Introduction

If you create a container with docker run and then need its id or name for later commands, the best approach is to capture that information at creation time. Docker already returns the container id in detached mode, and it can also write the id to a file. Polling docker ps after the fact can work, but it is much less reliable in automation because multiple similar containers may be running.

Easiest Case: Detached Mode Returns the Container ID

When you run a container with -d, Docker prints the container id to standard output.

container_id=$(docker run -d nginx:alpine)
echo "$container_id"
docker logs "$container_id"

This is the cleanest pattern for scripts because the id comes directly from the creation command. No extra lookup is required.

Best Practice: Assign a Name Explicitly

If your workflow will refer to the container multiple times, naming it is often better than chasing the id.

1docker run -d --name web-test nginx:alpine
2docker logs web-test
3docker exec web-test nginx -v
4docker rm -f web-test

A predictable name makes scripts easier to read and debug. It also avoids accidental matches when multiple similar containers exist.

Use --cidfile for Robust Automation

For shell automation, --cidfile is very useful. Docker writes the created container id to a file.

docker run -d --cidfile /tmp/mycontainer.cid nginx:alpine
container_id=$(cat /tmp/mycontainer.cid)
echo "$container_id"

This is especially helpful when:

• you want the id even if command output is redirected,
• a script is split across steps,
• another tool needs to consume the id later.

It is a more deterministic interface than grepping docker ps.

Foreground Containers Need a Different Pattern

If you run without -d, Docker attaches to the container process instead of returning the id in a script-friendly way. In that case, naming the container or using --cidfile is the better solution.

Example:

docker run --name batch-job --cidfile /tmp/batch.cid alpine sh -c "sleep 5"

Even if the process runs in the foreground, you still have a reliable id in /tmp/batch.cid.

Why docker ps Lookup Is a Fallback, Not a Primary Method

You can search for a running container after creation:

docker ps --filter ancestor=nginx:alpine --format '{{.ID}} {{.Names}}'

Or by name pattern:

docker ps --filter name=web-test --format '{{.ID}}'

This is fine for debugging, but it is weaker in automation because:

• multiple containers can match,
• timing can race with startup,
• ids are no longer tied to the exact docker run invocation.

Prefer creation-time capture whenever possible.

Container Name Versus Container ID

Choose the identifier based on the workflow:

• use container id when you need exact machine-level identity,
• use --name when humans or scripts will interact with the container repeatedly,
• use both in more structured automation.

Example:

docker run -d --name app-under-test --cidfile /tmp/app.cid myapp:dev

Now you have:

• a stable human-readable name,
• the exact container id stored for machine use.

Integrating with Later Docker Commands

Once you have the id or name, every follow-up command becomes straightforward:

1docker exec "$container_id" env
2docker inspect "$container_id"
3docker stop "$container_id"
4docker rm "$container_id"

The important part is that the identifier comes from the same lifecycle event that created the container.

Common Pitfalls

• Parsing docker ps output after the fact when the id could have been captured directly from docker run -d.
• Avoiding --name and then writing harder-to-maintain scripts that depend only on opaque ids.
• Assuming an image-based docker ps --filter ancestor=... query identifies one unique container.
• Running a foreground container without --cidfile and then struggling to recover the exact id reliably.
• Hardcoding container ids that change every time the container is recreated.

Summary

• In detached mode, docker run -d already returns the container id.
• Use --name when you want a stable, readable handle for later commands.
• Use --cidfile when automation needs the exact id in a robust way.
• Treat docker ps lookups as a fallback, not the primary integration method.
• Capture the identifier at container creation time whenever possible.