Updates, staging, and releases

Editors’ work never needs a release. Content, menus, design, switching themes, and turning plugins on or off all happen in the admin, with drafts, previews, and history.

A release (a new version of the app image) is needed for:

• updating sc-cms itself;
• adding or updating a theme;
• adding or updating a plugin (both kinds ship inside the image; sandboxed plugins are checked against their signatures).

How a release travels

1. Every change merged to main runs the full test suite.
2. A green build produces the web, worker, and migrate images once, tagged with the commit and staging. Tagging a release (such as v0.0.1) also tags those images with the version (0.0.1).
3. Staging runs those images. Someone checks the change there; pnpm smoke https://staging.example.com --staging runs a quick automated check.
4. Promote: a GitHub workflow, run by hand and approved by a reviewer, re-tags the same images as production. Production runs exactly what staging ran.
5. Production pulls the new images, runs migrate, restarts web and worker, and runs pnpm smoke https://www.example.com.

Rolling back means promoting the previous version. Database changes only ever add, so the older version runs fine on the newer database. For a bad theme or plugin, switching back or deactivating it in the admin is usually quicker.

Staging

Staging is a copy of production that is safe to break. With APP_ENV=staging:

• emails are written to the log instead of sent;
• webhooks are recorded but never sent;
• search engines are told not to index anything;
• backups are never written or deleted;
• the admin shows a Staging banner.

pnpm staging:refresh refreshes staging from production’s latest backup. Staging then holds real people’s data, so protect it like production.

Details: releases guide (in the code repository).