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"

      - "[email protected]"

      - "--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/[email protected]

        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.