Deploy your code.
We handle the infrastructure.
Import from GitHub, upload your folder or publish straight from Devora IA. Devora Cloud detects your project, provisions the infrastructure and puts it online in seconds — with HTTPS, encrypted data and replicas on separate machines: if one goes down, your site stays up.
- 7-day free trial · no card
- Online in seconds
- No Dockerfile required
- Automatic HTTPS
- Encrypted data
- Managed PostgreSQL
- Replicas on separate machines
- AMD EPYC + NVMe
From a git push to production traffic, without a pipeline to maintain
Every deployment walks the same six stages. You watch them happen in real time; we own the queueing, the caching, the placement and the rollback.
- Median build
- 48s for a cached Next.js project
- Zero-downtime
- New replicas take traffic only after the health check passes
- One-click rollback
- Every previous image stays addressable by deployment number
A complete platform, not a thin wrapper around a server
Builds, containers, databases, replicas, monitoring, an API and an assistant that can actually change things — all governed by the same permissions and the same audit trail.
Git Deploy
Install the Devora GitHub App and every push to your default branch builds, deploys and health-checks itself. Pull requests get an isolated preview URL that disappears when they merge.
Upload Deploy
Drag a folder or a .zip into the dashboard and we take it from there. No CLI to install, no pipeline YAML to write, no registry to configure.
AI Assistant
Ask Devora reads your real deployments, logs and metrics. It explains why a build failed and proposes an action you preview before applying.
Databases
Managed PostgreSQL, MySQL, MariaDB, MongoDB and Redis in one click, on dedicated database servers, with optional replicas for high availability. Credentials are sealed with AES-256-GCM and injected into your service at start.
Replicas
Scale a service to N replicas with rolling deploys and health gating. Anti-affinity placement keeps replicas on separate nodes so one failure never takes you down.
Multi Server
Your application runs on AMD EPYC processors with NVMe storage. Add server capacity with a single install command: the scheduler filters by capacity, labels and region, then scores by real free CPU and RAM.
Monitoring
Per-container CPU, RAM, disk and network, node load and temperature, streaming logs, and alert rules that fire to the dashboard, email or a webhook.
API
Everything the dashboard does is a documented REST call on api.devoracloud.com/v1 — scoped API keys, cursor pagination, signed webhooks and predictable error codes.
Devora IA Integration
Projects generated in Devora IA publish straight to Devora Cloud. The code, the detected env schema and the recommended database come along with them.
Security
Containers run non-root with every capability dropped, seccomp and AppArmor profiles, pid/cpu/ram limits and an isolated per-project network. No Docker socket. Ever.
Bring your code however it exists today
Git repository, a folder on your machine, or a project generated by Devora IA. The pipeline after the source lands is identical — same detection, same builder, same guarantees.
Push to main, get production
Install the Devora GitHub App, pick a repository and we read the branch, the framework and the build commands. Every push redeploys; every pull request gets a preview.
- acme/storefrontTypeScript · pushed 2 min agoImport
- acme/checkout-apiGo · pushed 1 h agoImport
- acme/design-systemTypeScript · pushed yesterdayImport
- branch
- main
- framework
- NEXTJS
- builder
- RAILPACK
- install
- pnpm install --frozen-lockfile
- build
- pnpm build
- port
- 3000
Waiting for repository selection
Watch the deploy happen, line by line
No refreshing a build page and hoping. The log stream is the same one the platform writes, streamed over a websocket as the deployment moves through its stages.
- Every line, in orderBuild output, scheduler decisions, container creation and health checks land in one stream, tagged by stage and persisted with the deployment.
- Runtime logs tooAfter the deploy, the same viewer follows your containers across replicas and nodes, with search and level filters.
- Metrics beside themCPU, RAM, disk and network per replica, node load averages and request latency — all sampled continuously.
- Alerts when it mattersAlert rules watch the same series and fire to the dashboard, email or a signed webhook with a cooldown you control.
Replicas on separate machines, traffic that reroutes itself
The scheduler filters nodes by real capacity, labels and region, then scores them by free CPU and RAM. When a node degrades, the load balancer stops sending it traffic and the replica is rescheduled elsewhere.
- Healthy replica
- Degraded node · traffic withdrawn
- Request in flight
Replicas that follow the traffic
Replicas are created by demand: when traffic rises, Devora spins up more in seconds; when it falls, they wind down on their own. Zero configuration.
0.5 vCPU · 512 MB
healthy
storefront · 1 replica · created by demand
One command and the server joins the fleet
Generate the token in the dashboard, paste one line on the server and that is it: Docker, the agent and registration are automatic. The scheduler already counts the new machine on the next deploy.
$ curl -fsSL api.devoracloud.com/node/install.sh | sudo bash
node-sp-01
8 vCPU · 32 GB
node-sp-02
8 vCPU · 32 GB
waiting for a new server…
An assistant that reads your infrastructure and can fix it
Not a chatbot bolted onto a docs search. Ask Devora resolves the actual deployment, explains the failure in terms of your project, and proposes a change you can inspect before it runs.
Deployment #43 failed at the BUILD stage after 41s. The build ran pnpm build, which invoked prisma generate, and it exited with code 1.
The error is Environment variable not found: DATABASE_URL. Your project has DATABASE_URL defined for the PREVIEW environment only — the devora-pg-prod database you created two days ago was never linked to PRODUCTION.
Deployment #42 succeeded because it ran before Prisma was added to the build command, so nothing read the variable at build time.
Set DATABASE_URL in the PRODUCTION environment to the sealed connection URI of devora-pg-prod, then redeploy commit a91f3c2.
- Grounded in your telemetry
Ask Devora reads the deployment record, its logs, the project configuration and the node metrics behind it — never a generic answer.
- Permission-aware
Every proposed action is re-checked against your role in the organization before it can be applied, and it lands in the audit log with your name on it.
- Preview before apply
Actions are suggestions until you preview the exact change. Destructive ones require a second confirmation and can never run implicitly.
- POST /v1/ai/threads/:id/messages · SSE stream
POST /v1/ai/actions/:id/preview
POST /v1/ai/actions/:id/apply
Isolation you do not have to configure
These are not toggles buried in an advanced tab. Every container the platform creates is built from the same locked-down specification, enforced on the control plane and again on the node agent.
Non-root by default
Every customer container starts as user 1000:1000 with noNewPrivileges and capDrop ALL. Nothing you deploy can escalate to root on the node.
CPU, RAM and PID limits
Each replica is capped by its plan: cpuLimit, memoryMb and pidsLimit are enforced at container creation, so a runaway loop never starves a neighbour.
Network isolation
Projects get a private internal network. Services reach each other by name, the public edge only sees the ports you expose, and host networking is never allowed.
seccomp + AppArmor
A seccomp profile and the docker-default AppArmor profile are applied to every workload, blocking the syscall surface used by container escapes.
No Docker socket. Ever.
/var/run/docker.sock is never mounted into a customer container, privileged mode is rejected control-plane side and agent side, and host mounts are restricted to the Devora-managed volume root.
Sealed secrets
Environment secrets are sealed with AES-256-GCM using a per-record IV, stored encrypted, redacted from every log line and decrypted only when a container starts.
"security": {
"user": "1000:1000",
"readOnlyRootfs": false,
"noNewPrivileges": true,
"capDrop": ["ALL"],
"capAdd": [],
"seccompProfile": "default",
"apparmorProfile": "docker-default",
"privileged": false,
"networkMode": null
},
"resources": { "cpuLimit": 0.5, "memoryMb": 1024, "pidsLimit": 512 }- gVisor (runsc)On the roadmapOpt-in user-space kernel for untrusted workloads, intercepting syscalls before they reach the host kernel.
- Firecracker microVMsOn the roadmapHardware-virtualized isolation per workload for customers who need a boundary stronger than namespaces.
- Immutable audit trailShipping todayEvery action in the platform is already written to an append-only audit log scoped by organization.
Predictable plans, real resources
Every plan includes automatic HTTPS, custom domains, the full API, webhooks and the dashboard. You pay for the capacity your services actually reserve.
Business
Plataforma de várias equipes: até 10 réplicas em hosts diferentes.
R$499/mo
7 days free, then billed monthly · cancel anytime
- 40 projetos · até 10 réplicas em hosts físicos diferentes
- Escala automática
- 4 vCPU · 4 GB
- 40 bancos gerenciados
- Auditoria exportável · backup 30 dias
4 vCPU · 4 GB RAM · 100 GB disk
What Devora handles for you
Building your own infrastructure means wiring, configuring and maintaining every piece by hand. With Devora it all ships ready and integrated.
Frequently asked questions
The questions that come up before the first deploy — answered without hand-waving.
No. Devora Cloud analyzes your code, identifies the language, the framework and the package manager, and assembles the image for you. Docker is an implementation detail on our side — all you need is your project.