Docker Logs Filling Your Disk? Set Limits and Verify Them

Imagine your small Docker server has been quiet for weeks. Then a worker starts repeating the same error, and the next deployment fails because the disk is full. The application image hasn’t changed much; the output it leaves behind has.

If Docker logs are filling your disk, confirm the affected container’s logging driver, set a bounded retention policy, and recreate that container during a planned change. Docker’s local driver rotates logs automatically; json-file needs rotation options. Changing daemon defaults alone won’t update existing containers. Start with the actual configuration, rather than assuming your server matches your laptop. Docker’s logging configuration guide explains these differences.

This is a hypothetical troubleshooting situation for a self-managed Linux Docker Engine host, including a Krova Cube. It isn’t an account of a Krova outage. You’ll need Docker access and permission to inspect the host; commands below are guidance, not results from a tested customer deployment.

First, work out which storage is growing

Before removing anything, separate three questions: which filesystem is full, which Docker objects occupy space, and what each container retains. Run these on the machine hosting the daemon. If your Docker context points to a remote host, your laptop’s filesystem figures won’t describe that server.

df -h
df -i
docker info --format 'root={{.DockerRootDir}} default-log-driver={{.LoggingDriver}}'
docker system df -v
docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'

df -h shows filesystem capacity; df -i checks inode availability. Docker’s disk-usage command helps you inspect images, containers and volumes. Treat it as one view of storage, not a complete explanation of every byte used by the operating system. A large database volume, build cache, application file or system journal calls for a different investigation than stdout logs.

Pick a suspect container by name. Here worker is a placeholder: replace it with a name from your own list.

docker inspect --format '{{json .HostConfig.LogConfig}}' worker
docker inspect --format '{{.LogPath}}' worker
docker logs --since 10m --tail 100 worker

The first command shows that container’s driver and options; the second reports its log path where available. Docker inspect exposes both object details and the log path. A short log sample can reveal repeated failures, but it isn’t a measurement of total disk usage. Keep credentials and personal data out of copied diagnostic output.

Choose retention around the time you need to investigate

There are two reasonable paths. Use local when you want bounded local logs and your collection pipeline supports it. Keep json-file with explicit limits when a collector depends on that format. Before switching drivers, check how your log shipper reads containers; compatibility is part of the decision.

The local driver defaults to five files of 20 MB per container, with compression of rotated files. Those defaults are a starting point, not a retention promise. A noisy worker can use its available history much faster than a quiet web service.

For a planning example, suppose a worker produces 2 MB of uncompressed log output per minute. A nominal 30 MB allowance represents roughly 15 minutes of output: 30 ÷ 2 = 15. Across five equally configured containers, 3 files × 10 MB × 5 containers gives about 150 MB of nominal log-file capacity. This is illustrative arithmetic, not a measured workload or a filesystem quota; compression, metadata and rotation behavior affect actual usage.

Ask whether 15 minutes gets you through an alert, an investigation and a handoff. If it doesn’t, reduce unnecessary verbosity or send required history to a collector with an explicit retention policy. Raising a local limit without estimating the rate simply postpones the same decision.

Apply the policy to one Compose service

For an existing Compose stack, an explicit service policy makes the intended behavior visible beside the deployment. Add this section under the service you already run; it’s a fragment, not a complete application definition. The example chooses the local driver and a nominal three-file, 10 MB rotation policy.

services:
  worker:
    # Keep the existing image, environment, mounts and other settings.
    logging:
      driver: local
      options:
        max-size: "10m"
        max-file: "3"

Compose documents logging as a service configuration. If you need JSON logs for your collector, use driver: json-file with these rotation options instead. In either case, review the retention requirement before copying the example values.

docker compose config
# After reviewing configuration, persistence and the maintenance window:
docker compose up -d --no-deps --force-recreate worker

Compose’s up reference documents recreation and its preservation of mounted volumes. --no-deps narrows this operation to the selected service; it doesn’t make the application immune to dependency or readiness problems. Confirm the application is healthy before changing another service.

Verify the new container, then watch a real workload

docker compose ps worker
docker inspect --format '{{json .HostConfig.LogConfig}}' "$(docker compose ps -q worker)"
docker compose logs --since 5m --tail 100 worker
df -h

Check that the replacement shows the intended driver, max-size and max-file. Then exercise the application’s normal health check and observe free space and useful log history through a representative workload. A correct configuration readback proves the settings were attached; it does not prove the retention window meets your needs.

If disk usage still grows, return to the storage investigation. Logging drivers handle container stdout and stderr; they don’t cap a file the application writes into a mounted directory. A retry loop also still needs its underlying error fixed. Rotation gives the failure a smaller storage budget; it doesn’t resolve the failure.

Make the next deployment inherit the decision

After the service change works, decide whether to adopt a host-wide default. Docker supports log-driver and string-valued log-opts in the daemon configuration. Merge changes into the existing configuration rather than overwriting unrelated settings, and plan the daemon restart. Existing containers still require recreation to adopt changed defaults. Daemon configuration and scope

If you use remote logging, don’t assume that means zero local storage. Docker can maintain a rotating local cache for drivers that cannot read logs; review the cache and delivery limitations in its dual logging documentation. Keep operational debugging history and any required audit retention as separate requirements.

Where this fits on a Krova Cube

Krova’s Docker workload page describes running standard Docker Engine and Compose inside a Cube with its own kernel and root access. That gives you control over the container host. You still need to choose its logging policy, retention and monitoring. This procedure is for self-managed Cube workloads; it doesn’t describe Nest managed hosting.

If you’re already running Docker on a Cube, start by inspecting one busy service and recording its retention requirement. If you’re choosing where to deploy, size disk for images, persistent application data and operational headroom as well as logs. An isolation boundary and a storage budget solve different problems.

Creation context: this guide and its cover were produced with AI assistance using the linked documentation. The scenario and capacity arithmetic are illustrative; no hands-on benchmark, customer incident or human review is claimed. Documentation checked on 4 November 2026 IST.