Guide

Deploying

What a push does, and how to know it worked

DEPLOYING

A push to main builds every service in the blueprint and rolls it out. Watch
it with: saasie app <name> build list

Only main deploys. A push to any other branch is accepted and starts no
build.

WHERE IT ENDS UP

  one service        https://<name>.saasie.app
  more than one      https://<service>--<name>.saasie.app, for each one

A blueprint with more than one service has no https://<name>.saasie.app —
that hostname is routed to nothing and answers 404. Adding a second service
therefore moves the first one's URL.

THE ROLLOUT IS A ROLLING UPDATE

The new version starts while the old one is still serving. The old one is
not stopped until the new one answers its health path. Two consequences,
and both have bitten real apps here:

  Your old and new code run at the same time, against the same database,
  for the length of the rollout. A schema change has to be survivable by
  both. See: saasie docs migrations

  If the new version cannot become healthy, the old one keeps serving and
  the rollout never completes. The site stays up, on the old code. This is
  the failure that looks most like success: nothing 500s, nothing restarts,
  and the app simply does not change.

VERIFY FROM OUTSIDE, NOT FROM THE BUILD LOG

A build log ends when the image is pushed. Your server has not executed at
that point, so a green build says nothing about whether the app runs.

The cheapest reliable check is to make the running code state its own
version — an endpoint that returns the commit, or any value you change in
the same commit — and read it over the public URL after deploying. If it
still reports the old value, the rollout has not completed, whatever
anything else says. Do that before reporting a deploy as done.

If a rollout does not complete, the useful questions in order: does the new
version answer its health path locally; does it bind 0.0.0.0 and the
declared port; does it block on something at startup that never returns.

  saasie app <name> status

answers the first of those from the cluster: when a pod is up and its
health path is not answering, that command prints Kubernetes' own reason
for it — the status code it got, or that the connection was refused.

The same text, on your machine: saasie docs deploy