Deploys & pending changes
The pending-changes staging model, hot-reload vs. full refresh, discarding, shutdown, and deploy history.
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:
| What changed | What happens | Roughly how long |
|---|---|---|
| Workspace/soul document edits, skill file edits | Hot-reload — the running agent server picks up the new files in place | Fast, no reboot |
| Model allowed-list changes (company, server, or Teammate) | Full refresh — the agent server relaunches and boots fresh | ~5 minutes |
| Secret changes (including egress host allowlists) | Full refresh | ~5 minutes |
| Messaging/channel configuration changes | Full refresh | ~5 minutes |
| Agent server size or disk changes | Full refresh | ~5 minutes, sometimes longer |
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: Trial accounts with no live agent server yet can't discard everything — doing so would wipe your only configuration and leave you with nothing to deploy. Deploy at least once, or upgrade, before a full discard is available.
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.
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.