Update what's live
Ship a change to the same link. What replaces what, what stays, and how to tell the new version is actually the one serving.
Deploying again is the same request as deploying the first time.
Ask for it
deploy that again
or, if your agent has been working on several things:
push the changes to the recipe box app
The link does not change. Whoever you sent it to keeps using the same address, and you don't have to tell them anything.
What changes and what doesn't
| Thing | What happens on a redeploy |
|---|---|
| Your files | Replaced wholesale by what your agent sends this time |
| The URL | Unchanged |
| HTTPS | Unchanged — nothing to renew, ever |
| Who can open it | Unchanged. A private app stays private; a public one stays public |
| Environment variables | Unchanged — they're set at creation and survive every deploy |
| The runtime | Unchanged unless your agent explicitly changes it |
A deploy replaces, it doesn't merge
What's live afterwards is exactly the files sent this time — a file your agent stops sending disappears from the app. That's what makes it predictable, but it does mean a partial send ("just update index.html") removes everything else. Deploy the whole project.
Confirm the new version is the one serving
open the link and check the change is there
There is a real gap between "the build was accepted" and "the new code is answering requests" — a fresh deploy can still report the previous version as running for a few seconds. So check the change itself, not the status.
Changing the runtime
Your agent can switch an app between runtimes on a deploy — a static site that grows a Node server, say. It's the same request:
this needs a server now; redeploy it as a Node app
The address, the access list and the environment variables all survive that.
There is no rollback
agenthost keeps no "previous version" you can restore with a tool call. If you want to go back, the answer is to deploy the earlier files again — which is easy if your project is in git, and worth setting up if the app matters.
put the version from before this morning's changes back online
Your agent can do that from your own files. It cannot pull an old version out of agenthost.
Under the hood
Every deploy pushes your source as a commit to a private git repository we keep for the app, then triggers a rebuild. The response comes back as soon as the build is queued — see Checking a deploy for how to tell when it's really up.
An invite-only app has its access gate re-applied automatically after a rebuild, because rebuilding the container regenerates its proxy configuration. agenthost handles that on its own — after the build, and on a background sweep of every private app — so a redeploy never quietly publishes what you shared with a few people.