A Solo Developer's Deploy Checklist: Docker, Cloud Run, and Supabase

When you are the whole team, nobody reviews your deploy. The checklist is the reviewer. This is the one I run before a client API goes live, distilled from Docker in Production, GCP Production Architecture, Supabase and PostgreSQL, and the full stack overview.

1. The image

• Multi-stage Dockerfile: build tools stay out of the production image.
• The same image runs locally, in CI, and in production. No "works on my machine" build.
• A health endpoint exists and returns fast without touching slow dependencies.
• Images are tagged and referenced by immutable digest, so rollback means pointing at the previous one.
• Local Compose runs against a Postgres that matches production.

2. The runtime

• Image lives in Artifact Registry and deploys to Cloud Run. No custom process manager.
• Region chosen near your users. For Asia-heavy traffic, pricing and latency favoured GCP.
• CPU throttling is on. Do not pass `--no-cpu-throttling` unless you can prove you need it. It opts you into always-on billing.
• Background work is not done after the response. Return 200 fast and enqueue a Cloud Tasks job so CPU can scale to zero. This is the fix behind the 80% bill cut.
• Min and max instances are set deliberately, not left at defaults.

3. The data

• Orders, inventory, bookings, and riders are relational. Use PostgreSQL, with Prisma as the typed access layer.
• Supabase handles Auth and row-level security for multi-user access.
• Payments and vendor calls stay in your API, not in the client.
• Migrations run as a deliberate step, not implicitly on app start.
• Backups exist and you have restored one at least once.

4. Assets and secrets

• Video, PDFs, and kiosk assets sit in Cloud Storage behind a CDN, off the Node process.
• Secrets live in Secret Manager and are injected at runtime. Nothing sensitive in the image, the repo, or a `.env` committed by accident.
• Large binaries do not go in git. Your repo should clone in seconds.

5. Before you say "live"

1. Hit the health endpoint on the deployed URL, not localhost.
2. Place one real end-to-end order, booking, or signup.
3. Check the logs for errors during that test.
4. Confirm you can roll back to the previous image digest in under a minute.
5. Set a billing alert so a mistake costs a notification, not a surprise invoice.

The stack is boring on purpose. Boring is what one engineer can operate at 2 a.m. If you want this set up for your product, get in touch.