Should you build your own Fly.io?

Build a closest honest personal substitute for Fly.io 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: deploy one container on a user-owned server, route domains, retain logs, perform backups, and expose operational limits clearly.
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.
Do not claim to reproduce proprietary data, network liquidity, regulated access, or frontier infrastructure.
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.