What is Docker's default log driver, and where does it write a container's stdout on the host?

## What a log driver actually is When `dockerd` starts a container it does not attach the container's `stdout` and `stderr` to your terminal. It attaches them to pipes (or a pseudo-terminal when the container is created with `-t`), reads them inside the daemon, and passes each message to a **logging driver** — a small component compiled into the engine whose only job is to decide where that message goes. The message carries three things: the text of the line, which stream it came from (`stdout` or `stderr`), and a timestamp. This is the first thing to internalise: the driver only ever sees the two console streams. If a Django app configured with a `FileHandler` writes to `/var/log/app.log` inside the container, no log driver on earth will see it — the bytes land in the container's writable layer and disappear when the container is removed. The convention that containerised processes log to the console is not style advice, it is the only path into this machinery. ## The default: json-file With no configuration at all, the driver is **json-file**. It appends one JSON object per line to a file on the host: ``` /var/lib/docker/containers/<container-id>/<container-id>-json.log ``` Each line looks like `{"log":"listening on 8000\n","stream":"stdout","time":"2026-09-03T10:14:02.118Z"}`. The file is owned by root and lives outside the container's writable layer, on whatever filesystem holds Docker's data root. Two consequences follow immediately: you need host root to read it directly, and it is *not* part of the container's own storage — a common misconception is that a container with a read-only root filesystem cannot fill the disk with logs, when in fact the daemon is doing the writing on the host's behalf. By default json-file applies **no rotation** at all, so the file grows for as long as the container runs. That is the single most common way a Docker host runs out of disk. ## The other drivers The engine ships several drivers besides json-file: - **local** — a compact, purpose-built file format that rotates and compresses by default; the sensible modern choice when you just want files on the host. - **journald** — hands each message to the systemd journal on the host, where `journalctl` can filter it by container name or id. - **syslog**, **gelf**, **fluentd**, **awslogs**, **gcplogs**, **splunk** — shipping drivers that send messages off the host to a collector or a cloud log service. - **none** — throws the messages away. The container still runs; it simply produces no logs anywhere. ## Setting the default, and overriding it per container The daemon-wide default lives in `/etc/docker/daemon.json`: ```json { "log-driver": "local", "log-opts": { "max-size": "10m", "max-file": "3" } } ``` and takes effect after the daemon is restarted. The crucial detail is *when* it is applied: the driver and its options are resolved at **container creation** and frozen into that container's configuration. Restarting the daemon with a new default does not re-configure the containers already on the host, and neither does `docker restart` — you have to remove and recreate the container for a new default to apply. `docker inspect` will show you what a given container actually got, under `HostConfig.LogConfig`. An individual container can always opt out: ``` docker run -d --log-driver=none noisy-batch-job:1.9 ``` Per-container overrides are how you handle the exception — a chatty batch job you do not want to keep, or one service that must go straight to a collector — without changing the policy for the whole host. Compose exposes the same two settings on a service under its `logging` key. ## Why the choice matters early Picking a driver is not just plumbing. It decides whether logs survive the container's removal, whether `docker logs` can show them to an on-call engineer, whether a slow log backend can stall the application, and how much host disk the fleet can consume. Leaving the default in place is a decision too — it means unbounded JSON files on the host, one per container, with no retention policy other than the lifetime of the container. There is also a cost consideration that is easy to miss. json-file stores each message as escaped JSON with a full RFC3339 timestamp and a stream name on every line, so a short log line can more than double in size on disk. For a service emitting a line per request that overhead is the dominant term in the log volume, and it is paid on the host's filesystem, on every read, and again in any compression the driver does. The `local` driver's binary format exists specifically to remove it. Finally, note that the lifetime of the log is the lifetime of the *container object*, not of the process. Restarting a container appends to the same file; removing the container deletes its directory, log files and all. Anyone who has run a container with `--rm` while debugging a crash has discovered the second half of that rule the hard way — the container exits, the engine removes it, and the evidence goes with it.