Docker -f Flags: File vs Force

The same -f letter means two different things in the Docker CLI. In docker compose it selects which compose file to operate on; in docker rm it force-removes a running container. This doc covers both, including the common trap where a stack defined in a non-default compose file is not affected by a plain docker compose command.

Quick reference

docker compose -f compose.batch.yaml down             # -f = file: operate on this compose file
docker compose -f compose.yaml -f compose.prod.yaml up -d   # layer files, later overrides earlier
docker rm -f my-worker                                # -f = force: kill + remove in one step

docker compose -f: pick the compose file

By default docker compose looks for compose.yaml (or docker-compose.yml) in the current directory. -f points it at a different file:

docker compose -f compose.batch.yaml up -d
docker compose -f compose.batch.yaml down

This is the trap: if a stack was started from a non-default file, a plain docker compose down does nothing to it - without -f, the command operates on compose.yaml only. Any command against that stack (up, down, ps, logs) needs the same -f.

Layer multiple compose files

-f can be passed multiple times. The files are merged in order and later files override earlier ones - the usual pattern for a base file plus an environment overlay:

docker compose -f compose.yaml -f compose.prod.yaml up -d

docker rm -f: force-remove a running container

docker rm normally refuses to remove a running container. -f makes it kill the container first (SIGKILL) and then remove it, in one step:

docker rm -f my-worker my-scheduler

Without -f the same cleanup takes two steps per container:

docker stop my-worker
docker rm my-worker

Since -f kills with SIGKILL, the container gets no graceful shutdown - fine for stateless workers, but prefer docker stop first for anything that needs a clean exit (e.g. a database flushing to disk).