Ship an app

A working sandbox → a production URL, with one button.

When to deploy

• The preview URL looks right when you click around in the browser.
• The app actually responds on its port (ask the agent: "probe the app and confirm it returns 200" — it uses app_probe).
• The data layer is wired (binding env is present, not a stubbed fake).

If any of those is off, fix it first. The Deploy button runs its own check and will reject a broken build — so deploying broken code mostly wastes a few minutes; it doesn't break anything that's already live.

Deploy from the dashboard

1. Open app.agentry.run/sandboxes.
2. Click the sandbox you want to ship.
3. Click Deploy.
4. Set the options:
   • Access — who can reach the app (see Access modes below). Defaults to org-only (signed-in members of your organization).
   • Env — pre-filled from the sandbox's current environment. Edit or override any value here.
   • Advanced (optional) — the port to check before building, and a custom URL slug.
5. Click Deploy. The button turns into a live progress indicator.

There's no "project path" to fill in — a sandbox holds one project, and agentry builds it.

What happens next

agentry runs four steps, each visible on the deployment page in real time:

1. Check — confirms the app builds cleanly (e.g. npm run build for a Node project). If it fails, you see the exact error and the deploy stops here. Nothing live is touched.
2. Build — packages your app into a production container image. Your stack is detected automatically — Next.js, Vite, Python, Go, Rust, Ruby, and more.
3. Save — pushes that image to your registry, so you can roll back to it later. (No registry connected? The step is skipped and the image stays local to this server — the deploy still runs, you just can't roll back or move it to another server.)
4. Run — starts the container, opens the bridge route, and hands back a stable public URL.

A clean Node app deploys in 30–90 seconds. Later deploys of the same project are faster (the build reuses cached layers).

Your deployment URL

Once the deploy reaches running, the dashboard shows the URL:

<your-app>-<random-suffix>.agentry.live

For example my-app-3f7e2a1c.agentry.live. The random suffix is deliberate — for public apps it's the only thing standing between the URL and the open internet, so don't strip it.

The URL is stable. It survives every redeploy and rollback, so you can bookmark it, share it, and point a custom domain at it.

Shipping an update

Your AI changed the code in the sandbox; you want the live app to reflect it. Just deploy again:

1. Open the sandbox, click Deploy.
2. agentry builds a fresh image and the running deployment swaps to it — same URL, same custom domain, zero reconfiguration.

Every deploy is a new image, kept in your registry. That's what makes the next section possible.

Rolling back

Shipped something broken? You don't rebuild — you point the deployment at an image that already worked:

1. Open the deployment → Redeploy.
2. Pick any earlier image from the list.
3. Confirm. The URL stays the same; you're back on the good version in seconds.

This is covered in full — including building an image without deploying it, and reusing one app's image for another — in Images & rollbacks.

Access modes

Every deployment has an access setting, chosen in the Deploy form and changeable later on the deployment's page:

• Only me / org (default) — only signed-in members of your agentry organization can open it. Unauthenticated visitors are bounced to sign-in. Best for internal tools and admin panels.
• Public — anyone with the URL can open it. The random suffix is the only secret. Best for landing pages, demos, anything you'll share widely.
• Password — anyone with a shared passphrase can open it. agentry generates the passphrase and shows it to you once. Best for a private link you hand to a client or a small group.

Need real user accounts?

Access modes are a coarse gate on the whole app. If you want individual users to sign up and log in — with email/password or Google/GitHub/etc. — that's the Authentication feature, and it works alongside any access mode.

Stopping a deployment

On the deployment page, click Stop. The container stops and the URL goes offline, but the row stays as a record — you can redeploy it later. To remove it entirely, click Dismiss after stopping.

When the build fails

The deploy aborts and shows the exact error on the deployment page. The usual causes:

• An import the dev server tolerated but the production build doesn't.
• A type error in a code path only the production build exercises.
• An env var the build references but that isn't set.

Fix it in the sandbox (or ask the agent to), then deploy again. Failed attempts don't change anything that's live.

Build works, but the app misbehaves

The container is running but the URL returns a 500, a blank page, or odd behavior:

1. Check the logs. Deployment page → Logs. Most issues show up here as stack traces.
2. Check env vars. A missing or wrong value is the #1 cause. Edit it in the Env tab and redeploy.
3. Check the database. If the app talks to a DB, opening the URL should make a connection appear in your DB's monitoring. If it doesn't, the connection env var probably isn't reaching the container.

See Logs + status for the full diagnostic playbook.

Custom domains

Serve your app from app.yourcompany.com instead of *.agentry.live. You add a couple of DNS records, agentry provisions the HTTPS certificate automatically, and the custom domain rides the same deployment. Full walkthrough: Custom domains.

Next

• Images & rollbacks — how images work, and how to roll back or reuse one.
• Environment variables — how env flows from dev to deploy.
• Logs + status — what's running, what failed, what's slow.
• Authentication — add user login to a deployment.