One-Box Server: Several Apps + Self-Hosted Supabase on 1 VPS

When every small app needs its own hosting project and its own database project, the bills grow with the number of apps, not the traffic. This skill is the template of a real setup that runs several apps on one VPS, generalised (app1, example.com) and with the mistakes it made written down.

Fit check first

It starts by asking what you run today, how many apps and roughly how many visits, then answers in one line whether this fits. It does not fit if you need zero downtime or multiple regions, nobody can answer alert mails, or you rely on Realtime, Edge Functions or a hosted dashboard.

What you get (templates/)

• bin/dc — dc <app> <compose args> with fixed project name, folder, env file and compose file.
• edge/ — one Caddy for TLS and routing of every host. Applied with caddy reload (a bad file is rejected and the old config keeps serving).
• ops/ — server prep (swap, Docker, firewall, unattended upgrades, timezone), key generation (Postgres password, JWT secret, anon/service JWTs, cron secret), DB bootstrap, env merge, SQL migrations recorded like the Supabase CLI (file and record in one transaction), host-side cron caller, alert mails (one per key per 6 hours, with the count held in between), hourly health check (disk, memory, OOM, containers, certificates, last backup), nightly backup to any S3-compatible bucket, monthly restore drill into a throwaway container, rollback of the app container only.
• app/ — per-app compose, Dockerfile (Next.js standalone), deploy.sh (clean main, gate, push, build on the server, wait for healthy, fall back to the previous image if it does not come up; stops and lists pending migrations instead of applying them), env-push.sh (only allowed names, refuses if a required one is missing).
• gotchas.md — 44 traps hit in practice, one line each with the reason. Examples: Ubuntu cron ignores CRON_TZ; compose --env-file cuts values at $; grep -q after a pipe with pipefail turns a match into a failure; PostgREST needs notify pgrst, 'reload schema' after a migration; restarting the Caddy container with a bad file takes every host down.

Rules it follows on a server

• Dump before any production DB write, say what will change, wait for an explicit yes.
• Never print secrets (cat .env, env, docker inspect, compose config are off limits; it checks names only).
• Touch one app at a time. No edge restarts, no prune -a, no volume deletes.
• Fix the cause when a check fails; never silence the alert.

Instructions are in Korean; scripts and comments are in English.

Source: https://github.com/Stophyuk/solutionzip-skills