I have an Apache/PHP application built into a Docker image and published to a container registry through CI. A separate infrastructure repository contains a docker-compose.yml file that runs the PHP container alongside Nginx, including the Nginx configuration and mounted TLS certificates. Each release creates a new EC2 instance and uses user data to initialize the server. With a single image, the startup process would simply install Docker, pull the image, and run it. With Compose, I also need to deliver the Compose file and its related configuration. Should these files be packaged as a versioned archive or pulled from the infrastructure repository during boot? Is there a commonly recommended approach? I want to keep the deployment relatively cloud-agnostic while continuing to use EC2 as the VM and a container registry, rather than adopting ECS, Fargate, or Kubernetes. I am also open to reconsidering the design—for example, terminating TLS at a load balancer and running only the Apache/PHP container on each instance.
4 Answers
For a small deployment that intentionally runs on one VM, using Docker Compose is perfectly workable. Keep the Compose file, Nginx configuration, and any other deployment files in version control, then publish them as an immutable, tagged release artifact. The instance's user-data script can download that exact archive, install Docker and Compose, and run `docker compose pull && docker compose up -d`. Avoid pulling an unpinned branch during boot, and keep secrets and certificates in a proper secret or certificate store rather than embedding them in the bundle.
Compose itself is not a multi-host scheduler. You can place identical EC2 instances behind a load balancer, but each VM would be running its own independent Compose stack, with no orchestration between them. That can be a valid and simple scaling model, but it means you must handle health checks, deployment coordination, instance replacement, shared state, and TLS carefully. If the load balancer terminates TLS, Nginx may not need to be in every application instance; the instances could run only Apache/PHP behind the load balancer.
So the limitation is not that multiple EC2 instances are impossible, but that Compose does not coordinate them as one cluster. The load balancer and the instance group would provide the scaling behavior instead.
You can also have the bootstrap script check out a specific infrastructure-repository tag instead of creating a separate archive. The important part is that the VM gets a known version of the Compose file and Nginx configuration, not whatever happens to be on the latest branch. Ansible or another configuration-management tool can handle the host preparation, file delivery, registry login, and Compose startup if you want more structure than a long user-data script.
If the application is small and the desired model is one complete stack per VM, keeping Nginx and PHP together is not inherently wrong. Moving to Kubernetes or another orchestrator adds significant operational complexity and is not automatically better for a single-host workload. Start with a reproducible Compose deployment, pin image versions, make the instance disposable, and move to a scheduler only when the operational requirements justify it.
That makes sense. My concern was that packaging the Compose file felt backwards, but treating it as a versioned deployment artifact seems reasonable.