Deploys & pending changes

Everything stages, nothing takes effect until you deploy

Every configuration change you make — a new Teammate, an edited workspace file, a model list, a secret, a channel connection, a resized agent server — stages as a pending change first. None of it reaches a running agent server until you deploy — with one exception: integration connections go live the moment their sign-in completes, no deploy needed. This is deliberate: you can make a batch of changes across several Teammates and servers, review the whole set together, and ship it as one deploy rather than one change at a time.

Reviewing pending changes

Before you deploy, the dashboard shows you a diff of everything currently pending — what's being added, changed, or removed, across every agent server with pending work. Review it the same way you'd review a pull request before merging.

Deploy all vs. force-deploy one server

Deploy all promotes every pending change across your whole account in one action. If you only need to push changes for a single agent server — or want to redeploy a server that has no pending changes at all, to pick up something like a manual fix — you can force-deploy that one server independently.

Hot-reload vs. full refresh

Not every deploy costs the same. What changed determines how the platform applies it:

The reason for the split: workspace and skill files are read straight off the running server, so pushing new versions in place is enough. Allowed models, secrets, and channel configuration are only read when a server boots — the server has to relaunch and go through boot again for those changes to take effect. If a single deploy mixes both kinds of change, the whole thing is treated as a full refresh.

Discarding pending changes

If you change your mind before deploying, you can discard all pending changes for your account (or, per server, whatever's pending on that one) and go back to what's currently live.

Note: While an automatic rollback is running on one of your agent servers, discard is unavailable. Wait for the rollback to finish (it shows in your deploy history), then discard.

Note: While a server deletion's teardown is running, discard is unavailable — for that deletion and for every other pending change. Wait for the teardown to finish (it shows in your deploy history), then discard. A running teardown can't be stopped or undone.

Shutdown

Shutting down an agent server stops it without touching its configuration or pending changes — it's the way to pause a server you're not using right now. See Agent servers for how shutdown differs from deleting a server outright.

Deploy history and progress

Every deploy shows up in your deploy history with its own progress view, so you can see what a deploy actually did and confirm it finished cleanly, whether it was a quick hot-reload or a full refresh.

If a full refresh fails — one that replaces the agent server, whether because it changes its infrastructure (size, disk, OpenClaw version, webhooks, alert settings, adding or removing agents) or delivers a new secret — the platform automatically rolls the agent server back to its last successful configuration, if it has one. The dashboard tells you the deploy was rolled back, which part of the process it failed in, and why in plain language — never a plain "Deploy complete". In your deploy history the failed deploy shows as Rolled back, and the restore to the last good configuration appears as its own Automatic rollback entry.

Your staged changes are kept, not discarded: the failed deploy's pending change stays exactly as it was, flagged next to that agent server the next time you review pending changes. From there you can fix whatever caused the failure and redeploy just that server, or discard all your staged changes (see "Discarding pending changes" above — there's no per-server discard) if you'd rather start over — unless another deploy for that server had already started before the rollback finished, in which case its own staged changes are left in place instead. A quick hot-reload (workspace or skill file changes only, no infrastructure or secret change) never replaces the server, so it has nothing to roll back — an issue there is fixed by deploying again.

When a deploy fails, the failed deploy's entry in your deploy history shows which part of the process it failed in — building your infrastructure, your agent server coming back up, its health check, or an automatic rollback — along with a plain-language explanation, never a raw error message, and a prompt to contact support. The pending-changes review notes that the last deploy failed and was rolled back, with the same plain-language explanation of which part failed.

Right after you click Deploy, the page shows the new deploy as Starting — it never shows "No deploys yet" while a deploy is already running in the background.

Who can deploy

Suspended accounts can't deploy — resolve your billing status first. See Team & billing.

An agent server can also deploy itself: if allow_self_deploy is turned on for that server (see Agent servers), the server's own MCP token is allowed to trigger a deploy on its behalf, without a person clicking the button. Leave this off unless you specifically want that.

API and MCP

Deploys have full dashboard/API/MCP parity: deploying all or a single server, discarding pending changes, shutdown, and deploy history are all available through the API and MCP tools as well as the dashboard. See API & MCP for the resource map.