# Rollbacks in seconds: the 90-day deploy history > Why a rollback here is a cutover rather than a rebuild, what it does and deliberately does not undo, and how to make your migrations rollback-safe. Why a rollback here is a cutover rather than a rebuild, what it does and deliberately does not undo, and how to make your migrations rollback-safe. 8 Apr 2026 · 3 min read · cmdz A rollback that rebuilds is not a rollback. It is a deploy of older code, at deploy speed, at the worst possible moment. ```bash cmdz rollback ``` Six seconds, typically. Here is why. ## Why it is fast Every deploy is stored as an image digest plus the configuration that went with it. That image already built successfully and already passed its health check — those facts are recorded, not assumed. A rollback starts that exact image again and moves traffic once it answers. No build, no dependency resolution, no registry pull if the node still has the layers. It is a cutover. Ninety days of history, so `cmdz rollback --to 388` works for something from March. ## What a rollback undoes - The application code, exactly, byte for byte - The runtime configuration that shipped with it: replica count, instance size, start command - The routing, once the old version is healthy ## What it deliberately does not undo This is the part worth reading twice. **Your database schema.** A rollback does not reverse migrations. It cannot, safely: a down-migration that drops a column destroys data the new version already wrote, and a platform should never do that automatically. **Your data.** Obviously, but worth stating. **Environment variables you changed since.** Those are state, not code. **Anything an external system did.** Emails are sent. Webhooks are delivered. Payments are captured. So: a rollback restores your application. It does not restore the world. ## Making migrations rollback-safe The practice that makes this work is expand-and-contract, and it costs one extra deploy. Instead of renaming a column in one release: 1. **Expand.** Add the new column. Write to both. Deploy. This release is compatible with the previous one. 2. **Migrate.** Backfill. Read from the new column. Deploy. 3. **Contract.** Stop writing the old column. Drop it. Deploy. Between each step you can roll back one release without the schema being wrong. Between step one and two you can roll back freely. The rule of thumb: **any single deploy should be reversible without a schema change.** If it is not, split it. ## Automatic rollback You can arm it: ```toml [apps.web.rollout] auto_rollback = true error_threshold = "5% over 2 minutes" ``` The platform watches the error rate after a release. Cross the threshold and it cuts back to the previous version and tells you. This is a good default for a production app with real traffic, and a bad default for something with three visitors a day, where 5% is one request and one request is noise. ## The confidence this buys The real value is not the rollback. It is that a fast, reliable rollback changes how you deploy. Teams that fear deploying batch changes up, which makes each deploy larger, which makes each deploy riskier, which increases the fear. The loop is well documented and every engineer has lived in it. Six-second rollbacks break it. You ship the small thing on a Thursday afternoon, because if it is wrong you will know in two minutes and it will be gone in six seconds. That is worth more than any individual feature on this platform, and it is worth more the more of your code was written by something that types faster than you can read. ## For agents `cmdz_rollback` is in the `build` profile, which means an agent can roll back but cannot delete. That asymmetry is deliberate: rolling back is a recovery action and should be as available as possible; deleting is not. "The error rate spiked after the last deploy, roll it back and tell me what changed" is a reasonable thing to ask something that can read your metrics, your deploy history and your diff. It is also, notably, the three-in-the-morning scenario that made people want agent access in the first place. ## Set your limit and start. One click with a passkey, then you verify a payment method once to start your 14-day free trial (€ 10 of credit). After that it is prepaid pay-as-you-go — you only ever spend credit you have already bought, and no invoice ever arrives above the amount you set. - [Create account](https://app.cmdz.com/signup) - [Read the docs](https://docs.cmdz.com)