Skip to main content
Version: Next

Validation, Updates, and Rollback

This page defines the operating rules for the standard school deployment flow built around the backend school bundle.

If support has explicitly moved a site onto the frontend deployment pack exception path, apply the same discipline there, but do not treat it as the default operator workflow.

Always validate the release artifact first​

Before install or update:

  • confirm you are using the correct release version
  • confirm the checksum manifest matches the archive
  • if the release is signed, confirm the trusted public key is available
  • run the packaged preflight before extraction or install
  • use the packaged install or update entrypoints only

Validation after install​

After the standard install or update flow, confirm all of the following:

  • the expected containers are running
  • the frontend loads on the server machine
  • the frontend loads from another device on the same LAN
  • backend health succeeds
  • no checksum, signature, migration, or configuration errors were reported

Update rules​

When a new release arrives:

  1. deploy from the new packaged artifact, not by editing old directories in place
  2. rerun the same verification and preflight sequence
  3. confirm TENANT_ID, LOCAL_SCHOOL_ID, and SITE_ID still match the school's handoff values before reusing .env.school
  4. use the packaged update command for that artifact
  5. verify health, bootstrap completion, and access again after update

Identity checks during updates:

  • TENANT_ID must still match the school's cloud-side tenant
  • LOCAL_SCHOOL_ID must still match the school's cloud-side school record
  • SITE_ID must remain the same stable appliance identity used by previous installs and sync sessions

Do not rotate SITE_ID during a normal update. That breaks continuity for bootstrap and sync session tracking.

Rollback rules​

If a new release is bad:

  • return to the last known-good artifact directory or archive set
  • rerun the packaged install or update path from that known-good release
  • keep the same TENANT_ID, LOCAL_SCHOOL_ID, and SITE_ID values that were used by the working deployment unless support explicitly instructs otherwise
  • do not combine scripts, env templates, checksums, or metadata from different release versions

Identity checks during rollback:

  • use the original school handoff values, not guessed or regenerated replacements
  • do not change SITE_ID just because the release version changed
  • if license validation is enabled, confirm the rollback bundle's license material still matches the configured tenant, school, and site values

What support should keep for every release​

  • release directory
  • archive and checksum manifest
  • optional signature metadata and trusted public key
  • school-specific handoff notes
  • the exact release version and pinned image tags

Operational discipline​

Do not do the following in production:

  • build local images on the school machine
  • deploy by cloning raw source repos
  • manually swap scripts between release versions
  • copy a previous .env.school forward without checking the packaged template and release notes
  • skip preflight because a previous release worked