Images & rollbacks
Every deploy you make produces an image — a frozen, complete snapshot of your app. Images are how agentry gives you instant rollbacks, zero-downtime updates, and the ability to move an app between servers. This page is the whole story.
Images vs deployments
Two words, two different things:
| What it is | Where you find it | |
|---|---|---|
| Deployment | A running app. Has a live URL, serves traffic, can crash and restart. | Deployments page |
| Image | A saved snapshot of your app, built once. Doesn't run on its own. | Images page |
A deployment is just an image that happens to be running. Stop the deployment and the image is still there, ready to run again.
Every time you click Deploy, agentry builds a new image and saves it to your registry. Nothing is ever overwritten — last week's image is still sitting there, exactly as it was.
This needs a registry
Saved images live in a container registry you connect (GitHub Container Registry or Docker Hub). It's a one-time setup and it's what makes everything below possible. See Connect a registry. Without one, a deploy still runs, but there's no saved image to roll back to.
The Images page
Open app.agentry.run/images. You'll see every image you've built, grouped by app and newest first. Each entry shows its tag (a build timestamp like 20260613T135400Z) and when it was created.
From here you can do two things with any image: deploy it to a new URL, or delete it.
Rolling back
The reason images exist. A new version is broken and you want the previous one back:
- Open the misbehaving deployment → Redeploy.
- You get a list of every image for this app. The one currently running is marked.
- Pick the last image you know was good.
- Confirm.
The deployment swaps to that image in place — the URL and any custom domain stay exactly the same — and you're back on a working version in seconds. No rebuild, no DNS changes, no waiting.
You can roll forward the same way: pick a newer image to ship an update.
Shipping an update
Two equivalent paths, depending on where you're standing:
- From the sandbox — the agent changed your code; click Deploy on the sandbox. agentry builds a fresh image and the running deployment swaps to it automatically. (Covered in Ship an app.)
- From the deployment — click Redeploy and pick a newer image you've already built.
Either way, same URL, same custom domain.
Building an image without deploying it
Sometimes you want to bake an image now and decide later whether to ship it — stage a release, or build on one server to run on another.
On the sandbox's Deploy panel, click Build only. agentry builds and saves the image to your registry without starting a container or allocating a URL. When it's done, it shows up on the Images page. Nothing goes live until you choose to deploy it.
A build-only run produces an image, not a deployment — you won't see a half-finished entry cluttering your Deployments page.
Reusing an image on another server (or another app)
Because an image is a portable snapshot, you can run it anywhere:
- Go to the Images page.
- Find the image and click Deploy this revision.
- Choose the server to run it on.
- Deploy it to the same server and it behaves like a rollback (reuses the existing URL).
- Deploy it to a different server and you get a brand-new deployment with its own URL — the original keeps running until you stop it.
This is how you promote an app from your laptop to a production box: build it once, deploy the same image to the bigger server.
Cleaning up
Old images cost a little registry storage and nothing else. Delete any you're sure you'll never roll back to from the Images page. The image currently backing a running deployment is always safe — deleting it won't stop the running container, but you won't be able to roll back to it, so think twice.
Next
- Connect a registry — the one-time setup that powers all of this.
- Ship an app — the deploy flow from the sandbox.
- Custom domains — your domain survives every rollback and update.