# Publish and roll back

> Release a checked app version, recover a failed release and manage its lifecycle.

## Before you begin

You need owner or dashboard editor access. Test important actions before publishing and cover the [subscription charge](/en/docs/apps/costs) from the shared pool. Partner operators with Editor access can also publish during a live operator session; the subscription is charged to the customer workspace’s shared pool.

## Publish a version

1. Open **Open builder** from the app page.
2. Choose **Publish**.
3. Choose the plan and autoscale, and review the first charge, when publishing for the first time.
4. Decide whether to keep preview test records on the first publication.
5. Review any **Access changes**.
6. Confirm the publication.
7. Follow the release in the app page's **History**.
8. Open or reload the app after the release completes.

First publication charges before infrastructure creation. Failed-publication retries never charge the same period twice. Every size includes hourly backups of the published data. Later publications keep published records and never replace them with test data.

## Follow a data update

Adding defaults or renaming fields can require **Updating your data**, followed by verification of every record. Members keep the previous interface until checks pass. Leaving the page does not stop the release.

A draft becomes a checked preview, then a published version. Later releases update records and activate after checks; compatible rollbacks retain records.

Pausing blocks access. Trash retains source and data for seven days before permanent deletion.

> **Rule** — The data model only grows. Add tables and optional fields; retain old fields when renaming. Removing tables or fields, changing field types or making optional fields required is unsupported and fails before deployment.

## Recover a failed release

1. Open the failed entry in **History**.
2. Read the failed step and its explanation.
3. Choose **Review access changes** if the permissions review became outdated.
4. Choose **Retry** when the cause is resolved.

When the app code fails the checks that run before publishing, **History** shows the first errors and offers **Fix in the builder** instead of **Retry**: the builder receives every error, fixes the app and checks the preview. Publish again afterwards.

Interrupted data updates retry automatically a few times. Failures after function deployment can leave newer functions serving the previous interface. Inspect the unfinished-release warning and History before assuming a full restoration.

## Keep the app up to date

Botchi improves the libraries apps are built on. A published app keeps its version until it is updated; publishing from the builder always includes the latest one.

1. Look for **Update available** on the Apps page or an update notice on the app page.
2. Choose **Update app**.
3. Follow the release in **History**.

The update republishes the published version: data, features and access stay the same. An app with unpublished builder changes is updated by publishing it from the builder. When an important update needs changes, choose **Adapt in the builder**, check the preview and publish as usual; members keep the current version until then.

## Roll back the published version

1. Open the app page's **History**.
2. Select an eligible previously published version.
3. Choose **Rollback**.
4. Review any **Access changes**.
5. Confirm the rollback.

Rollback offers only versions compatible with current records and restores code, not data. Versions with incompatible app kits or roles are also excluded. For builder source alone, use [source history](/en/docs/apps/build). To bring back records, restore a backup.

## Restore data from a backup

Botchi backs up the data of every published app every hour and keeps 30 days of restore points.

1. Contact Botchi support.
2. Name the app and the date and time to go back to, with your time zone.
3. Wait for support to confirm the restore is complete.

The restore replaces the app's published records with their state at that minute; changes made after it disappear. The code stays the same. When the current version no longer accepts the older records, support asks you to roll back first. The state just before a restore can itself be restored.

| Item | Rule |
| --- | --- |
| Data loss | At most the last hour of changes. |
| Restore point | Any minute of the last 30 days. |
| Duration | Minutes for small apps, up to hours for very large ones. |

## Export an app

The account owner can download a copy of a published app.

1. Open **Settings**.
2. Choose **Export app**.
3. Wait for the email that says the export is ready. Leaving the page does not stop it.
4. Choose **Download** in **Settings**.

The zip holds the source of the published version and the app's data as of the last hourly backup: every table and file, as a standard Convex snapshot that `npx convex import` loads into a Convex project. The source depends on the Botchi app kit and does not run outside Botchi as is.

| Item | Rule |
| --- | --- |
| Who | The account owner only. |
| Apps | Published apps, paused ones included. Not drafts or apps in Trash. |
| Data | As of the last hourly backup. A newly published app can be exported after its first backup. |
| Ready | In seconds to a few minutes. |
| Download | Available for seven days. |
| Limit | Up to three exports per app per day. |

## Pause or remove an app

1. Open **Settings**.
2. Open **Pause or delete app**.
3. Change **Kill switch** to stop or restore access.
4. Confirm the access change.

Pausing access keeps source and data. It does not cancel the app subscription.

To remove an app as an owner or dashboard editor:

1. Choose **Delete app** under **Pause or delete app**.
2. Enter the exact app name shown in the confirmation, if the app is named.
3. Choose **Move to trash**.

Members and agents lose access. Renewals stop while the app is in Trash.

Restore it from **Apps** → **Trash** with **Restore** before seven days expire. A restore after the paid period ends starts a new paid period charged to the workspace’s shared pool. Authorized partner operators can also restore during a live operator session.

> **Watch out** — **Delete for good** in Trash permanently removes the app, its database and source files. This cannot be undone. Trash also deletes them automatically after seven days. To keep a copy, export the app before moving it to Trash.

## Related

- [Build and test](/en/docs/apps/build)
- [Review app permissions](/en/docs/apps/access)
- [Subscription and limits](/en/docs/apps/costs)