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

> Source: <https://dev.to/digit500/deploy-an-app-from-claude-code-in-60-seconds-no-dashboard-no-captcha-hf8>
> Published: 2026-07-10 03:23:50+00:00

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](https://openpouch.dev) 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](https://openpouch.dev/docs/MCP.md). 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](https://github.com/openpouch/openpouch) · docs (for you *and* your agent): [openpouch.dev](https://openpouch.dev)

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