I don't like the way docker buildx works at the moment. Hopefully it improves over time. My biggest complaint is that everything is baked into a single comman

I don't like the way docker buildx works at the moment. Hopefully it improves over time. My biggest complaint is that everything is baked into a single command instead of being discreet commands. So instead of: docker build... docker tag... docker push... it's: docker buildx build --tag... --push... Most CI systems do something similar and you end up with an awful, monolithic build step that's essentially 'build-and-test-and-tag-and-push'. It's the same on every platform too. GitHub Actions, GitLab CI, Drone CI, etc. all seem to do the same thing. What if I want to build in one environment that pushes and one environment that doesn't? In my experience it's much easier if 'push' can be a build step on it's own because the CI system will usually have conditional support for things like different environments. From what I've seen it's not possible to use buildx and then conditionally tag the resulting images in a second command or build step. The 'docker' driver doesn't support multiarch and the 'docker-container' driver doesn't support '--load' [1], so you're pretty much stuck with a single command that does everything, at least for now, because the built images won't be added to the daemon used for building (ie: you won't see them with 'docker image ls'). Am I wrong? I've always liked the way the Docker daemon uses simple commands for everything; docker pull, docker build, docker tag, etc.. It feels very unix like. It would be a shame to lose that IMO. 1. https://github.com/docker/buildx/issues/543 https://github.com/docker/buildx/issues/543