Capstone: Deploying a SaaS Application

We will orchestrate the entire deployment using a production-hardened compose.yaml.

# compose.yaml
name: saas-production
 
# Define a custom bridge network for internal DNS
networks:
  saas_net:
    driver: bridge
 
# Define persistent volumes for stateful data
volumes:
  pgdata:
  redisdata:
 
services:
  # ----------------------------------------
  # 1. PostgreSQL Database
  # ----------------------------------------
  db:
    image: postgres:15-alpine
    networks:
      - saas_net
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      POSTGRES_DB: saas_prod
    secrets:
      - db_password
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 1G
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U admin -d saas_prod"]
      interval: 10s
      timeout: 5s
      retries: 5
 
  # ----------------------------------------
  # 2. Redis Cache
  # ----------------------------------------
  cache:
    image: redis:7-alpine
    networks:
      - saas_net
    volumes:
      - redisdata:/data
    command: redis-server --appendonly yes # Persist data to disk
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 256M
 
  # ----------------------------------------
  # 3. Node.js API
  # ----------------------------------------
  api:
    build:
      context: ./api
    networks:
      - saas_net
    # Note: No published ports! Traffic must flow through Nginx.
    environment:
      NODE_ENV: production
      REDIS_URL: redis://cache:6379
    secrets:
      - db_password
    # Reads the same file-based secret Postgres uses, instead of a plain
    # environment variable — keeping the DB password out of `.env`/`docker inspect`,
    # consistent with the secrets-handling guidance in Module 7.
    # `command:` (not `entrypoint:`) so the Dockerfile's `dumb-init` ENTRYPOINT
    # still becomes PID 1 and handles SIGTERM correctly, per Module 3.
    command: ["sh", "-c", "export DATABASE_URL=postgres://admin:$$(cat /run/secrets/db_password)@db:5432/saas_prod && exec node dist/server.js"]
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 512M
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "3"
 
  # ----------------------------------------
  # 4. Nginx Reverse Proxy
  # ----------------------------------------
  nginx:
    image: nginx:alpine
    networks:
      - saas_net
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro # Read-only mount
      - ./certs:/etc/nginx/certs:ro
    depends_on:
      - api
    restart: unless-stopped
 
# Define file-based secrets
secrets:
  db_password:
    file: ./secrets/db_password.txt

---

Step 2.5: The Nginx Reverse Proxy and TLS Certificates

The nginx service mounts two files from the VPS: ./nginx.conf and ./certs. Here's what actually goes in them.

./nginx.conf terminates TLS and proxies everything else to the api container over saas_net:

# nginx.conf
events {}
 
http {
  server {
    listen 443 ssl;
    server_name saas.example.com;
 
    ssl_certificate     /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;
 
    location / {
      proxy_pass http://api:8080;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
    }
  }
 
  server {
    # Redirect all plain HTTP to HTTPS
    listen 80;
    server_name saas.example.com;
    return 301 https://$host$request_uri;
  }
}

The certificate files it expects — fullchain.pem and privkey.pem — come from Let's Encrypt via certbot, run once on the VPS host (outside the saas_net containers, since it needs to bind port 80 briefly to prove domain ownership):

sudo certbot certonly --standalone -d saas.example.com
sudo cp /etc/letsencrypt/live/saas.example.com/*.pem ./certs/

Certbot's certificates expire every 90 days, so a cron job (certbot renew, plus a docker compose restart nginx to pick up the refreshed files) keeps this from silently breaking in production.

---

Step 3: Analyzing the Architecture

Why did we build it this way?

1. Isolated Networking

Notice that the db and cache services do not have a ports directive. They are completely inaccessible from the public internet. The only way to talk to PostgreSQL is to be on the saas_net internal bridge network.

Similarly, the api service does not publish port 8080. Instead, Nginx binds to ports 80 and 443 on the host, accepts public internet traffic, handles SSL, and proxies the traffic internally over saas_net to the API container.

2. Log Management

We explicitly limited the Node.js API logs to max-size: "50m" with 3 rolling files. If the API gets hit by a massive spike in traffic, it will not fill up the Linux VPS hard drive and crash the server.

3. Graceful Boot Sequencing

By combining the pg_isready healthcheck with depends_on: condition: service_healthy, Compose guarantees that the Node.js API will not boot until the database is fully ready to accept queries.

---

Step 4: The Deployment Workflow

If you SSH into your Linux VPS, your deployment workflow is simple, repeatable, and completely declarative:

1. Create the ./secrets/db_password.txt file — both db and api read the database password from this single file-based secret.
2. Run the deployment:

docker compose up -d --build

Docker will build the minimal multi-stage image, create the internal networks, provision persistent volumes, boot the database, wait for it to become healthy, boot the API, and finally boot the Nginx proxy.

---

Conclusion

Congratulations. You have completed the Docker In-Depth curriculum.

You are no longer a developer who just memorizes docker run. You understand how the Linux kernel provides namespaces and cgroups. You know how OverlayFS layers dictate caching strategy. You understand the dangers of PID 1, the risks of running as root, and how to orchestrate complex services securely.

You are now equipped to engineer, secure, and operate Docker containers in high-stakes production environments.

---