Vps Docker Traefik Deploy

VPS Docker Traefik Deploy

Overview

Use this skill to turn an application stack into a real production deployment plan with secure host setup, reverse proxying, registry-based releases, private admin access, persistent storage, backups, and rollback.

Prefer Ubuntu LTS or Debian stable. Prefer immutable image tags. Prefer Traefik for public ingress and SSH tunnels for admin-only access.

Workflow

1. Establish facts before changing anything. 2. Minimize the public network surface. 3. Baseline the host with a non-root operator account. 4. Install Docker from the official stable channel. 5. Deploy Traefik separately from the app stack. 6. Keep state outside container writable layers. 7. Deploy app images by pull, not by rebuilding on the server. 8. Validate health, backup, restore, rollback, and pruning.

Establish Facts

Confirm these points first:

• operating system and version
• public domains and subdomains
• TLS strategy: HTTP challenge or DNS challenge
• public services: website, API, websocket, admin UI, registry
• private services: database, Redis, dashboards
• registry type: managed or self-hosted
• persistent data locations
• backup destination and retention
• restore expectations
• whether a single VPS is still acceptable

If the project already has deployment docs, read them first and treat them as the application-specific contract.

Public Exposure Rules

Default public ports:

• 22/tcp for SSH
• 80/tcp for HTTP redirect and ACME when needed
• 443/tcp for HTTPS

Keep these private unless there is a strong reason:

• Traefik dashboard
• MariaDB or PostgreSQL
• Redis
• private registry
• app service ports that can sit behind Traefik
• internal admin tools

If a GUI tool is required, bind the service to 127.0.0.1 only and use an SSH tunnel from the operator workstation.

Output Requirements

When using this skill, produce a deployment answer that includes:

• target topology
• exact public ports
• folder layout
• user and permission model
• Docker and Traefik install method
• DNS record plan
• Traefik routing plan
• registry flow
• persistent data plan
• storage growth plan
• backup and restore plan
• rollout and rollback commands

Mandatory Guardrails

• Do not recommend public exposure of database, Redis, registry, or proxy dashboards by default.
• Do not recommend deploying as the host root account.
• Do not recommend mutable latest tags for production.
• Do not keep important state only inside container writable layers.
• Do not call a plan complete unless backup and rollback are addressed.

Reference Files

Read these files only when needed:

• references/server-baseline.md

Use for Ubuntu 24.04 host prep, non-root users, SSH hardening, swap, firewall, Docker install.

• references/traefik-dns.md

Use for Traefik layout, dashboard tunneling, DNS, subdomains, Cloudflare, and routing patterns.

• references/registry-storage-backup.md

Use for private registries, image retention, bind mounts versus volumes, S3-compatible storage, backup, restore, and cleanup.

• references/deploy-checklist.md

Use for rollout steps, post-deploy verification, rollback, and maintenance cadence.

Deployment Checklist

Before First Deploy

• confirm OS and package baseline
• create non-root operator account
• harden SSH
• enable firewall
• create swap
• install Docker and Compose from the official stable channel
• create the proxy network
• deploy Traefik
• prepare DNS records
• prepare runtime env files
• prepare backup destination
• decide storage locations

Release Flow

1. Build immutable images. 2. Push them to the registry. 3. Export exact image tags on the server. 4. Run docker compose pull. 5. Run docker compose up -d. 6. Verify health endpoints and logs.

Public Exposure Check

Public:

• SSH
• HTTP
• HTTPS

Private:

• dashboard
• DB
• Redis
• registry
• internal app service ports

Post-Deploy Verification

• docker compose ps
• docker compose logs --tail=100
• website responds through Traefik
• API health responds through Traefik
• websocket handshake or health endpoint works
• background workers are healthy
• backup job still runs

Rollback

Rollback by image tag, not by rebuilding on the host.

1. export previous image tags 2. docker compose pull 3. docker compose up -d 4. re-run health checks

Maintenance Cadence

Daily:

• backup checks
• disk usage checks

Weekly:

• log review
• image or builder cleanup review

Monthly:

• restore test
• OS patch review
• Docker and Traefik patch review
• certificate and DNS audit

Registry, Storage, And Backup

Registry Strategy

Prefer:

1. managed private registry such as GHCR, ECR, GCR, or GitLab Container Registry 2. self-hosted registry bound to localhost or private network only

Avoid public anonymous registries for private production images.

Use immutable tags:

2026-04-21-001

Do not deploy latest.

Self-Hosted Registry Rule

If you run registry:2, bind it only to localhost unless there is a strong reason not to:

127.0.0.1:5000:5000

Then access it through SSH tunnel:

ssh -L 5000:127.0.0.1:5000 deploy@your-server
docker login 127.0.0.1:5000

Persistent Data

Keep important state outside container writable layers:

