Deployment targets

cengrid init takes --target docker|fly|aws. The choice determines the config, secret rules, generated files and teardown contract.

	Docker	Fly	AWS
Control plane	Local containers	Fly apps	Digest-pinned ARM64 tasks on ECS Fargate
Agent computers	Local containers (sandbox.backend: "local")	Sprites computers	Lambda MicroVMs, or Sprites with sandbox.backend: "sprites"
Postgres	Local container or your DSN	Fly Postgres or your DSN	Terraform-managed RDS
Rollback	Not claimed	Restores a sandbox pin	Restores the prior deployment manifest
Dockerfile apps	Yes	No	Yes (MicroVM images)

Prerequisites

Requirement	Docker	Fly	AWS
Node 24 and the cengrid CLI	Yes	Yes	Yes
Docker daemon	Yes	Build path	Image build path
Sandbox image and credentials	Fly app for real execution	Fly app and scoped token	MicroVM image and execution role
Slack bot app, bot token and app token	When Slack is enabled	When Slack is enabled	When Slack is enabled
Admin email, verified sender, and a Resend key or SMTP credentials	With the built-in auth broker	With auth	With auth
AWS credentials, ECS, ECR, RDS, ALB, Cloud Map, GitHub OIDC trust	No	No	Yes

Fly

Fly requires region and flyOrg, plus a sandbox.app. For a hosted customer with a dedicated Fly organisation and linked billing, use the guided customer provisioning script in the product repository.

AWS

AWS requires a 12-digit account id, region, deployment label, ECS cluster, deploy-role ARN, Secrets Manager prefix and a DNS-valid Cloud Map namespace, plus an entry per enabled service with a unique ECR repository, ECS service and valid Fargate CPU and memory. The reference module exposes CloudFront over HTTPS and restricts its HTTP ALB origin to CloudFront. With the portal enabled it is the ALB’s only target, so access to private surfaces requires signed portal identity.

• imageLabel identifies the complete deployment manifest used by rollback and live drift checks.
• infra build-image publishes the ARM64 sandbox container to the private core ECR repository and builds the Lambda MicroVM from its digest. It needs a builder that builds linux/arm64 natively, such as Apple silicon, AWS Graviton, a GitHub ubuntu-24.04-arm runner or Docker Build Cloud. Node 24 crashes under QEMU emulation.
• Terraform keeps the 30 newest sandbox- tags in the core repository, so a rollback target several deploys old has correspondingly less headroom.
• up snapshots RDS before its first mutation (aws.predeployDbSnapshot: false opts out) and refuses an unavailable database.
• cengrid doctor verifies ECS, ECR, RDS, CloudFront-to-ALB routing, the deploy role and its exact GitHub repository trust, required secrets and the MicroVM image pin.

Upgrading from a release before prepared environments

Apply the rendered Terraform before the next infra build-image. The MicroVM is now built from the sandbox container in the private core repository, and only that infrastructure apply lets the build role pull from it. The order is merge, infrastructure apply, then deploy.

Prepared environments

On Sprites, prepared environment bundles are stored in a private S3-compatible bucket (S3_BUCKET, S3_REGION). On AWS, preparation builds a MicroVM image per environment set and needs AWS_DEPLOY_BUILD_ROLE_ARN. Without them computers apply items directly, which still works.

Each deploy that runs infra build-image publishes a new base, so each active environment set builds a new prepared image on its next launch. This is intended: a prepared image must match the base it starts from.