Docker in production without the drama

Docker gets sold as the thing that makes deployment simple. It does — right up until the first time a container eats the disk, or a restart wipes data nobody knew was inside it.

The three mistakes we see most

Data living inside the container. If it is not on a named volume or a bind mount, it disappears the moment you rebuild. This is the most common and most expensive mistake.

No resource limits. One container with a memory leak can take down every other service on the machine. A few lines in the compose file prevent it.

Logs growing forever. By default Docker keeps every line ever written. We have seen 40 GB of logs fill a disk and take a production site down.

services:
  app:
    image: myapp:latest
    restart: unless-stopped
    volumes:
      - app-data:/var/lib/app      # datos fuera del contenedor
    deploy:
      resources:
        limits:
          memory: 512M            # un fallo no tumba el resto
    logging:
      driver: json-file
      options:
        max-size: "10m"           # los logs no comen el disco
        max-file: "3"

Portainer is worth it

You can do everything from the terminal, but a visual panel changes who can help. When a client can see their own containers, restart one and read the logs without calling you, everyone wins.

Backups are not optional

A container is disposable. Its volumes are not. Whatever backup routine you have, verify that it actually covers the volumes, and — this is the part people skip — verify that a restore works. A backup you have never restored is a hypothesis.