Docker
Every workload runs in its own resource-limited container, so one app cannot starve another of memory or CPU.
- Dedicated namespaces per workload
- cgroup limits for memory and vCPU
Infrastructure
Built on open source. No lock-in.
The technologies and routing architecture that power Deployxa: proven open-source components, wired together for predictable deploys.
01 / Topology
How a request reaches your app.
Traffic enters through the edge proxy, which terminates TLS and forwards only to healthy containers. Builds and state live behind it.
- HTTP clientbrowser · API caller
- Traefik proxyedge router · Let's Encrypt TLS
- App containersisolated Docker network
- Backend engineRedis queue · PostgreSQL
02 / Controls
Isolation and safe rollouts.
The builder compiles your code and starts the new container next to the old one. Traffic moves only after the new container passes its health checks; then the old one is stopped.
- Each customer container runs in an isolated network sandbox
- System calls are filtered to block privilege escalation
- No dropped requests during the switch
Release v42
main · 7e1c0d9
- 01New container startedstandby
- 02Liveness check200 OK
- 03Traffic switchedv41 → v42
- 04Old container stoppeddrained
03 / Stack
The components, in detail.
Traefik
A cloud-native edge router that picks up new containers and re-routes public endpoints without reloads.
- Maps domains to container ports
- Load balancing and sticky sessions
BullMQ
Runs builds, migrations and environment setup asynchronously on Redis-backed queues.
- Retries and priority queues
- Backpressure during build spikes
Redis
In-memory store that brokers the job queue and caches session state and routing maps.
- High-throughput reads and writes
- Routing tables kept in sync
PostgreSQL
The source of truth for accounts, project configuration, deployment history and domain records.
- Scheduled snapshots
- Monitored for locks and slow queries
Let's Encrypt
Issues and renews TLS certificates automatically for every custom domain routed to Deployxa.
- ACME via Traefik
- HTTP-01 or DNS-01 validation
04 / Lifecycle
From job to live release.
Every deployment, whether it starts from Git, the CLI or the dashboard, takes the same path through the stack.
- 01 /
Queue
A push, CLI deploy or manual redeploy becomes a job on the Redis-backed BullMQ queue. Concurrent builds are capped per plan; extra builds wait their turn.
- 02 /
Build
The builder runs in its own sandbox, restores cached layers, then produces static output or a container image from your Dockerfile or the detected stack.
- 03 /
Release
The new container starts next to the current one. Traefik only routes to it after its health check passes, then the previous container is drained.
- 04 /
Live and standby
The release is live on its domains with TLS. The previous release is kept on a warm standby for a short window, so a rollback can switch back without a rebuild.
05 / Isolation and limits
Each app gets a fixed share.
Workloads run in separate containers with cgroup limits, so the numbers below are the ceilings each plan runs within. Enterprise plans are sized to order.
| Resource | Free | Starter | Pro | Team | Business |
|---|---|---|---|---|---|
| CPU | Shared | 1 vCPU | 2 vCPU | 2 vCPU | 8 vCPU dedicated |
| Memory | 512MB | 2GB | 4GB | 4GB | 32GB |
| Storage (SSD) | 1GB | 20GB | 80GB | 80GB | 250GB |
| Concurrent builds | 1 | 2 | 4 | 8 | 16, priority queue |
| Managed databases | Not included | 1 | 5 | 10 | 25 |
| Private networking | Not included | Not included | Not included | Not included | Included |
From the current pricing page. Free apps idle after 20 minutes without traffic and wake on the next request.
06 / Backups
Snapshots, restores and release history.
Database snapshots
PostgreSQL databases can be snapshotted to object storage with checksum verification. Snapshots are kept for 30 days by default and can be deleted early.
Restore and export
Restore a snapshot from the Backups tab; connected containers are reconnected afterwards. Databases can also be exported and imported for moving client data.
Release history
Successful releases stay in the deployment history, so you can roll back to an earlier build from the dashboard or with deployxa rollback.
Platform state
Accounts, project configuration, deployment history and domain records live in PostgreSQL with scheduled snapshots.
07 / Observability
See what the stack is doing.
The same signals the platform uses to route traffic are exposed to you, per project and across your organization.
- CPU, memory, requests, average and p95 latency, 5xx rate
- Build and runtime logs attached to every deployment
- Domain alerts for failed DNS, TLS or renewals
- deployxa metrics and deployxa logs from the terminal
- 01CPU utilizationlast 12 samples
- 02MemoryMB
- 03Requests per hourchart
- 04p95 latencyms
- 055xx rate%
08 / FAQ
Infrastructure questions.
Do apps share a server?
On shared plans, apps run on shared hosts but each in its own container with memory and CPU limits and its own network boundary. Business adds dedicated compute (8 vCPU, 32GB RAM) and private networking.
What happens if my app exceeds its memory limit?
The container is held to its plan limit, so a memory-hungry app cannot take resources from its neighbours. If your app needs more, move to a larger plan or dedicated compute.
Are backups automatic?
Database snapshots can be taken from the Backups tab and are retained for 30 days by default. Backup and restore is listed as a Business plan feature; check the pricing page for what your plan includes.
Can I run Deployxa on my own servers?
Yes. You can connect your own VPS (for example on AWS, Hetzner or DigitalOcean) and route deploys to it, and Enterprise offers on-premise deployment.
Why open-source components?
Docker, Traefik, Redis, BullMQ, PostgreSQL and Let's Encrypt are widely used and well documented. Your app ships as a standard container image, so it can run elsewhere if you ever leave.
Ready when you are
Run your app on this stack.
Same infrastructure on every plan, from Free to Enterprise.