Docker Compose in Production: Security Hardening, Caddy & Automated Backups

Introduction to Robust Production Orchestration with Docker Compose

The Docker ecosystem has transformed how we package and distribute applications, but transitioning from local development environments to production servers demands severe architectural rigor. Historically relegated to testing and staging environments due to misconceptions about its scalability, Docker Compose has evolved into a perfectly viable tool for monolithic or small-to-medium microservices workloads, provided it is accompanied by strict reliability engineering and infrastructure security standards.

In production scenarios, the convenience of launching multiple containers with a single YAML file cannot come at the expense of security concessions. Leaving database ports exposed directly to the public interface, running internal processes with root privileges inside the container, or neglecting the rotation and encryption of data snapshots are critical flaws that compromise the operational integrity of any modern software architecture.

This article explores in detail the fundamental guidelines to harden your Docker Compose-based infrastructure, implementing the principle of least privilege, strict overlay and bridge network isolation, the adoption of an elegant reverse proxy with Caddy Server and automated TLS, alongside an automated and resilient cloud backup routine.

Security Hardening Principles and Non-Root Users

The first attack vector in containerized environments exploits the default configuration where application processes run under the root user (the all-powerful system administrator account) inside the container namespace. If a remote code execution (RCE) vulnerability (a flaw allowing malicious code to run over the network) occurs in the tech stack, the attacker immediately gains administrative privileges over the container's file system and, depending on host kernel isolation flaws, can escalate privileges to the host machine. Mitigating this risk requires explicitly specifying unprivileged UIDs and GIDs (numeric identifiers for users and groups) in Dockerfiles and Compose manifests.

Beyond user restriction, hardening requires dropping unnecessary Linux capabilities (granular system permission switches) and mounting root filesystems as read-only (read_only: true), with targeted persistent volumes for temporary data directories and logs. These guidelines block attempts at malicious modification of internal operating system binaries and drastically reduce the attack surface of the application exposed to external traffic.

version: '3.8'
services:
  app:
    image: registry.internal/app:v1.2.0
    user: "10001:10001"
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    volumes:
      - tmp-data:/tmp
    networks:
      - internal
volumes:
  tmp-data:
networks:
  internal:
    internal: true

Advanced Network Topology and Database Isolation

Network architecture in Docker Compose is frequently overlooked, resulting in scenarios where databases such PostgreSQL, Redis, or MySQL remain accessible through unnecessary network interfaces. Rigorous isolation dictates that no persistent storage service should have ports mapped directly to the host (ports directive), communicating exclusively through internal and private Docker networks, where internal DNS name resolution manages inter-service traffic.

To achieve this level of isolation, we separate the infrastructure into distinct networks: an external network (usually managed by the reverse proxy for HTTP/HTTPS traffic entry) and isolated internal networks for data persistence. The internal: true directive in the network definition ensures that containers connected to it have absolutely no egress route to the public internet, eliminating data exfiltration vectors if lateral compromise occurs on the internal network.

networks:
  public_net:
    driver: bridge
  database_net:
    driver: bridge
    internal: true
services:
  database:
    image: postgres:15-alpine
    networks:
      - database_net
    environment:
      POSTGRES_DB: production
    volumes:
      - pgdata:/var/lib/postgresql/data
  backend:
    image: my-backend:latest
    networks:
      - database_net
      - public_net

Elegant Reverse Proxy with Caddy and Automatic SSL

TLS certificate management (the cryptographic security protocol that secures web browsing) and HTTP traffic routing in traditional environments required complex and extensive configurations in Nginx or Apache, accompanied by Certbot renewal scripts. Caddy Server redefines this experience by natively automating the provisioning, monitoring, and renewal of SSL/TLS certificates via Let's Encrypt or ZeroSSL, requiring very few lines in its Caddyfile configuration and integrating fluidly into the Docker Compose ecosystem.

In the Compose file, Caddy acts as the sole entry port exposed to the outside world (ports 80 and 443), intercepting HTTPS requests and reverse-proxying them to internal application containers via Docker's internal DNS. This approach simplifies HTTP security header management, automatic HTTP to HTTPS redirects, and basic load balancing between microservice instances.

api.marciocunha.net {
    reverse_proxy backend:8080 {
        header_up Host {http.reverse_proxy.upstream.host}
        header_up X-Real-IP {http.remote_host}
        header_up X-Forwarded-For {http.remote_host}
        header_up X-Forwarded-Proto {http.scheme}
    }
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
    encode gzip zstd
}

Automated Snapshot, Compression, and Cloud Backup Routines

No production architecture can be considered complete without a rigorous and tested disaster recovery strategy. Relying on manual snapshots or sporadic copies of Docker volumes is an invitation to operational collapse. Reliability engineering requires automating database dump routines, encrypted compression of resulting files, and immediate synchronization with long-term cloud storage, such as AWS S3 or S3-compatible buckets.

We can implement this routine by encapsulating the process in a dedicated container running shell scripts triggered via internal cron jobs (automated background task schedulers) or managed by external orchestrators, mounting database persistent volumes in read-only mode for secure dump extraction. Backup rotation follows strict retention policies (GFS strategy - Grandfather-Father-Son), ensuring daily, weekly, and monthly snapshots are generated without consuming infinite storage space.

#!/usr/bin/env bash
set -euo pipefail
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
BACKUP_DIR="/backups"
DB_CONTAINER="production_db_1"
DB_NAME="production"
DB_USER="postgres"

echo "[+] Starting database dump..."
docker exec -t ${DB_CONTAINER} pg_dump -U ${DB_USER} ${DB_NAME} | gzip > "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz"

echo "[+] Encrypting compressed archive..."
openssl enc -aes-256-cbc -salt -in "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz" -out "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz.enc" -k "${BACKUP_ENCRYPTION_KEY}"
rm "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz"

echo "[+] Uploading to cloud storage..."
aws s3 cp "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz.enc" "s3://${S3_BUCKET_NAME}/backups/db_${TIMESTAMP}.sql.gz.enc"

echo "[+] Cleaning up local backups older than 7 days..."
find ${BACKUP_DIR} -type f -name "*.enc" -mtime +7 -delete
echo "[+] Backup process completed successfully."

Conclusion and Actionable Practices for Resilient Infrastructures

Managing production environments with Docker Compose does not mean abandoning the advanced security, observability, and resilience standards found in more complex orchestration ecosystems like Kubernetes. By rigorously applying internal network isolation, running containers with unprivileged users, elegant routing provided by Caddy Server, and automated encrypted backup pipelines, we build a lightweight, auditable, and highly stable infrastructure.

As a final recommendation for architects and software engineers, establish periodic restore drill routines. A backup that has never been tested for restoration is essentially a nonexistent backup. Validate your disaster recovery documentation quarterly and keep your configuration files versioned and subjected to rigorous code reviews, ensuring the longevity and security of your systems in production.