Deploys and rollbacks

What happens when you deploy

1. ZedCloud builds the new version (if the source changed).
2. It starts the new version next to the old one.
3. It waits until the new version is ready: every replica must run at least 3 seconds without restarting, and answer 2xx on your Health path if you set one. It waits up to 60 seconds.
4. Traffic switches to the new version. The old one is kept for about 10 minutes.

If the new version never gets ready, the old one keeps serving and the app says last deploy failed: … with the reason. Your users see nothing.

Apps with a persistent volume, or set to Recreate, are stopped and started instead, with a short gap.

Why set a health path?

Without one, “ready” means “running for 3 seconds”. A health path such as /healthz that checks the database lets ZedCloud catch a version that starts but can’t work.

Rolling back

There are three ways back:

• Switch back (Settings → Deployments) returns to the previous version instantly, while it’s still kept.
• Roll back on any successful build in Source → Builds redeploys that build.
• Commit history (uploaded or git-pushed code) sets the code back to any commit, as a new commit, so history is kept.

From the CLI: zc rollback <app> --to v1.2.0 (a tag) or --to <commit>.

Builds

Source → Builds lists every build with its status, commit and ref. Expand one for its stages, the log, and a diagnosis in plain words if it failed.

Choosing a branch, tag or commit

Change ref… (Overview or Source) picks a Branch, Tag or Commit and builds it. A tag or commit pins the app: pushes and auto-deploy are ignored until you switch back to a branch. Redeploy and pull latest rebuilds the tracked branch.

CLI: zc refs <app>, zc pull <app> --tag v1.4.0.

Auto-deploy

For GitHub apps, tick Auto-deploy when changes (checked every minute), or set up the webhook for instant deploys. Pushes that arrive during a build are built straight after.

Deploy with git push

Where the platform offers it, an app whose source is a ZIP or folder also takes git push:

zc login --token <token>
zc git setup <app-id>        # adds the "zedcloud" remote, no token in .git/config
git push zedcloud main       # builds and deploys
git tag v1.2.0 && git push zedcloud v1.2.0   # tags are kept for rollback

Create a token for git in the Source tab makes a token for this. main takes fast-forward pushes only, and tags can’t be moved.

Promoting between environments

When a workspace has environments, you can move a tested build forward without rebuilding it:

• From the app: Source → Promote latest build to [env].
• Or the Environments page (g e): a grid of apps against environments with Promote from buttons.

Promote deploys the exact image that is live in the source environment. Apps are matched by name, and the target app must already be deployed once from code.

Approvals

If the workspace requires approval, Deploy becomes Request deploy. See Deploy approval.