Versions and rollback

Every forculus deploy makes a new version of the app, numbered from 1, and puts it live once it’s running. A rollback puts an earlier version live again, with the app’s current configuration, secrets and data.

A new version of a Worker or a site can take a minute or two to reach every location. Until then, some requests still get the previous version. A deploy that replaces a live version tells you:

Version 3 may still answer some requests for a minute or two, until this one reaches every location.

A container app switches versions with a rollout. Cloudflare stops the running container with SIGTERM, gives it up to 15 minutes to exit, then starts the new version’s container. The old version answers until it has stopped, so the switch takes about as long as your app takes to exit on SIGTERM. Requests that come in between wait for the new container to start:

Version 3 keeps answering until its container stops and this one's starts. Cloudflare sends it SIGTERM and gives it up to 15 minutes to exit, so the switch takes about as long as your app takes to exit on SIGTERM.

List versions

forculus versions acme/hello

   4  deployed  2026-09-23  someone@example.com (live)
   3  failed    2026-09-23  someone@example.com
   2  deployed  2026-09-22  you@example.com
   1  deployed  2026-09-20  you@example.com

Each line shows the version’s number, its status, the day it was made and who made it. The version serving now is marked (live). The newest is first. A version whose scan found something ends with what it found, like [scan: 1 possible secret]. forculus scans reads the whole report.

Status	Meaning
deployed	It went live, and can be put live again.
failed	It was made but couldn’t be put live. The previous version kept serving.
uploaded	It was made and is on its way live.
previewing	A preview on its way up.
pruned	Too old to roll back to. Only its number, hash and author are kept.

Most deploys answer once the version is live. One that takes longer, like a site of thousands of files, answers while its version is still uploaded, and forculus deploy waits until it’s deployed or failed. If we stop partway through, the version is failed within a few minutes, and so is one still going live after 30 minutes, which we stop. A preview stopped partway is failed within 30 minutes, and at once if its app is deleted while it goes up. It may be serving anyway, in whole or in part, unless it has files: then we put the previous version back up ourselves. Either way, deploy again or roll back to the version you want live.

If you press Ctrl-C during forculus deploy before the upload finishes, the deploy stops. It says Stopped before the upload, so nothing was deployed., removes the image a container deploy built, and deletes an app that --create made for it. After the upload, Ctrl-C only stops the waiting. We carry on putting the version live, and forculus deploy says so as it exits. forculus versions shows how it went, and a rollback puts an earlier version back.

--json gives each version’s number, sha256, size_bytes, status, active, created_by and created_at, and for a failed version, failure: why it didn’t go live, when we know. A version deployed since scans began has scan, its scan’s id, outcome, counts and dependencies. A version that has been live also has replaced: the number of the version it took over from the last time it went live. forculus deploy --json prints the same fields for the version it made, with the app’s url beside them. For a preview, url is the preview’s address and live_url the app’s.

The app’s Versions tab in the dashboard shows the same list, with Put this live beside each version you can roll back to. While the app is paused or suspended, its live version reads Current · paused, Current · suspended or Current · stopped and Not serving, as the app’s status does. In a suspended workspace no version is offered to put live, since nothing can be deployed there.

Roll back

Give the version’s number:

forculus rollback acme/hello 2

Version 2 is live again. Version 4 may still answer some requests for a minute or two, until this one reaches every location.

The version replaces the live one for everyone using the app once it has reached every location, so for a minute or two some requests still get the version it replaced. For a container app this is a rollout, as for a deploy: the running container stops and the old version’s image starts in its place.

Cloudflare runs one rollout at a time. While the previous rollout is still going, a rollback, deploy, env set or env remove first waits up to 20 seconds for it. A rollout is done once Cloudflare has set the new version to start, which can be while the previous version’s container is still exiting. An env set or env remove then goes ahead, and stops that container at once, as any change to a container app’s variables does. An env set or env remove made during a deploy waits for the deploy too, in the same 20 seconds, and then applies to the version the deploy put live. If either is still going then, the app keeps running what it was running, and you get:

This app's last change is still rolling out to its container. That can take a few minutes, or up to 15 if the app doesn't exit on SIGTERM. Try again in a few minutes.

A deploy stopped this way is listed as failed. An env set or env remove stops before it changes anything. The exception is when a rollout starts between its check and the redeploy. Then the change is saved but not live, the message says so, and running the same command again puts it live. If a deploy starts in between, the change waits for it and goes out once it’s done, as for any version still going live.

Rolling back to the version that’s already live puts it live again anyway. That fixes an app that a failed deploy or rollback left partly on another version. It says Version 2 was already live. We redeployed it.

A rollback doesn’t make a new version. Version 2 is live again under its own number. The next forculus deploy makes version 5, and you can roll forward to 4 the same way you rolled back.

What a rollback keeps

A version holds what was deployed: a Worker’s code and compatibility settings, a site’s files, or a container’s image, port and size. Everything else belongs to the app and stays as it is now:

• environment variables, with their current values,
• secrets,
• the database and everything in it,
• who the app is shared with, and its bypass tokens.

If you roll back to a version that expects a variable you’ve since removed, it runs without it. Set it again with forculus env set.

Which versions you can roll back to

The newest 20 versions keep their contents, and so does the live one. Previews are versions too and count toward the 20. Older versions are pruned. They’re still listed, but rollback refuses them:

error: Version 3 is too old to roll back to. We only keep the newest 20 versions, previews included. Deploy it again from its source.

Only a version that went live can go live again:

error: Only a version that deployed successfully can be rolled back to.

A version number that doesn’t exist:

error: acme/hello has no version 9. `forculus versions acme/hello` lists its versions.

A rollback runs the current checks on the version. A site with a file that a newer rule refuses can’t be put live again, and a container version can’t go live on a plan that doesn’t run containers.

Permissions

Listing versions and rolling back take an editor or owner of the app, or a workspace admin or owner. Every deploy, failed deploy and rollback is recorded in the audit log.

Next steps

• Share an app to let people in.
• Audit log to see every deploy and rollback.