Skip to main content
This guide shows how to publish changes from an App’s sandbox to production, how to roll back production to an earlier commit, and how to take a published App offline.
Publishing and unpublishing an App requires the owner or admin role in the organization.

Publish new changes to production

A deployment always publishes a commit. If the sandbox files changed since the last commit, the deployment commits them first.
1

Verify your changes on the sandbox dev server

Before you commit, start a preview to verify that the App bundles and runs cleanly:
If the build fails, the API returns 422 preview_failed with the compiler error in error.detail.
2

Check what changed

Inspect the modified and untracked files in /app:
3

Create a commit

Commit the sandbox changes to Git and create a durable backup:
This step lets you write your own commit message. If you skip it, the deployment commits any changes for you.
4

Deploy the commit

Publish the sandbox to production:
The request builds the App, applies any D1 migrations, publishes the bundle, and waits until the production runtime is serving:

Roll back to an earlier commit

Every commit in your App’s history has a 40-character commit_sha and a cmt_... ID. You can redeploy any earlier commit directly to production.
1

Find the commit to restore

List the App’s commits:
Find the target commit in results and copy its id (cmt_...).
2

Deploy the earlier commit to production

Pass the commit’s cmt_... ID in the commit_id field of POST /api/apps/{id}/deployments:
When the request returns with status: "succeeded", production is serving that earlier commit.
3

Optional: Reset the sandbox working tree

Deploying an earlier commit changes production, but leaves the sandbox /app directory on its current commit. If you also want to reset /app in the sandbox to match that commit, call POST /api/apps/{id}/restore with the commit’s cmt_... ID:
Rolling back code does not reverse D1 database schema migrations that have already been applied. Write backward-compatible D1 migrations so earlier commits can still read the database if you roll back. See D1.

Take an App offline (unpublish)

To stop serving an App in production without deleting the App, call POST /api/apps/{id}/unpublish:
The API returns the updated App object with:
  • production.status: "unpublished"
  • production.deployment_id: null
Requests to the App’s URL no longer reach your Worker. Your source files, commits, Secrets, and D1 / KV / R2 / Durable Object data remain untouched. Call POST /api/apps/{id}/deployments whenever you are ready to put the App back online.

Next steps