Appearance
Software updates
Installing a new version. The system does this properly — snapshot first, then update, with a way back. 20 minutes, at a quiet hour.
Sidebar → Server & Health → Software Updates
Before you start
| Do this | Why |
|---|---|
| Pick a quiet time | Schools are locked out while it runs |
| Take a manual backup | The update takes its own snapshot, but a second copy costs nothing |
| Tell your schools | A few minutes of downtime is fine if expected, alarming if not |
| Have the update package ready | The .zip supplied with the release |
Large packages upload in pieces
The upload is resumable and chunked, so a dropped connection does not mean starting again on a slow line.
What happens when you deploy
Nine steps, in this order. Knowing the order tells you exactly where you stand if something stops.
| Step | What it does |
|---|---|
| Verify | Checks the file size, its SHA-256 checksum, and that the package really contains the application |
| Maintenance mode | Schools see a maintenance page |
| Database snapshot | A full backup, taken before anything is touched |
| File backup | Copies of the files about to be replaced |
| Copy files | The new version goes in |
| Migrations | Database structure updated |
| Seeders | Any new default data the release needs |
| Caches & storage link | Cleared and repaired |
| Back online | Maintenance mode off |
You can still use the site during maintenance
Maintenance mode is turned on with a private bypass link, shown in the update log. Open that link and you see the real site while everyone else sees the maintenance page — useful for checking the update before letting schools back in.
The safety design
Two things are worth knowing, because they change how nervous you need to be:
If the snapshot fails, the update stops immediately — before a single file or table is changed. You are exactly where you started.
If a migration fails, the snapshot already exists, taken moments earlier. The log tells you so.
Do not close the browser tab while it runs
The deploy reports progress as it goes. Closing the tab mid-way leaves you unsure which step it reached — and the site possibly still in maintenance mode.
If that happens, check the update log on the same screen; it records every step.
After the update
Check these four things before telling schools they can log back in:
- The version number on the page has changed
- Server & Health → Server Health is clean
- Log in as a school admin and open a page with photos or documents, confirming the storage link survived
- A message sends — trigger a test notice
If something went wrong
You have two ways back:
| Route | When |
|---|---|
| Rollback from the updates screen | Restores the previous files, and the database snapshot if needed |
| Restore the snapshot from Backups | If you only need the data back |
Rolling back the database loses anything entered since the update
If schools have been working since the update, restoring the database throws that work away. Files-only rollback keeps it.
Decide which you need before pressing anything — and this is exactly why you update at a quiet hour, when there is nothing to lose.
Common problems
| What you see | Cause |
|---|---|
| "Checksum does not match" | The upload was corrupted or incomplete — upload it again |
| "Package does not contain the application" | Wrong zip, or a zip of the wrong folder level |
| Deploy stops at the snapshot step | No disk space, or the database is too large for the time limit — free space and retry |
| Migration fails | Note the error; the snapshot is already taken. Send us the log |
| Site stuck showing maintenance | Use the bypass link from the log, or clear maintenance mode from Server Health |
| Photos broken after updating | The storage link is repaired automatically, but check it on Server Health |
| Everything works, but nothing sends | Check the cron job is still in place on the host |