Guides

Next.js in production on AWS

How to run a Next.js app in production on AWS, the architecture choices from a single container to multi-zone, what drives the cost, and how to get a priced, validated design for your own repository.

Next.js apps mix static assets, server rendering, API routes and often background work. This guide explains the architecture choices on AWS and how Brunel decides between them from your code.

What Brunel looks for in a Next.js repository

next in package.json (framework, version) and the Node.js version.
Rendering mode: a static export (output: "export") can live on object storage behind a CDN; server rendering needs compute.
Data: pg, prisma, drizzle or mongoose imply a database; ioredis a cache; @aws-sdk/client-s3 object storage.
Background work: queues (bullmq), cron entries in vercel.json, a worker process in a Procfile or Compose file.
Integrations: payments, email, AI services, authentication, and the environment variables they need.

Architecture by stage

Stage	Compute	Data	Edge
Starter	One small container service (or a VM for the smallest budgets)	Small managed PostgreSQL, daily backups	CDN in front, TLS
Growth	Container service with 2+ tasks and autoscaling, separate worker	Managed PostgreSQL, managed cache	CDN + WAF, staging environment
Scale	Multi-zone container service or Kubernetes	Multi-zone database with replicas, cache cluster	CDN + WAF, tracing, disaster recovery

Static assets and images always go through the CDN: it removes most of the traffic from your compute, which is why Brunel's default assumption sends 60 % of traffic to the CDN.

What drives the cost

Always-on compute: tasks × size × 730 hours. Autoscaling minimums matter more than maximums.
The database: size, high availability (roughly doubles the instance cost) and storage.
NAT and egress in private networks: often a surprise line. Brunel shows it separately.
Observability: log volume and retention.

Brunel prices every one of these lines from the AWS catalog for Paris (eu-west-3), with the catalog date, and shows the assumptions so you can change them.

Deployment

The generated workflow builds one image per service, pushes it to the registry and rolls out, authenticating to AWS with GitHub OIDC (no access keys). See Deployment.

Try it on your repository

Paste the repository in https://brunel.cloud/new.
Set your peak traffic and monthly budget in the questionnaire.
Compare Starter and Growth, click the database and the compute to see why each was chosen, and export the Terraform.

Or from your agent: see Infrastructure from your AI agent.