Skip to content
All posts

1 min readdeploys, infrastructure, cetus

Half my releases used to ship

The frontend redeploys itself on a push. The backend is a git clone on a box that pulls only when I ssh in.

12 August 2026

Cetus deploys two different ways. The web app is on Vercel, where a push to main is the deploy. The API is a git clone on a GCP box, and it pulls when I ssh in and tell it to.

For a while I treated the push as the release. The frontend would go out expecting a field the API had never heard of, staging and production would disagree about what the API accepted, and I would find out from a bug report rather than from a failed deploy.

What made it hard to spot is that commit subjects lie. A commit called fix(composer) had changed a schema file under app/. Reading the subject line was never going to catch that.

So the check is a diff now, not a judgement. Ask git which files changed between the deployed commit and main, and if anything under app/ or migrations/ comes back, the backend is part of this release. Then ssh in and pull. The rule is written into the deploy README, at the top, where I will see it before I push instead of after.