Docker Log Rotation Limits Space, Not Days of History

Docker log rotation can bound the recent container output kept on a home server, but it does not promise a fixed number of days of history. A quiet service and a failing service can consume the same allowance at very different speeds. Choose the storage policy and the evidence-retention policy separately.

Start with the stream, not the folder name

Docker's file-based logging drivers capture a container's standard output and standard error. That is a specific source of messages, not every file an application creates. An application that writes its own diagnostic files inside a mounted directory needs a separate retention policy for those files. Changing a container's logging driver does not make that directory part of Docker's rotation mechanism.

This distinction matters on a self-hosted media server: container output, application logs and the media library can share a physical disk while belonging to different storage budgets. First identify which writer owns the growing data. The local driver documentation defines the captured streams and warns against manipulating its internal files with external tools.

File limits describe a rolling window of bytes

The local driver rotates automatically and compresses rotated files by default. Docker documents its default allowance as 100 MB of messages per container before the benefit of compression. That is not a reservation for a particular week, nor a complete upper bound for everything on the Docker filesystem.

The JSON-file driver behaves differently: its default size setting is unlimited. Setting only a file count is not enough; Docker documents that its max-file setting depends on an accompanying max-size setting. Read the JSON-file options rather than assuming a container inherits a safe retention window.

When the oldest rotated file is removed, the remaining history covers whatever interval fits. A burst of repeated errors can displace the useful messages from before the failure. If the household needs evidence from a known date, local rotation alone cannot establish that promise.

Choose the format around its consumers

For ordinary container workloads without another logging requirement, Docker recommends the local driver because it rotates by default and uses an efficient internal format. JSON-file remains the daemon default for compatibility reasons. Neither driver is a reason to let an external script truncate Docker-owned files. Both driver references warn that direct interference can disrupt logging.

Before changing formats, inventory anything that collects or processes the existing logs. A collector expecting JSON files is a dependency to review, not proof that every service must retain the same driver indefinitely. The logging configuration guide describes other drivers for destinations such as syslog and journald; their retention decisions belong to those systems as well.

Read the container policy, not only the daemon default

These read-only checks require access to the intended Docker daemon. Docker administration is privileged access; do not grant it broadly merely to inspect logs. This discussion concerns Docker Engine container logging, not a universal policy for Kubernetes or application-managed files.

Use docker info --format '{{.LoggingDriver}}' to inspect the daemon's current default. To examine one actual container, replace CONTAINER with its name or ID:

docker inspect --format '{{json .HostConfig.LogConfig}}' CONTAINER

The expected result identifies the container's driver and its explicit options. Empty options do not mean unlimited storage for every driver: the selected driver's defaults still matter. Conversely, a daemon default of local does not prove an older container uses it.

Docker applies new daemon logging defaults to newly created containers; existing containers keep their earlier configuration. A migration therefore needs a planned recreation, preserved application data and a service-specific rollback plan. A daemon restart by itself is not evidence that the old container changed.

Delivery buffers trade missing messages for responsiveness

Rotation controls stored history. Delivery mode controls what happens while messages travel from the process to the logging driver. Docker's default mode is blocking; non-blocking delivery adds a finite intermediate buffer. When that buffer fills, new messages are dropped rather than queued.

Consequently, non-blocking mode is not a stronger evidence guarantee. It can protect application responsiveness from logging back pressure while leaving gaps in diagnostics. Increasing the buffer is also not equivalent to adding durable retention. Choose the trade-off deliberately when investigating a busy NAS or a repeatedly failing container.

Budget for diagnosis rather than an attractive number

A useful homelab policy answers a small set of questions:

• Which messages come from container streams, and which are application-owned files?
• Does each running container have the intended driver and options?
• How far back does the surviving history reach during an error burst?
• Does a collector need a particular format or an independent archive?
• Is missing a message preferable to delaying the application?

Keep spare disk capacity as well as a retention policy. Docker notes that reading compressed rotated logs can temporarily require additional disk space and CPU work. Rotation is a control on one source of growth, not a guarantee against a full disk. The useful outcome is recent diagnostic evidence with understood limits—not a file count mistaken for a calendar.