Translating Elastic Beanstalk configuration to Docker Compose

• Environment properties
• Platform and runtime
• Procfile
• Load balancer and listeners
• Auto scaling
• .ebextensions
• Platform hooks
• RDS
• Logs and monitoring
• Cutover plan

Elastic Beanstalk hides a lot of configuration in environment settings, .ebextensions and platform hooks. When moving to containers on your own server, the work is mostly translation. This mapping covers the settings most apps use.

§Environment properties

Beanstalk environment properties become environment variables in Compose or your deployment tool’s secret store. Export them from the console or with the EB CLI, then store them outside the repository.

§Platform and runtime

The Beanstalk platform version, such as a specific Node.js or Python on Amazon Linux, becomes a pinned base image in your Dockerfile, for example node:20-slim or python:3.12-slim. Pin versions explicitly; you no longer get managed platform updates.

§Procfile

If you used a Procfile on Beanstalk, each process becomes a Compose service from the same image with a different command.

§Load balancer and listeners

The Application Load Balancer, listeners and HTTPS certificates are replaced by a reverse proxy on the server, such as Caddy or Traefik, with automatic Let’s Encrypt certificates. Health check paths configured on the target group move to container health checks.

§Auto scaling

Beanstalk auto scaling groups have no direct equivalent on a single server. For most small and medium apps, a right sized server with headroom replaces scaling. If you truly need horizontal scale, run several app containers behind the proxy or use more than one server.

§.ebextensions

These YAML files install packages, write files and run commands. Translate them:

• packages become apt-get install lines in the Dockerfile
• files become files copied into the image or mounted as config
• container_commands such as migrations become a pre deploy step that runs once
• option_settings become environment variables or proxy configuration

§Platform hooks

Scripts in .platform/hooks run at deploy stages. Most become Dockerfile build steps or release commands. Anything that modified Nginx becomes proxy configuration.

§RDS

If the app uses RDS, you can keep it and just point the new server at it, or move to a Postgres or MySQL container with off-server backups. Keeping RDS initially reduces risk.

§Logs and monitoring

CloudWatch log streams are replaced by container logs collected by your platform or a log shipper. Set up uptime checks before cutover.

§Cutover plan

1. Build and run the container locally with the exported variables.
2. Deploy to the new server on a test domain, pointed at the existing database.
3. Lower DNS TTL, switch, and keep the Beanstalk environment for a few days.
4. Terminate it once traffic and errors look normal.

A broader comparison of replacement options is in this guide to Elastic Beanstalk alternatives.

Disclosure: I work on Peon.