coolify-vps-baseline

A production VPS exposes two ports to the world, runs every workload as a Coolify resource behind one proxy, builds nothing itself, and is observed. Establish those facts before any application is deployed, and verify them read-only before changing anything on a server that already serves traffic.

Hard rules: never break these

• The server never builds. Images are built in CI and pulled from a registry. A build on the host competes with production for CPU and memory and hangs on registry installs.
• Never publish container ports on the host. Only the proxy listens on 80 and 443; everything else is reached through the Docker network. A -p or Coolify port mapping on an app is a firewall bypass.
• Do not touch the firewall, fail2ban, sshd or the proxy config without the owner's explicit go. A wrong rule locks everyone out; the owner runs those commands, you give them exact lines.
• One SSH session, reused. Port 22 is usually rate limited; open a ControlMaster connection once and multiplex every command through it (see Step 1).
• Read before you write. Capacity, running containers, firewall state and registry login are facts to read first; report them before proposing changes.

Step 1: Connect once and read the server

# ~/.ssh/config: Host <alias>, HostName <ip>, User <user>, IdentityFile ...
S=~/.ssh/<alias>.sock   # a short path; long socket paths fail silently
ssh -o ControlMaster=auto -o ControlPath=$S -o ControlPersist=30m <alias> true
ssh -o ControlPath=$S <alias> 'free -h; df -h /; nproc; sudo docker stats --no-stream --format "{{.Name}}\t{{.MemUsage}}"'
ssh -o ControlPath=$S <alias> 'sudo ufw status verbose; sudo docker ps --format "{{.Names}}\t{{.Ports}}\t{{.Status}}"'

Record: RAM and disk headroom, what already runs, which containers publish host ports (ideally only the proxy), and the OS version. The checklist in reference/server-checklist.md lists every item to confirm on a fresh or inherited server, with the command for each.