Update the SaaS platform and subscribers
The Platform Super Admin receives one compatible signed delivery. The current System Update screen verifies and queues that package for host processing, while Fleet Releases handles subscriber rollout requests.
| Who | What they do |
|---|---|
| Publisher | Builds and signs one compatible customer-delivery.zip, publishes its checksum and public-key fingerprint separately, and provides release notes. |
| Platform Super Admin | Checks backups, uploads the delivery under System Update, reviews queue and fleet status, and tests the platform/subscribers afterward. |
| Host operator | Configures the trusted publisher fingerprint, reviews the immutable plan and backups, applies the central release and approved subscriber waves. |
| Subscriber | No upload, terminal command or purchase code. They may see a short maintenance period for their own workspace. |
Current procedure
- Check release and backups
Compare the published checksum/fingerprint, read compatibility notes, confirm a current central backup and a current backup for each target subscriber.
- Queue the delivery
Open System Update, upload the signed
customer-delivery.zipand its matching core ZIP when required by the delivery, confirm your current platform password and choose Upload & check. Review the verified package and compatibility results before host processing. - Wait for host review
The screen shows pending host review or prepared for host. This step does not install code.
- Apply central release
The host operator follows the reviewed central update procedure and confirms platform health.
- Request subscriber waves
Use Operations → Manage fleet releases. Select canaries, targets, wave size and concurrency. The host applies the reviewed request.
- Check each result
Open Operations to see central status, per-workspace backup and update status, scheduler/queue signals and recovery readiness. Test Super Admin, signup, mail, webhook, POS sale and refund.
If the update fails
Keep the recorded release receipts and failed workspace in its required maintenance state. Retry only through the exact reviewed action. For code-only rollback, use the previous signed release when backup and authenticated rollback evidence are ready. For schema-changing failures, leave maintenance active and follow the journal recovery decision; a database rollback is never assumed.
Data the release must preserve
The application protects .env, private platform state, tenant databases, storage/app/private, storage/app/public and uploaded customer files. After the update, verify actual access and data in a test workspace rather than relying only on an upload success message.
Screen example
