DEV Community: dino

Your AI agent deployed the app. Did it tell you the link expires?

dino — Tue, 21 Jul 2026 04:41:09 +0000

Note: I'm the maker of openpouch. This post is about an agent-UX lesson we learned from our first real user — honest limits included. Feedback very welcome.

Our first real user never opened our website. He talks to his coding agent; the agent deploys with openpouch; he gets a link. Exactly how it should work — the agent is the only UI.

Three days later his app was gone.

Nothing crashed. Anonymous previews expire after 72 hours — that's the free tier, and it's documented everywhere an agent looks: the CLI result, the JSON, the docs, llms.txt. The agent knew. It just never told him. When the deploy succeeded, the agent summarized the exciting part ("Your app is live! 🎉 Here's the link") and dropped the boring part (expiry date, how to keep it). The human learned about the 72-hour rule the hard way: by watching his app 404.

He told us (translated): "The AI has to actively spit that out at me — how long it's valid, and what my options are. Otherwise how would I ever know?"

He's right. And the fix turned out to be an interesting API-design lesson for anyone building tools that agents — not humans — consume.

The relay gap

When a human uses your CLI, your output IS the UI. When an agent uses your CLI, your output is raw material for a summary you don't control. Agents compress. They keep what looks like the point (the URL) and cut what looks like boilerplate (the caveats). We had tested this across several coding agents: the expiry info was reliably read — and unreliably relayed.

You can't fix that with more docs. The agent already read the docs. You have to design the response so that relaying is the path of least resistance.

The fix: a field whose name is the instruction

Since openpouch@0.3.3, a healthy deploy result carries a top-level field called tellYourUser:

{
  "ok": true,
  "url": "https://sunny-otter-x4kq.openpouch.sh",
  "healthStatus": "healthy",
  "deployment": { "expiresAt": "2026-07-19T09:12:44.000Z", "ownership": "anonymous" },
  "tellYourUser": "Your app is live at https://sunny-otter-x4kq.openpouch.sh. It's a free preview and expires on Sat, Jul 19, 2026 (UTC). To keep it: save it to a free account, redeploy any time, or upgrade for apps that stay up while they're used (paid plans from $15/month — openpouch.dev/pricing). Doing nothing is fine too — it just expires."
}

Design decisions that matter more than they look:

The field name is imperative. Not notice, not meta.expiry — tellYourUser. An agent deciding what to do with this field has the answer in the key itself. This is the whole trick: schema as instruction.
It's pre-written, ready to relay. No assembly required. An agent can paste it verbatim into its summary — least-resistance path. Plain language, no jargon, exact date instead of "72 hours" (a human shouldn't have to do date math).
It only appears on healthy deploys. A degraded app must not produce a cheerful hand-off block — absence is also a signal.
It never contains the claim link. The claim URL is a capability token (whoever has it can take the preview). It stays in a private local file; the hand-off text describes the ways to keep the app, not the secret.
All options, including "do nothing". Expiry pressure without an exit is a dark pattern. "Doing nothing is fine too" is in there on purpose — the user asked for the options "so I can think about it", not for a countdown.

Days after shipping it, the same user's agent told him the exact expiry date, unprompted, twice. His review: "the warning is still there … better."

The generalizable lesson

If agents consume your API, assume three things:

Your response is a hand-off, not a display. Somewhere behind the agent is a human who will get a summary of your output. Decide what must survive that summary, and package it.
Name fields like instructions when you need behavior. tellYourUser, nextCommands, suggestedCommand outperform metadata, info, details. Agents act on affordances.
Machine-truth next to human-truth. The same result carries deployment.expiresAt (ISO, for logic) and the friendly sentence (for relaying). Never make an agent choose between parsing and explaining.

None of this is openpouch-specific. If you're building a payments CLI, a migration tool, a cron service — anything an agent operates on a human's behalf — the relay gap applies to you.

Try it

