Architecture

How Deploxa is built.

Three cooperating services on AWS — a Next.js control plane, ephemeral Fargate build workers, and an Express edge proxy. This page is the visual tour: click through any diagram, flow, or service to see how it works.

Services

10+

AWS services

Cloud providers

Runtime targets

Explore the diagram Read the docs

01 · Overview

Three services, three responsibilities

Every service scales and fails independently. The control plane holds all state; the build worker and edge proxy are deliberately stateless.

Control plane

The brain

Dashboard + REST API + orchestration
Owns all state (Postgres via Prisma)
Triggers build tasks, resolves domains, handles auth + billing

Next.js 16React 19Prisma 7Better Auth

Build worker

Ephemeral by design

One container per deployment — spins up, builds, uploads, exits
Streams build logs back over HTTPS to the control plane
No persistent state, no shared filesystem, no snowflakes

Node.js 20DockerAWS ECS Fargate

Edge proxy

The doorway

Serves every deployed site — static, Lambda-backed, or Container-backed
Domain resolution over Redis (push-cache), zero HTTP calls on hit
Firewall rules, custom headers, redirects, on-demand TLS for custom domains

Express 5RedisS3AWS EC2 + Caddy

02 · System diagram

Where everything sits

Drag to pan, scroll to zoom. Click any service and its details open in the panel beside the diagram — how it works, what it runs on, and what it connects to.

request pathasync / supporting

Click any service to read its details here.

Request path

1.Visitor hits a *.deploxa.com or custom domain
2.Cloudflare (DNS-only) resolves it to the EC2 elastic IP
3.Caddy terminates TLS and routes the apex host to the control plane
4.Every other host goes to the edge proxy on :8000
5.Proxy resolves the deployment from Redis and serves S3 or invokes Lambda

03 · Data flow

What happens when…

Pick a scenario to see the exact sequence of hops between services — from git push to a rendered page.

1
GitHub → Control plane
Webhook lands
GitHub POSTs a push event. The control plane HMAC-verifies it, matches the repo+branch to a project, checks the plan's monthly deployment limit, and creates a Deployment row.
2
Control plane → Redis
Reserve a build slot
Concurrent builds are capped platform-wide via a Redis Lua script (atomic acquire-or-fail). Deployment stays QUEUED if no slot is free.
3
Control plane → ECS
Launch a Fargate task
RunTask with the repo URL, git token, decrypted env vars, JWT signing key ARN, and callback URLs. The container starts in a public subnet with awsvpc networking.
4
Builder container
Clone, install, build
Fetches the JWT secret from Secrets Manager, clones with the user's OAuth token, runs install + build. Output directory is auto-detected (Vite dist, Next .next, CRA build, etc.).
5
Builder → S3 + Control plane
Upload + status callbacks
Static output uploads to S3. Every log line POSTs back to the control plane's /api/log endpoint (signed with the JWT). Status transitions QUEUED → BUILDING → DEPLOYING → READY.
6
Control plane → Redis (push)
Prime the domain cache
On READY, the control plane writes the domain → deployment mapping into Redis. The edge proxy reads it on the next request with zero HTTP round-trips.
7
Browser → Edge
First request served
The visitor hits Caddy → proxy. Proxy resolves domain from Redis, decides runtime (STATIC / NODEJS / NEXT_SSR), and either streams S3 assets or invokes Lambda.

Want to build on it?

The docs cover everything you need to deploy an app, configure it, and run it in production.

Read the docs About the maker

How Deploxa is built.

Services

10+

AWS services

Cloud providers

Runtime targets