Update and restore

Choose the operation you need: update an app, roll back to an earlier version, recover deleted data, or retire an app.

What you can do: Work with code, configuration, and databases with a clear understanding of what each operation can restore
Required permission: manage on the app. Database restoration and app deletion require browser approval
Done when: You open the app URL after the operation and confirm the expected state

What can and cannot be restored

In this table, “rollback” means returning code to an earlier deployment. “DB restore” means restoring Managed SQLite to a restore point.

Item	Restored by rollback?	Restored by DB restore?	Notes
Code (image)	Yes	No	Starts the target deployment’s image without rebuilding. Static sites / SPAs are excluded (see below)
`keelson.yaml` settings (`env`, `crons`, `assets`, `health`)	Yes	No	Uses the settings from the target deployment
Secret values	No	No	Always uses the current values. Change them back manually in the console
Managed SQLite data	No	Yes	Daily backups, manual snapshots, and point-in-time recovery (PITR)
Schema changes made by `db.migrate`	No	Yes	Restores the schema as it was at the restore point
Files SDK files	No	No	Not covered by backups. Retain copies in your app
Media SDK files	No	No	Write-once; remain unless deleted
External databases (such as PostgreSQL)	No	No	Restore using the external service’s backups
Changes to external services (Slack posts, emails, payments)	No	No	Side effects cannot be undone. Watch for duplicates when retrying
App permissions, IP restrictions, public URL	No	No	Independent of deployments. Change them back manually

Deploy app changes

Run and test the app locally
Use keelson deploy --check --json to inspect configuration and archive contents in advance, without uploading
Run keelson deploy, or ask your agent to deploy
When finished, open the URL and check the result. For authenticated API checks, see Verify a deployment

If deployment fails before traffic switches, users can continue using the old revision. However, any partially executed db.migrate changes remain (see “Change the database schema” below).

See Deploy an app for which changes take effect and when, including secrets that do not take effect until the next deployment.

Roll back code

Apps with a server (those with a command) can return to a previous successful deployment that has a container image.

keelson rollback                # Return to the previous successful deployment
keelson rollback <deploy_id>    # Return to a specific deployment

Starts a new revision using the target deployment’s image and keelson.yaml settings, without rebuilding
Only completed deployments with an image can be targets. Static site / SPA deployments and deployments created by the older deployment system cannot be rollback targets
Uses current secret values
If the target deployment’s keelson.yaml contains db.migrate, rollback also runs it before switching traffic. Rollback is not necessarily an operation that leaves the DB untouched
The database is not rolled back. If newer code changed the schema, the restored code will read the newer schema. Adding columns or tables is usually compatible. If columns were removed or types changed, consider restoring the DB as well
Cannot run while a deployment is in progress

The console’s “Deployments” tab lists deployments and lets you download each deployment’s source.

To restore a static site / SPA, deploy the previous artifacts again. Check out an earlier Git commit and rebuild locally, or download the previous deployment’s source (assets.dir contents and keelson.yaml) from the “Deployments” tab and run keelson deploy directly.

Recover accidentally deleted data

Restore Managed SQLite (db.mode: libsql) data from “Restore points” on the app page in the console.

Choose a time on the restore-point timeline: a daily backup, a manual snapshot, or an arbitrary PITR time. See Plans and limits for retention counts and recovery windows by plan
You can download the data first to inspect it
Run Restore. Browser approval is required
Open the app and check the restored data

What restoration does:

All writes after the selected time are lost. This is not a partial restore of only the deleted data. Downloading before restoration lets you manually reapply changes you want to keep
The state before restoration is retained for 72 hours, during which you can undo the restore
Only one app’s DB is affected. Other apps are unaffected
Files / Media files and external databases are excluded

Take a manual snapshot before important operations (up to five per app per day).

Change the database schema

The command in db.migrate runs on every deployment, before traffic switches.

If it fails, traffic stays on the old revision. However, partially applied changes are not automatically undone. Check migration logs (keelson logs deploy <deploy_id>) and the DB state before fixing the issue
Prefer changes that still work with the old code, such as adding columns or tables. Make migrations idempotent (for example, with IF NOT EXISTS) because they run every time
Before changes that are hard to reverse, such as dropping columns or changing types, take a manual snapshot and schedule the work during a quiet period

Retire an app

Suspending and deleting are separate operations.

Operation	What happens	Reversible?
Suspend (app “Settings” → “Suspend”)	Requests, webhooks, and cron jobs cannot start the app. The URL shows a suspended page. Data, URL, and settings remain	Resume at any time
Delete (“Settings” → “Danger zone”)	Removes the app, URL, deployment history, and secrets. Requires browser approval	No

Export these before deletion:

DB data — Download from restore points
Files / Media files — Cannot be downloaded from the console or CLI. Implement download endpoints in the app to export them (Files and media)
Source code — Keep it in Git, or download it from each deployment in the “Deployments” tab
Secret values — Cannot be retrieved after deletion. Keep a copy if needed

After deletion, DB backups, Files, and non-sensitive configuration notes (app name, URL, cron definitions, and environment variable and secret names) are held in quarantine for seven days. This allows discretionary assistance with accidental deletion; it does not guarantee recovery.

For apps after a subscription ends, see Billing and subscriptions.

App status and logs — Suspension, deployment history, and logs
Database (Managed SQLite)
Troubleshooting