Multiple commands on docker ENTRYPOINT
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
Running multiple startup commands in a container is common. You may need to wait for a dependency, run a migration, generate assets, and then launch the real service. The safest pattern is usually a small entrypoint script that performs setup and then uses exec to hand control to the main process. That keeps signal handling correct and prevents the container from being trapped behind a shell wrapper with awkward lifecycle behavior.
Know the Difference Between ENTRYPOINT and CMD
ENTRYPOINT defines the executable that always runs when the container starts. CMD provides default arguments that are appended unless the user overrides them.
This is the cleanest structure when a startup script must prepare the environment and then hand off to the application.
The Recommended Pattern Is a Wrapper Script
A short shell script is usually better than cramming several commands into one ENTRYPOINT string.
Dockerfile wiring:
The critical line is exec "$@". Without it, the shell remains PID 1 and signal forwarding becomes much less reliable.
Why One-Line Shell Chains Get Fragile
It is possible to write an inline shell chain.
This works for simple cases, but it gets ugly quickly:
- quoting becomes harder,
- error handling becomes less clear,
- signal behavior depends on how the shell remains in front,
- and debugging or extension becomes painful.
As soon as startup logic is more than one short chain, a script is the better engineering choice.
Make Startup Steps Conditional When Needed
A script also makes it easy to control behavior by environment variables.
This lets one image serve local, staging, and production use cases without duplicating Dockerfiles.
Avoid Treating One Container as a Full Process Supervisor
If you need several long-lived processes, the first question should be whether they should be separate containers instead. Containers are usually simpler to operate when they have one main process.
If you truly need multiple long-lived processes, use a minimal init system or real supervision carefully. But that should be an exception, not the default answer to “multiple commands”.
Test Shutdown Behavior, Not Just Startup Success
Many broken entrypoint setups appear fine during startup and only fail during stop or restart, because PID 1 behavior is wrong.
If docker stop consistently hangs or times out, the entrypoint handoff is probably incorrect.
Idempotency Matters for Startup Logic
Migrations and initialization commands may run again when a container restarts. That means startup logic should be safe to repeat or at least fail in a clear, intentional way.
Treat entrypoint scripts as real production logic, not as disposable glue. The first time a restart loop happens under orchestration is the wrong time to discover that the script assumes it runs only once.
Common Pitfalls
- Forgetting
exec "$@"and breaking signal handling for the real application process. - Packing complex shell logic into a single
ENTRYPOINTstring. - Running several long-lived background processes without supervision.
- Writing startup steps that are not safe under container restart.
- Assuming startup success is enough without testing shutdown behavior.
Summary
- Use an entrypoint script when a container must run several startup commands.
- Keep
ENTRYPOINTin exec form and hand off to the final process withexec. - Prefer scripts over long inline shell chains once logic becomes nontrivial.
- Keep startup steps idempotent where possible.
- Test both startup and shutdown behavior so PID 1 handling is correct.
Related reading
- Multiple docker containers in one EC2 instance through AWS ECS
- Multiple images inside one container
- Multiple RUN vs. single chained RUN in Dockerfile, which is better?
- My docker container has no internet
- My kafka docker container cannot connect to my zookeeper docker container
- Mysterious Filebeat 7 X-Pack issue using Docker image
- naming to docker.io, explanation and prevention?
- Need help troubleshooting a .NET Core 2.1 API in a linux Docker

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.