Back up, recover and update
Keep a verified copy
In 0.4.0, Operations → Backups can schedule daily or weekly local backups while the server and job workers run. Keep a chosen number of verified pairs, or keep all. A failed verification does not replace the last verified success or prune healthy copies. Failure alerts are in the application, not email or push notifications.
gorun backup --data /var/lib/gorun --retain 7Preview, then restore separately
Use backup-preview with the actual manifest path to inspect a disposable read-only local copy. It does not sign in to accounts, run jobs or change the live site. A preview is not proof that external objects, integrations and every extension can be recovered. Permanent restore uses a new directory; switching traffic remains your decision.
Store a copy off the same disk. Keep the original site secret, deployment settings, matching themes and external media separately. Default backups omit secret.key and gorun.toml. Pause writes when you need a fully consistent database-and-file recovery point.
Updates need a deployment plan
Check the latest public release, read its notes, back up, preserve the old artifact and secrets, stop the old process, replace the artifact and test before cutover. Run one process per SQLite data directory. Rolling back the executable alone does not undo database changes.
The optional System Updates page is released in 0.5.0. It requires an operator-configured Coolify resource, recent authentication and a verified backup before requesting deployment. It is not a general in-app core updater, and a deployment request is not proof of successful rollout. Existing sites need a manual deployment before the new page exists. Anonymous GHCR access must not be assumed; use the verified public binary path or your tested build/deployment method.