Introduction

Docker usually separates image creation from container startup. You run docker build to produce an image and docker run to start a container from that image.

If you want a one-liner for quick development work, you can combine both steps. The trick is to let docker build output the image ID and pass that ID directly into docker run.

The Basic One-Command Pattern

The simplest version looks like this:

docker run --rm -p 8080:8080 "$(docker build -q .)"

Here is what each part does:

• 'docker build -q . builds the image from the Dockerfile in the current directory'
• '-q tells Docker to print only the resulting image ID'
• '$(...) captures that image ID in the shell'
• 'docker run starts a container from that temporary image reference'
• '--rm removes the container when it exits'

This is convenient for fast local testing because you do not need to invent a tag name for every run.

A Complete Example

Suppose you have this Dockerfile:

1FROM python:3.12-slim
2
3WORKDIR /app
4COPY app.py .
5
6CMD ["python", "app.py"]

And this small program:

print("hello from the container")

You can build and run it immediately:

docker run --rm "$(docker build -q .)"

The output will be:

hello from the container

If the container exposes a service, add port mapping and any required environment variables:

docker run --rm -p 4000:8080 -e APP_ENV=dev "$(docker build -q .)"

That is still one shell command even though it performs two Docker operations internally.

When This Approach Is Useful

This pattern is best for short feedback loops:

• testing a sample Dockerfile
• running a throwaway container during development
• verifying that a code change still builds and starts

It is less useful when you need a reusable, named image. In that case, tagging the image explicitly is clearer:

docker build -t myapp:dev .
docker run --rm -p 4000:8080 myapp:dev

That is two commands, but it is easier to debug, easier to repeat, and easier to share with teammates.

Variations You Will Actually Use

If your Dockerfile has a non-default name or lives elsewhere, include -f:

docker run --rm "$(docker build -q -f docker/Dockerfile .)"

If you need build arguments:

docker run --rm "$(docker build -q --build-arg APP_MODE=demo .)"

If the container should stay interactive:

docker run --rm -it "$(docker build -q .)"

The pattern is flexible because anything that produces a valid image reference can be substituted into docker run.

Tradeoffs and Limitations

The one-liner is handy, but it hides the image name. That can make troubleshooting harder because the image is identified only by a hash unless you inspect the shell-expanded command.

It also does not remove the built image automatically. --rm cleans up the container, not the image. If you repeat the command many times and the build cache changes often, your machine can accumulate unused images.

Finally, command substitution is a shell feature. It works in shells such as bash and zsh, but the exact quoting rules can differ across environments. If you need maximum portability across scripts and CI systems, the explicit two-step form is often safer.

Common Pitfalls

• Assuming --rm deletes the image. It only removes the stopped container.
• Forgetting quotes around the command substitution in shells where whitespace handling matters.
• Using the pattern in CI when a tagged image would make logs and debugging clearer.
• Expecting this to work the same way in every shell without checking the shell's command-substitution rules.

Summary

• You can build and run a Docker image in one shell command with docker run "$(docker build -q .)".
• The -q flag makes docker build print only the image ID.
• This approach is useful for fast local experiments and throwaway runs.
• It is less clear than tagging the image explicitly when you need repeatability or debugging.
• '--rm removes the container, not the built image.'