Skip to main content
This is the advanced AWS path: containers managed by ECS Fargate with auto-scaling, zero-downtime rolling deploys, CI/CD via GitHub Actions, and secrets in AWS Secrets Manager. If you’re getting started or running a single store, the EC2 + RDS guide gets you to production with a fraction of the moving parts — on the same Docker image, so you can graduate to ECS later without rework.

Required AWS Services

The required set is smaller than an AWS architecture diagram suggests — four services run the store: In front of the web service you’ll put an Application Load Balancer with a free HTTPS certificate from Certificate Manager — that’s your public entry point. Everything else is optional:

Docker Image

Build your project’s image with spree build --production, or use the stock ghcr.io/spree/spree image for deployments without customizations. To build and deploy a custom image to AWS ECR via GitHub Actions:
This action requires secrets to be set in your GitHub repository. You can find the full list of secrets in the AWS ECS Deploy Task Definition GitHub Actions repository.

Environment Variables

Store secrets in AWS Secrets Manager and reference them in your task definitions. Non-sensitive configuration goes in the environment array directly. For a full list of available variables, see Environment Variables.

Secrets Manager

Create the following secrets in AWS Secrets Manager: Optional secrets for email delivery, file storage, and error tracking:
S3 file storage credentials are not needed as environment variables when your ECS task role has the appropriate S3 permissions. Use IAM roles instead of access keys when possible.

ECS Task Definitions

One task definition runs the whole app — the web server also runs background jobs in-process (combined mode). Save it as .aws/web-task-definition.json. The worker task definition is an optional scale-out step — skip it (and the deploy-worker job in the workflow above) until job load deserves its own service.

Web Service

Worker Service (optional scale-out)

Switches to split mode: background jobs move into a dedicated service — same image, no rebuild. When you deploy it, set SOLID_QUEUE_IN_PUMA=false in the web task’s environment so the web container stops running jobs. Save as .aws/worker-task-definition.json:

Production Sizing

The task definitions above are sized for production. Here is a summary and scaling guidance: The database also stores background jobs and cache — the sizing above accounts for it. Scaling the web service to multiple instances is safe with in-process jobs: instances coordinate through the database. Add ElastiCache (Valkey or Redis) only for high-traffic caching.

Auto Scaling

Use ECS Service Auto Scaling to scale the web service based on CPU or memory utilization:

After Deployment

Admin

Access your admin panel at:
Default credentials are created during db:seed. Change them immediately after first login.

Database Migrations

The GitHub Actions workflow above runs migrations automatically on deploy. To run migrations manually:

Next Steps