4.2.7.2 ENTRYPOINT Argument Forwarding
A focused guide to ENTRYPOINT Argument Forwarding, connecting core concepts with practical Docker and container operations.
ENTRYPOINT argument forwarding is the behavior where anything supplied as arguments to docker run, beyond the image name itself, is appended directly to the fixed ENTRYPOINT executable rather than replacing it — the mechanism that lets a fixed-entrypoint image still accept flexible input.
How Forwarding Works
Whatever is typed after the image name in docker run becomes the argument list appended to the program ENTRYPOINT specifies.
ENTRYPOINT ["python", "app.py"]
docker run myimage --verbose --port 9090
This results in executing python app.py --verbose --port 9090, with the supplied flags forwarded directly as arguments to the fixed command.
Forwarding Interacts With CMD as Default Arguments
When CMD is also present, it supplies the default arguments forwarded to ENTRYPOINT if none are explicitly provided at run time, with any explicitly supplied arguments replacing those defaults entirely rather than being combined with them.
ENTRYPOINT ["python", "app.py"]
CMD ["--mode", "production"]
docker run myimage
docker run myimage --mode development
The second invocation replaces the default --mode production argument entirely with --mode development, rather than supplying both.
Forwarding Arguments Through a Wrapper Script
When ENTRYPOINT is a custom script rather than the application directly, that script typically needs to explicitly forward its own received arguments to the actual application it eventually launches.
#!/bin/sh
# entrypoint.sh
echo "Starting with arguments: $@"
exec myapp "$@"
The "$@" here represents exactly the arguments forwarded by Docker's argument forwarding mechanism, which this script then forwards onward to the actual application.
Why Understanding Argument Forwarding Matters
A clear understanding of exactly how arguments flow from docker run through ENTRYPOINT (and any wrapper script involved) to the final executed program is essential for correctly designing an image that accepts flexible, runtime-supplied configuration while still maintaining a fixed, predictable underlying command.