Should you build your own Supabase Pro?

Build a personal replacement for Supabase Pro in an empty repository.
Use Docker Compose, Caddy, PostgreSQL, Redis, and a small Go control plane; do not offer alternative stacks.
The core loop is: self-host a containerized Postgres backend with auth, storage, and a small API surface, route domains, retain logs, and perform backups on one user-owned server.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Accept a Git repository or container image and one explicit Dockerfile-based build path.
Implement applications, environments, secrets, domains, health checks, and rolling container replacement.
Use Caddy for automatic TLS and route only to healthy local containers.
Capture bounded build and runtime logs and expose restart, rollback, and redeploy actions.
Back up PostgreSQL metadata and document backups for each deployed application's data volumes.
Add host metrics, disk alerts, update instructions, disaster recovery, and a prominent single-server warning.
Include clear empty, loading, success, and recoverable error states.
Add input validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for the core transformation and one end-to-end happy path.
Create a README with setup, architecture, permissions, data location, and backup steps.
Do not add accounts, billing, telemetry, analytics, or a hosted control plane.
Deliberately leave out multi-region or serverless infrastructure.
Deliberately leave out managed data stores and global edge delivery.
Deliberately leave out DDoS response, compliance, and guaranteed uptime.
Finish by running the tests and listing the exact commands used.