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

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.