• database data
• Redis persistence if enabled
• uploaded files
• application storage directories
• registry data
• reverse proxy ACME state

Named volumes are acceptable. Bind mounts are often easier for operators when they need direct filesystem visibility, backups, or disk migration.

Storage Growth Plan

Plan for growth before disks fill up.

Typical path:

1. add a new disk or block volume 2. mount it under a stable path such as /srv/app-data 3. move DB, storage, or registry data there 4. update bind mounts or Docker volume targets

For file-heavy systems, move user-generated files to object storage:

• AWS S3
• Cloudflare R2
• MinIO
• Backblaze B2 via S3-compatible API
• any other S3-compatible system

Prefer:

• block storage for databases
• object storage for large uploads, exports, and archives

Backup Minimum

Always back up:

• database dumps
• file storage
• env files and secrets stored on the host
• ACME or TLS state if the proxy manages certificates

Restore Rule

A backup is incomplete until restore is tested.

Require:

• DB restore test
• storage restore test
• application boot check after restore

Image And Host Cleanup

App host cleanup:

docker image prune -a --filter "until=240h"
docker builder prune --filter "until=240h"

Registry cleanup:

• keep currently deployed tags
• keep rollback tags
• delete unused manifests or use registry retention rules
• run garbage collection during maintenance windows if the registry requires it

Server Baseline

Recommended Host

• Ubuntu LTS 24.04 or Debian stable
• 4 vCPU / 8 GB RAM / 80 GB SSD as a reasonable starting point for small production stacks
• add swap unless you have a deliberate no-swap policy

As of 2026-04-21, official stable references show:

• Docker Engine on Ubuntu 24.04: 29.4.0
• Docker Compose plugin latest release: 5.1.3
• Traefik latest active-support minor: 3.6

Re-check official release channels before provisioning a new production host.

Initial Packages

sudo apt update
sudo apt install -y \
  ca-certificates \
  curl \
  gnupg \
  lsb-release \
  jq \
  unzip \
  git \
  ufw \
  fail2ban \
  htop \
  ncdu \
  rsync

Non-Root Operator

sudo adduser --disabled-password --gecos "" deploy
sudo usermod -aG sudo deploy

Important:

• avoid day-to-day root logins
• the docker group is root-equivalent; add users there only if you accept that tradeoff

SSH Hardening

Prefer:

• SSH keys only
• PermitRootLogin no
• PasswordAuthentication no
• restricted AllowUsers

Example:

sudo sed -i 's/^#\\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

Swap

Example 4 GB swapfile:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swap.conf
sudo sysctl --system

Docker Install

Use Docker's official apt repository:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verify:

docker version
docker compose version

Firewall

Default public ports:

• 22/tcp
• 80/tcp
• 443/tcp

Example:

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

Only add more ports if the app genuinely requires them.

Traefik, DNS, And Private Admin Access

Network Model

Recommended public surface:

• 80/tcp
• 443/tcp

Recommended private-only services:

• Traefik dashboard
• database
• Redis
• private registry
• any admin endpoint

Create one shared external Docker network for proxied app containers:

docker network create traefik_proxy

Traefik Deployment Pattern

Run Traefik as a dedicated infrastructure stack, separate from the application stack.

Typical host layout:

/srv/traefik/
  compose/
  dynamic/
  letsencrypt/
  logs/

Recommended bind policy:

• 80:80
• 443:443
• 127.0.0.1:8080:8080 for the dashboard

Use file provider or labels. Prefer file provider when you want to keep app compose files cleaner.

Dashboard Access

Do not publish the dashboard on a public route by default.

Use an SSH tunnel:

ssh -L 8080:127.0.0.1:8080 deploy@your-server

Then open:

http://127.0.0.1:8080/dashboard/

Domain Layout

Recommended public hostnames:

inventory.example.com
api.example.com
ws.example.com

Avoid public DNS for:

registry.example.com
traefik.example.com

unless you have a real reason and proper hardening.

Cloudflare Guidance

For Cloudflare:

• A or AAAA records point to the server public IP
• Cloudflare proxy mode is acceptable for websites, APIs, and websockets
• use Full (strict) TLS
• use DNS challenge if you need wildcard certificates
• scope API tokens to a single zone only

WebSockets work through Cloudflare, so ws.example.com can usually remain proxied.

Other DNS Providers

Use the same record pattern:

• A or AAAA for each public hostname
• DNS challenge only if the provider supports it cleanly
• otherwise use HTTP challenge and keep ports 80 and 443 reachable

Routing Pattern

For separate subdomains:

• website -> http://<web-container>:80
• API -> http://<api-container>:80
• websocket -> http://<websocket-container>:3001

Traefik handles websocket upgrades automatically on standard HTTP routers; you do not need to expose websocket ports publicly just because the service is realtime.