[{"content":"Both entrypoint and command define what runs when a container starts. They look similar, but they play different roles, and confusing them leads to surprising behavior.\nThe mental model When a container starts, Docker runs:\n<entrypoint> <command> entrypoint is the executable command is the default arguments passed to it If the image’s Dockerfile has ENTRYPOINT ["python"] and CMD ["app.py"], the container runs python app.py.\nOverriding from Compose Both can be overridden in Compose:\nservices: app: image: python:3.12 entrypoint: ["python"] command: ["app.py", "--debug"] This runs python app.py --debug regardless of what the image’s Dockerfile defined.\nWhen you typically only set command Most of the time, you just want to run a different command on an image:\nservices: # Run tests instead of the default app tests: image: myapp command: ["pytest", "tests\/"] # Run a one-off migration migrate: image: myapp command: [".\/migrate.sh"] The image’s ENTRYPOINT (often python, node, or \/entrypoint.sh) handles the executable, and you just pass different arguments.\nWhen you set entrypoint Override entrypoint when you want to bypass the image’s default executable:\nservices: # Image normally starts the app, but here we want a shell debug: image: myapp entrypoint: ["\/bin\/sh"] command: ["-c", "env && tail -f \/dev\/null"] To completely disable the image’s entrypoint and run a fresh command:\nservices: app: image: myapp entrypoint: [] command: ["echo", "hello from compose"] Exec form vs shell form There are two syntaxes:\n# Exec form (recommended) \u2014 array, runs directly command: ["python", "app.py"] # Shell form \u2014 string, runs through \/bin\/sh -c command: python app.py Exec form is preferred because:\nSignals (SIGTERM, etc.) reach your process directly (Tip #44) No shell expansion gotchas Faster startup (one less process) Use shell form only when you need shell features:\ncommand: bash -c "wait-for-db && python app.py" Override at runtime docker compose run lets you override both at runtime:\n# Override command docker compose run --rm app pytest tests\/ # Override entrypoint with --entrypoint docker compose run --rm --entrypoint \/bin\/sh app This is the cleanest way to debug a misbehaving service (Tip #34).\nA common gotcha If you define command: in Compose but the image already has an ENTRYPOINT that doesn’t expect arguments, things break:\n# Dockerfile ENTRYPOINT ["\/start.sh"] # compose.yml services: app: image: myapp command: ["bash"] # Becomes: \/start.sh bash \u2014 probably not what you want Either set entrypoint: [] to clear the image’s entrypoint, or use the existing entrypoint as designed.\nFurther reading Compose specification: entrypoint Compose specification: command Related: Tip #34, Debugging with exec vs run Related: Tip #44, Signal handling in containers ","permalink":"https:\/\/lours.me\/posts\/compose-tip-059-entrypoint-vs-command\/","summary":"

Both entrypoint<\/code> and command<\/code> define what runs when a container starts. They look similar, but they play different roles, and confusing them leads to surprising behavior.<\/p>\n

The mental model<\/h2>\n

When a container starts, Docker runs:<\/p>\n

<entrypoint> <command>\n<\/code><\/pre>