There's no need to do things exactly as is being done there. You can bind-mount in a directory for your build dockerfile and output to that directory and then

There's no need to do things exactly as is being done there. You can bind-mount in a directory for your build dockerfile and output to that directory and then use that as the input to the next dockerfile without having to rely on the build dockerfile creating a valid tarball containing a dockerfile etc. The difference isn't huge, but I think it's good to uncouple the build/run-image creation logic a little more. Doing so also lets you more easily work on the dockerfiles independently and debug certain issues (e.g. you can compile the binary outside of docker, put it in the run one, make sure things are okay). As for his bonus points: You can avoid using busybox by compiling your go program with: "CGO_ENABLED=0 go build -a -installsuffix cgo my-program.go" (assuming go 1.4). The output of this is a static binary which you can add to an empty docker container. The way to do that would be to have a dockerfile of `FROM empty; COPY ./my-program /my-program; ENTRYPOINT ["/my-program"]` with newlines replacing each semicolon. It will end up somewhat smaller than the busybox image, but the savings aren't nearly as dramatic as you might expect. If you do tls/ssl or rely on any exec calls, you'll also probably be better off just using busybox for the certificates and basic binaries being present.