Rollback

List Worker versions, then select the version you want to restore:

vendor/bin/atoms status --env production
vendor/bin/atoms rollback VERSION_ID --env production --message "restore known code"

Both commands reach Cloudflare through Wrangler, so both need credentials, and both resolve them exactly as deploy does — see Authenticate with Cloudflare and Precedence. Neither resolves a callback URL: they ship no code.

Without a version id, Wrangler selects the previous Worker version. Changing a secret also creates a Worker version, so the previous version may contain the same code.

What rollback changes

Rollback restores Worker code and compatible versioned configuration. It does not reverse SQLite migrations or restore data. Cloudflare bindings, such as the Durable Object namespace, are not rolled back with code.

The older code must work with the current schema. For example, removing a column can prevent a rollback to code that still reads that column. Keep schema changes compatible with every code version you may need to restore.

If a migration applied successfully but produced an unwanted schema, add a corrective migration. If a migration failed to apply, resolve that failure first: the migrator stops at the failed migration. See ATOMS-E053.

Rollbacks take time to reach running Atoms. Verify application behavior after rolling back.

Data recovery

Atoms does not provide a point-in-time data recovery command. Cloudflare’s SQLite restore APIs must be called from inside the Durable Object. Exposing them requires a custom Worker implementation that you maintain. See the runtime specification for the runtime’s storage and lifecycle behavior.