Background: The Full Disk Nightmare
Have you ever been woken up at 3 AM because a server crashed, only to discover the hard drive was at 100% capacity? I once learned a bitter lesson while deploying a microservices system for an e-commerce project. Due to an oversight where logs were left in debug mode without any size limits, a single log file ballooned to 65GB in just 48 hours. As a result, it consumed the entire root partition of the VPS.
By default, Docker uses the json-file logging driver. This driver silently records all output (stdout/stderr) into a JSON file on the host. If left unrestricted, this file will grow indefinitely until the disk has no bytes left. At that point, databases stop writing, services fail in a chain reaction, and you’ll spend your whole morning cleaning up the mess.
To avoid this horror scenario, Log Rotation is a mandatory technique. Simply put, it helps you control log file sizes and automatically deletes old records when they exceed a certain threshold.
3 Effective Ways to Configure Container Log Limits
Depending on whether you are running a single container or managing an entire server cluster, choose one of the three approaches below.
1. Quick Configuration with Docker Run
This method is suitable when you need to quickly test a single container. You just need to add the --log-opt flag directly to the startup command.
docker run -d \
--name nginx-proxy \
--log-driver json-file \
--log-opt max-size=10m \
--log-opt max-file=3 \
nginx
Parameter explanation:
max-size=10m: When the log file reaches 10MB, Docker will perform a rotation.max-file=3: The system only keeps a maximum of 3 oldest log files. When a 4th file appears, the oldest one is deleted.
2. Setting it up in Docker Compose
In practice, we usually work with Docker Compose. Including log configuration in the .yml file helps you manage infrastructure as code (IaC), making it easy to reuse when migrating servers.
services:
api-service:
image: node:18-alpine
logging:
driver: "json-file"
options:
max-size: "50m"
max-file: "5"
db-postgres:
image: postgres:15
logging:
driver: "json-file"
options:
max-size: "20m"
max-file: "3"
Pro tip: For critical services like Databases, you should increase max-file to about 5-10 files. This makes tracing past errors much easier.
3. Global Configuration for the Entire Server (Recommended)
This is the most effective “set and forget” method. Instead of configuring each container individually, you set global rules for the Docker Daemon. Every new container created thereafter will automatically follow these rules.
Open (or create) the Docker configuration file at /etc/docker/daemon.json:
sudo nano /etc/docker/daemon.json
Paste the following content into the file:
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
Finally, restart Docker to apply the changes:
sudo systemctl restart docker
Important Note: Restarting the Docker Daemon will temporarily disconnect running containers. Additionally, this configuration only affects newly created containers. Existing containers will retain their old configuration until you recreate them.
Quick Fixes When the Disk is 100% Full
If you are reading this while your server is already “gasping for air,” don’t rush to use the rm command to delete log files. Docker might not release the disk space immediately because the files are still being held by active processes. The proper way is to truncate the files:
# Empty all Docker log files immediately
sudo sh -c "truncate -s 0 /var/lib/docker/containers/*/*-json.log"
This command will reduce the size of all log files to 0 bytes instantly, allowing your server to “breathe” again without needing to restart services.
Conclusion
Log management is often overlooked by junior developers in local environments. However, in Production with millions of requests, logs are a double-edged sword.
My advice is to always configure daemon.json as soon as you set up a new server. If your application requires long-term log storage for analysis, push them to specialized systems like ELK Stack or Graylog instead of letting them “corrode” your application server’s hard drive. Don’t let a tiny text file take down a massive system!

