Deploy any Docker app to a $5 VPS with automatic HTTPS, CI/CD, and backups

Managed platforms are wonderful until the invoice arrives. For most side
projects and early products, a $5 VPS runs the whole thing comfortably. The
reason people stay on the expensive platforms is not the money, it is the
setup: TLS certificates, a database that is not exposed to the world, a deploy
process that does not break at 2am, and backups you can actually restore.

This is the setup I use on every box, written out so you can copy it. By the
end you will have any Dockerized app live on your own server with automatic
HTTPS, push-to-deploy from GitHub, and nightly encrypted backups.

Nothing here is exotic. It is the boring, reliable version, which is exactly
what you want for infrastructure.

What you will build

One server, one app, one database. On purpose. Simple enough to read top to
bottom and cheap enough to run for a few dollars a month.

• Traefik as the edge router, terminating TLS with automatic Let's Encrypt certificates and redirecting HTTP to HTTPS
• Your app in a container behind the router
• Postgres on a private Docker network that is never published to the internet
• GitHub Actions that builds your image and deploys over SSH on every push
• A nightly backup that dumps the database, encrypts it, ships it offsite, and can be restored with one command

Step 1: Provision and harden the server

Start with a fresh Ubuntu or Debian box from Hetzner, DigitalOcean, or similar.
Before anything else, do not run your app as root on an unhardened machine.

The essentials, run once as root:

• Create a non-root sudo user and copy your SSH key to it
• Install Docker and the compose plugin
• Turn on a firewall that denies everything except SSH, HTTP, and HTTPS
• Install fail2ban to ban brute-force SSH attempts
• Enable automatic security updates
• Add a small swap file so a memory spike does not kill the box

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable

Once your key works for the new user, disable root login and password auth in
SSH entirely. Always confirm a fresh SSH session works before closing your
current one.

Step 2: Traefik for automatic HTTPS

Traefik watches Docker and configures itself from container labels. Point your
domain's A record at the server, and Traefik requests a Let's Encrypt
certificate the first time a request comes in.

services:
  traefik:
    image: traefik:v3.1
    restart: unless-stopped
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--certificatesresolvers.le.acme.email=[e-mail]"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "letsencrypt:/letsencrypt"

No certbot, no renewal cron. Traefik handles issuance and renewal itself.

Step 3: Your app and Postgres on a private network

The trick that keeps you safe: two networks. The app sits on an edge network
that Traefik can reach, and an internal network shared with Postgres. The
database is only on internal, so it is never reachable from the public
entrypoints.

  app:
    image: ghcr.io/you/your-app:latest
    restart: unless-stopped
    env_file: .env
    depends_on:
      db:
        condition: service_healthy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`yourdomain.com`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.routers.app.tls.certresolver=le"
      - "traefik.http.services.app.loadbalancer.server.port=3000"
    networks: [edge, internal]

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks: [internal]

The depends_on healthcheck means your app waits for the database to be ready
before it starts, so you do not get connection errors on boot.

Step 4: Push-to-deploy with GitHub Actions

You do not want to SSH in and pull every time you ship. This workflow builds
your image, pushes it to the GitHub Container Registry, and updates the server
over SSH on every push to main.

name: deploy
on:
  push:
    branches: [main]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          context: ./app
          push: true
          tags: ghcr.io/${{ github.repository }}:latest
      - uses: appleboy/ssh-action@v1.2.0
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /home/deploy/app
            docker compose pull
            docker compose up -d --remove-orphans
            docker image prune -f

Set the four secrets in your repo settings and you are done. Every push ships.

Step 5: Backups you have actually restored

A backup you have never restored is not a backup. The script below dumps
Postgres, compresses and encrypts it, keeps a week locally, and uploads offsite
to any S3-compatible bucket.

docker compose exec -T db pg_dump -U appuser appdb | gzip > db.sql.gz
gpg --batch --passphrase "$BACKUP_PASSPHRASE" --symmetric \
  --cipher-algo AES256 -o db.sql.gz.gpg db.sql.gz
aws s3 cp db.sql.gz.gpg "s3://your-bucket/$(date +%F).sql.gz.gpg"

Schedule it nightly with cron:

0 3 * * * /home/deploy/app/backup.sh >> /var/log/backup.log 2>&1

Then, and this is the part everyone skips, test a restore. Drop a table on a
staging copy, run your restore script, and confirm the row count matches. Do it
now, not during an outage.

What this costs, and when not to do it

A small Hetzner or DigitalOcean box is a few dollars a month and runs most side
projects without breaking a sweat. You own the stack and there is no per-seat
or per-request markup.

This is a single-server setup. It is not for multi-region, zero-downtime
rollouts, or anything that needs managed-database failover. If you need those,
stay on a managed platform. For everything else, this is plenty, and it is
yours.

If you would rather not assemble it yourself

I packaged exactly this, the hardening, Traefik with auto HTTPS, the app and
Postgres wiring, the GitHub Actions deploy, and the backup and restore scripts,
into a tested kit with a runnable demo so you can confirm it works before you
touch your own server. There are companion kits for monitoring (Grafana,
Prometheus, Uptime Kuma), deeper server hardening, and backups, and a bundle
with all four.

If your cloud bill feels too big for what you actually run, it is here:
https://katari85.gumroad.com/l/qoxpr

Either way, copy the setup above and stop paying markup for a server you could
own.