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.
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).
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.
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:
summary
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.
--var
/ --env-file
, injected at runtime, reported by name only), but they're ephemeral — no persistent storage yet.
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.