Every DenkOps project keeps a deploy history, and any previous version that deployed healthy rolls back with one click. The dashboard's Deploys panel lists each version with its deploy time, the actor who shipped it, the commit, and a status pill. The active version is marked, and recent versions stay available, so rolling back never means rebuilding.
What does the deploy history show?
One row per deploy, newest first:
- Version: v1, v2, v3, counting up. The version currently serving traffic carries an Active badge.
- Deployed: the timestamp.
- Actor: who shipped it. That can be a person, or it can be the agent that deployed straight from a Claude Code chat.
- Commit: the commit the version was built from, when there is one.
- Status: healthy, superseded, or failed.
The actor column is the quiet star. Once an agent is allowed to deploy, "who shipped v14 at 02:12?" is a question you will actually ask, and the history answers it without a search through chat transcripts.
How does one-click rollback work?
Every previous version that deployed healthy gets its own Rollback button in the table. Click it, confirm the prompt ("Roll back my-api to v12?"), and the platform switches traffic back to that version. There is also a project-level Rollback button that returns to the previous healthy version without you picking a number, and from Claude Code you can simply say "rollback".
The important part is what does not happen: no rebuild. Recent versions are retained as they were built, so a rollback starts the old version exactly as it ran before. You are not re-running an install step at 2 a.m. and hoping the dependency tree resolves the same way twice.
Why does an undo button matter when an agent ships the code?
Agents change the economics of deploying. A coding agent can ship five versions in an afternoon: a feature, two fixes, a refactor, another fix. That speed is the point, but it moves the human's job from "do the deploy" to "supervise the deploys". Supervision only works if the cost of being wrong is low.
Deploy history plus rollback is what makes it low. You can let the agent ship, glance at the status column, check the request traces if p95 moved, and undo any version in one click if it did not work out. The agent gets autonomy over shipping. You keep authority over what stays shipped.
Roles reinforce the same split. Rollback is available to workspace owners and members; viewers can read the history and the logs but cannot change what is running. If several people and agents share a project, the workspace audit trail records deploys and rollbacks alongside membership changes, so the history survives beyond the table.
What should you check before rolling back?
Two things, both visible in the dashboard:
- The target's status. Roll back to a version that deployed healthy. The table shows this per version, so you are never guessing which build was good.
- Staged configuration. Environment variables are applied at deploy time, so a version that ran fine last week runs with the config it is given now. If you changed a secret since, confirm the old code expects it.
That is the whole checklist. Rollback is designed to be the boring option, the one you can take under pressure without a runbook.