The whole thing works without an account (that's the point):

npx openpouch deploy . --json

Or as native MCP tools in Claude Code (every capability typed, deliberately no approve — production stays human-gated):

claude mcp add openpouch -- npx -y @openpouch/mcp

The relay lesson kept paying off, by the way: the newest fields follow the same pattern. deploy --app <name> gives an app one stable URL across all future redeploys — and the result says urlStability: "stable" so the agent can tell its user "the link you shared keeps working" instead of guessing. data push/data pull move real files in and out of an app's persistent volume, which turns "migrate my app and keep the data" into something an agent can genuinely finish.

Honest limits, current as of July 2026: Node/static only (no Python runtime yet), no custom domains yet, anonymous previews expire after 72h (accounts keep apps alive while they're used; stable-URL apps and persistent volumes are account features). Everything is open source (Apache-2.0): https://github.com/openpouch/openpouch — and the agent-facing entry point is https://openpouch.dev/llms.txt.

What would you put in tellYourUser? And what's the field you wish agent-facing tools shipped?

Deploy an app from Claude Code in 60 seconds — no dashboard, no CAPTCHA

dino — Fri, 10 Jul 2026 03:23:50 +0000

Note: I'm the maker of openpouch. This is a how-to, written honestly — it's a technical preview and I'll be clear about the limits. Feedback very welcome.

Your coding agent can write the app. It can write the tests. Then it hits deploy — and the cloud asks it to click a fire hydrant.

That's the thing nobody designed for: every deploy target assumes a human at a browser. CAPTCHAs, "verify you're human", dashboard-only toggles, OAuth flows that dead-end in a headless tab. An agent that can ship software can't get past a bot-wall built to stop bots.

openpouch is the opposite of that: one command to a live URL, no account, no dashboard, no human-verification step anywhere. It ships as a CLI and an MCP server, so it drops into Claude Code (or Cursor, Codex, OpenClaw, …) as native tools. Here's the 60-second version from Claude Code.

1. Add the MCP server

claude mcp add openpouch -- npx -y @openpouch/mcp

That's it — a zero-dependency stdio MCP server, pulled on demand via npx. It exposes the full deploy lifecycle as 13 tools (openpouch_deploy, openpouch_verify, openpouch_logs, openpouch_inspect, openpouch_rollback, openpouch_list, …). There is deliberately no approve tool — approving a production deploy is human-only, in every harness. An agent literally cannot approve its own prod deploy. Previews, though, it just ships.

Can't attach MCP servers mid-session? You can prove the whole toolset from any plain shell — the recipe is in the docs. Or skip MCP entirely and use the CLI (npx openpouch deploy, same functions, --json + exit codes).

2. Let the agent deploy

Point Claude Code at any app folder and ask it to deploy. Under the hood it calls one tool:

// openpouch_deploy  { "dir": "." }

For a full-stack app (an API behind the frontend), add a health path so the agent proves the backend is actually up, not just the shell:

// openpouch_deploy  { "dir": ".", "healthPath": "/api/health" }

openpouch builds the app on deploy (a raw Vite/React/Svelte source folder or a Node server with a build step — no local build needed), starts it in a hardened container, and health-checks it before telling you it's live.

3. What comes back

The result is structured JSON — exactly what an agent needs to make a decision, plus a plain-language line for the human running it:

{
  "ok": true,
  "url": "https://your-app-x1y2z3.openpouch.sh",   // the shareable link
  "healthStatus": "healthy",
  "summary": "Your app is live at https://…  — anyone you share it with can open it right away.",
  "nextCommands": { "verify": "…", "logs": "…", "inspect": "…" },
  "evidence": ["deploy.manifest.json", "deploy.evidence.json", "DEPLOYMENT.md", "…"]
}

Three things worth calling out:

The live URL is the primary result. You hand it straight to a client — no build settings, no dashboard tour.
A plain-language summary is safe to relay to a non-technical human verbatim.
Deployment truth lands as files in the repo (DEPLOYMENT.md, deploy.evidence.json, …). After a context reset, a fresh agent re-reads those files and knows exactly what's deployed, where, and how to resume. No hidden state.

If the app comes back unhealthy, openpouch_logs shows the captured install/build/app output (tagged [install]/[build]/[app]) — the agent reads the cause, fixes it, redeploys, verifies. A real self-repair loop.

Honest limits (it's a technical preview)

Previews are ephemeral — they vanish after ~72h unless claimed (claim → 7 days). Great for demos, agent-generated sites, and client previews; not yet for payment-grade production.
Env vars/secrets work for dynamic apps (--var / --env-file, injected at runtime, reported by name only), but they're ephemeral — no persistent storage yet.
It's free during the preview. Paid, persistent hosting is on the roadmap.
It runs on openpouch's own infrastructure (not a wrapper over someone else's dashboard), and abuse is controlled with agent-compatible quotas and rate limits — never a CAPTCHA, because that's exactly what breaks agents.

Try it

npx openpouch deploy

Open source, Apache-2.0: github.com/openpouch/openpouch · docs (for you and your agent): openpouch.dev

If your agent can write software, it should be able to ship it. That's the whole idea.