Update and restore

You can deploy app changes or return to earlier code or data after a problem. Choose the action that matches what you need.

Goal	Action
Apply changes	Deploy again
Return to the code before an update	Roll back
Recover accidentally changed or deleted data	Use a database restore point
Temporarily stop access	Suspend
Retire the app	Delete

These actions require the app’s manage permission (manage). Database restores and app deletion also require approval in a browser.

Restoring code does not restore the database or files to their earlier state. See What each operation restores for the full comparison.

Apply app changes

Tell your agent what changed and which actions to check.

Deploy these changes to Keelson. Check the configuration and upload contents before deploying, then verify that [action] works afterward.

Check your changes in your local development environment.
Ask the agent to deploy. With the CLI, use keelson deploy --check --json to inspect configuration and upload contents, then keelson deploy to apply them.
After deployment, open the app and test the changed behavior. For apps that only run scheduled jobs, check the run history. See Verify a deployment.

If deployment fails before the traffic switch, the previous version remains accessible. However, changes made by a partially completed db.migrate remain. See “Change the database schema” below.

See When changes take effect for details such as the deployment or Apply step required after saving secrets.

Restore an earlier version of the code

A rollback returns the code to an earlier deployment. The target must be a successful deployment whose container image, the packaged files used to run the app, is still available.

You can ask your agent: “After [problem], check whether we can return to the previous code, including any impact on data.” The CLI commands are:

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

The app starts 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 with an older deployment method cannot be rollback targets.
Secrets use their current values.
If the target deployment’s keelson.yaml includes db.migrate, it also runs during rollback before traffic switches. A rollback can therefore modify the database.
The database is not restored. If the update changed its schema, check that the older code can use that schema. Even adding a column can affect compatibility through constraints or defaults. Ask your agent to check compatibility and consider a database restore if needed.
Rollback cannot run while a deployment is in progress.

Past deployments appear in the console’s Deploys tab, where you can download their source.

For a static site or SPA, redeploy the earlier files. Either return to an earlier Git commit and build locally, or download the source of an earlier deployment from the Deployments tab: the contents of assets.dir and keelson.yaml. To use the downloaded archive, extract it and run keelson deploy in the folder containing keelson.yaml. No rebuild is needed.

Recover accidentally deleted data

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

Select a point on the restore timeline: a daily backup, a manually saved snapshot, or a specific time using point-in-time recovery (PITR). See Plans and limits for retention counts and recovery windows.
You can Download the selected restore point to inspect it. This downloads that historical state, not the current database.
Select Restore and approve the operation in your browser.
Open the app and check the data after restoration.

What happens during a restore:

Database writes are temporarily unavailable during the switch. Notify users and choose a quiet period.
All writes after the selected point are lost. This does not recover only the deleted records. To keep the current state too, create a manual snapshot of the current database and download it before restoring. Ask your agent how to bring back any later changes you still need.
The state before restoration is retained for 72 hours, during which you can undo the restore.
A restore affects only one app’s database, not other apps.
Files / Media files and external databases are not included.

Before a major change, take a manual snapshot to create a known recovery point. You can create five per app per day.

Change the database schema

A migration updates the database structure, for example by adding fields. Ask your agent to check that returning to the earlier code will still work:

Before changing the database schema, check compatibility with the previous code and whether the migration can safely run again after a failure. For changes that may require a restore, explain the impact and recovery steps before running them.

Implementing migrations

The command in db.migrate runs before traffic switches during a deployment or rollback.

If it fails, the previous version remains accessible, but partially applied database changes are not automatically undone. Inspect keelson logs deploy <deploy_id> and the database state before making corrections.
Make repeated runs safe so the same change is not applied twice. This property is called idempotency. Track applied changes or use constructs such as IF NOT EXISTS, and check what happens after a partial failure.
Check compatibility with the previous code even when adding columns or tables. For higher-impact changes, such as removing columns or changing types, consider taking a snapshot immediately beforehand and running during a quiet period.

Retire an app

Suspending and deleting have different effects.

Action	What happens	Can you undo it?
Suspend, under Settings → Suspend for web apps and static sites / SPAs	Requests, webhooks, and cron do not start the app. The URL shows a stopped page. Data, URL, and configuration remain	Yes, use Resume
Delete, under Settings → Danger Zone	Removes the app, URL, deployment history, and secrets. Requires browser approval	No

Apps that only run scheduled jobs have no console Suspend action. Set each job’s enabled to false and deploy to stop scheduling; set it back to true and deploy to resume. See Scheduled jobs.

Export these before deletion:

Database data — for the current state, create a manual snapshot and download that restore point.
Files files — add download functionality to the app and export them.
Media files — create viewing links from the file IDs recorded by the app and save the files before deleting. Neither Files nor Media has a console or CLI listing or download feature. See File management and capacity.
Source code — keep it in Git or download it from a deployment in the Deployments tab.
Secret values — saved values cannot be displayed again. Retrieve them from where you originally stored them or from the issuing service.

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

See Billing and subscriptions for what happens when a subscription ends.

What each operation restores

“Rollback” below means returning the code to an earlier deployment. “Database restore” means returning Managed SQLite to a restore point.

Item	Restored by rollback?	Restored by database restore?	Notes
Code (image)	Yes	No	Starts the target image without rebuilding. Excludes static sites / SPAs
`keelson.yaml` settings (`env`, `crons`, `assets`, `health`)	Yes	No	Uses the target deployment’s configuration
Secret values	No	No	Always uses current values. Change them manually in the console
Managed SQLite data	No	Yes	Daily backups, manual snapshots, and PITR
Schema changes made by `db.migrate`	No	Yes	Returns the database structure to the restore point
Files SDK files	No	No	Not backed up; retention is the app’s responsibility
Media SDK files	No	No	Cannot be overwritten; save a new file to replace one
External databases, such as PostgreSQL	No	No	Use the external service’s backups
External actions, such as Slack posts, emails, or payments	No	No	Rollback does not undo them. Avoid duplicates when retrying
App permissions, IP restrictions, and public URL	No	No	Managed independently of deployment. Revert manually

App status and logs — suspension, deployment history, and logs
Managed SQLite backup and restore
Troubleshooting