Your agent built the app — now take it live: hands-on with GoLive, the deployment skill for coding agents

Your coding agent can build the app. Getting it live — hosting, database, domain, email, payments, and secrets that don't leak — is still the part where projects quietly die. GoLive is the open-source project trying to close that gap: an Agent Skill plus a zero-dependency Node CLI that takes an agent-built product from a repository to production, on your own accounts, through an explicit pipeline: detect → plan → approve → apply → verify.

The numbers say the idea is resonating. mikehasa/golive-skill was created on September 23, 2026, and by October 1 it had collected 1,159 stars, 87 forks, 78 commits, and 5 releases under an MIT license — a pace that made it the standout signal in a crowded week of agent-tooling releases. In this tutorial you run every read-only command for real against a demo Next.js app — detect, menu, init, doctor, plan, teardown, verify — and get the account-gated half (apply) documented from the project's own verified docs, with the exact approval flags, so you know precisely where the sandbox ends and your accounts begin. Every command below was actually executed; the outputs shown are the outputs observed.

1. What GoLive actually is#

GoLive describes itself as "Take your agent-built product live: hosting, database, domain, email, payments — on your own accounts. Open-source Agent Skill + zero-dependency Node CLI: detect → plan → approve → apply → verify." It has two halves that work independently or together:

The CLI — a zero-dependency Node binary distributed on npm's alpha channel. You never install it globally; npx golive@alpha <command> fetches and runs it. The version I verified is 0.1.0-alpha.7 (bundle digest bc2b1d0a…), and update-check confirmed the channel was current on the day of testing.
The Agent Skill — a skill package (Agent Skills spec 1.0.0) that installs into Claude Code, Codex, or OpenCode and teaches your coding agent the deployment runbook: the detection order, the approval model, the secret-handling rules, and per-provider references for Vercel, Supabase, Stripe, Resend, Netlify, Neon, Porkbun, GoDaddy, and Cloudflare DNS.

The design philosophy is the differentiator: infrastructure as a plan you read before anything runs. The agent detects, proposes, and drafts; a human approves the plan; only then does anything touch production. The agent never buys anything and never creates accounts on your behalf — it plans, you own the accounts, it applies. And the project is honest about its alpha status: the docs distinguish hard rules (apply refuses without an approved plan id) from suggestions (provider defaults), rather than presenting everything as gospel.

2. What you'll need#

Node.js 20+ with npx — the CLI is zero-dependency; npx golive@alpha fetches and runs it. No global install, no build step.
Git — for the version-verified workflow and for rolling back if a plan goes sideways.
A coding agent that executes skills (Claude Code, Codex, OpenCode) — only for the skill path in Step 2. The CLI works entirely standalone.
An app to ship. I used a demo Next.js app with Supabase, Stripe, and Resend wired in — stack detection reads framework markers and environment-variable references in your code, so the richer your imports, the better the detection.
Provider accounts — but only when you reach apply. Vercel, Supabase, Stripe, and Resend accounts are yours, created by you, and the agent is structurally forbidden from making them for you. Everything up to plan runs with zero accounts.
No cost, no GoLive account. The tool itself is free and needs no signup. Provider bills are yours, as they should be.

3. Step 1 — Install and verify the CLI#

There is no installer. The documented channel is the npm alpha tag:

npx golive@alpha version

Output, exactly as observed:

golive version: 0.1.0-alpha.7 (bundleDigest: bc2b1d0a2f0ecf5e4ccf1dc5f1c40af5ba0e5a3c1c)

Note the bundleDigest: the alpha channel ships a single bundled artifact, and the digest lets you confirm precisely which bundle you ran — a small reproducibility touch most alpha CLIs skip. Then confirm the channel is current:

npx golive@alpha update-check

That returned {"ok":true,"status":"current",…}. The full command surface (help) covers detect, menu, init, doctor, plan, apply, verify, status, teardown, handoff, credentials, install, install-status, uninstall, version, and update-check — a coherent vocabulary where every verb does what it says.

4. Step 2 — Install the agent skill#

npx golive@alpha install --agent claude --global

This copies the skill into your agent's skill directory — on my machine, ~/.claude/skills/golive — containing SKILL.md (the runbook), scripts/golive.mjs (the deterministic helper the agent invokes), and a references/ folder with per-provider playbooks for Vercel, Supabase, Stripe, Resend, Netlify, Neon, Porkbun, GoDaddy, and Cloudflare DNS. Verify it landed:

npx golive@alpha install-status

That confirmed an owned copy at v0.1.0-alpha.7, distinct from the npx-cached CLI — worth knowing, because the skill your agent reads and the CLI it shells out to can drift apart, and install-status is how you check. The --agent flag accepts claude, claude-code, codex, and opencode; I verified both claude spellings resolve.

Reading SKILL.md yourself is the single most useful ten minutes in this tutorial. It is where the approval model, the secret rules, and the hard limits live — the material your agent will be operating under, which means it is the material you are delegating under.

5. Step 3 — Detect: let it read your app#

Point the CLI at your app root. Mine was a demo Next.js app with @supabase/supabase-js, stripe, and resend in its dependencies and environment references in lib/db.ts and app/api/checkout/route.ts:

cd /path/to/your-app
npx golive@alpha detect

Detection found next, supabase, stripe, and resend — every integration the demo actually had, no phantom ones — and mapped the environment variables it saw referenced: NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY flagged clientExposed: true, STRIPE_SECRET_KEY flagged clientExposed: false. It suggested db: supabase as the database default.

The clientExposed flag is the first place GoLive shows its security posture. Browser-exposed keys (NEXT_PUBLIC_* and equivalents) are public-by-design; server keys are never printable, never pasted, never echoed. Detection doesn't just inventory your stack — it classifies your secrets, and that classification flows into every later step.

6. Step 4 — Choose providers, write the plan file#

Before committing to anything, survey the options:

npx golive@alpha menu

menu lists provider options per axis — hosting, database, payments, email, domain, DNS — each with capability notes. For hosting it offered netlify and vercel as automated, plus aws-amplify, cloudflare-workers, fly, gcp-cloud-run, railway, and render as guided, with notes like "requires CLI login" or "token scopes" so you know the cost of each choice before you make it. Then lock your stack:

npx golive@alpha init --stack hosting=vercel,db=supabase,payments=stripe,email=resend

That wrote golive.yaml (version 1) with targets for preview and production. This file is the contract everything downstream reads — the plan, the apply, the verification all key off it. Commit it; it is the deployment equivalent of a lockfile.

Five glowing pipeline stages connected by circuit traces: scan, plan, human checkpoint, apply gears, and a verified shield — Illustration generated by AI Frontier Post.

7. Step 5 — Doctor: the honest gatekeeper#

npx golive@alpha doctor

On my machine — no provider logins, no tokens — doctor returned ok:false per provider with exact remediation instructions: run vercel login; run supabase login and mint a token with the right scopes; provide Stripe sk_/rk_ keys; run resend login or supply an API key. Credentials live at ~/.config/golive/credentials (mode 0600, covered in Step 8).

This is the step most deployment tools fake — a green checkmark that means "we didn't check." GoLive's doctor enumerates what it cannot reach and tells you the precise fix. And where a provider step can't be constructed until you log in, the planner says so instead of inventing success: my plan output carried explicit warnings that provider-specific steps were omitted pending login. A tool that reports its own blind spots is a tool you can trust with production.

8. Step 6 — Plan: read it before anything touches production#

npx golive@alpha plan

plan produced an ordered step list under plan id d7212020f61e, plus handoffs — items only a human can do (provider logins, identity verification/KYC, anything that costs money), each marked blocking:true with done:false. This is the artifact you review and approve, and the plan id is the capability token for the next step: nothing runs without it.

Two details worth internalizing. First, teardown is the plan's mirror: it produced a read-only inverse plan (plan id 403e5a03b054) showing exactly what would be destroyed, without destroying anything — deprovisioning gets the same review discipline as provisioning. Second, handoff lists the human-only items as a standalone checklist, so the boundary between "the agent does this" and "you do this" is a document, not a vibe.

9. Step 7 — Apply, verify, status (the account-gated half)#

Here is the honest boundary of this tutorial: apply needs real provider accounts and logins, which this sandbox doesn't have, so I did not execute it. What follows is documented from the project's verified docs (SKILL.md plus the CLI help text) — the approval model is load-bearing, so it deserves exactness even secondhand.

The rules, verbatim in spirit:

golive apply --plan <planId> --yes — apply refuses without an approved plan id and --yes. One approval covers one plan; a changed plan needs re-approval. There is no "just run it" mode.
Risky steps need explicit extra confirmation: --confirm-live for the first production deploy and anything the skill marks risky, --confirm-dns for DNS changes, --confirm-destroy for deletions and live-resource teardown.
Preview-first: the first deploy to a target goes to preview. Production happens only after preview passes its checks and the human explicitly says go. The skill encodes this as a hard rule, not a suggestion.

After apply, golive verify runs the check suite and writes .golive/report.json plus a human-readable GOLIVE_REPORT.md. In my pre-apply run it correctly reported ok:false — nothing deployed yet, so verification failing is the honest answer, and the report file still landed for inspection. golive status shows the app root, detected framework, and deployment state. The loop is closed: plan it, gate it, apply it, then prove it worked.

10. Step 8 — The secret rules (read these twice)#

This is the section that justifies the whole tool. From the verified SKILL.md hard rules:

Secrets are never printed, pasted, or echoed. Redaction shows at most the last 4 characters, and only of non-secret identifiers. A key that appears in your terminal output is a key that appears in your shell history, your scrollback, and your screenshots — GoLive treats that as a bug class, not a convenience.
Credentials live at ~/.config/golive/credentials, mode 0600, entered via hidden-input prompts (golive credentials --prompt / --set key=value). Never in shell history, never in chat logs, never in the plan file.
Client-exposure classification (from Step 3's clientExposed flags) governs what may go where: browser-visible keys are public-by-design, server keys must never be client-exposed, and the agent is instructed to check before wiring any variable into client code.
The agent never buys anything or creates accounts. No new Vercel/Supabase/Stripe accounts, no purchases, no trials started in your name. The README's "Before you hand over production access" section documents these limits for the human in the loop.
A handoff closes only by a passing check — marking it done by hand doesn't count. The checklist is evidence-driven.

A steel vault locked inside a laptop holding golden API keys, a glowing shield above, warning rays blocked at the machine's edge — Illustration generated by AI Frontier Post.

11. When to use this vs the alternatives#

Use GoLive when your agent built a real app and you want a reviewable, provider-agnostic path to production with the human holding every risky lever; when your stack spans providers (Vercel + Supabase + Stripe + Resend in a single plan); or when you want the deployment runbook to live inside your coding agent as a skill instead of a wiki page nobody reads.

Use the plain provider CLIs (vercel, supabase) when you're deploying a single-provider app and already know the dashboard — the plan/approve ceremony is overhead you don't need.

Use an all-in-one platform path when you want one vendor to own hosting, database, and auth and you'll accept the lock-in that comes with it.

Don't use GoLive when you don't have provider accounts yet — run detect through plan freely, but apply will (correctly) wait. And don't reach for it expecting full autonomy: the tool is architected against the agent acting alone on production. That constraint is the feature.

12. The takeaway#

The interesting thing about GoLive isn't the provider list — it's the shape. An agent skill that turns deployment into a readable plan with explicit human gates, where the agent's power is bounded by plan ids and confirmation flags, where "not logged in" is reported as a fact with a fix instead of a silent skip, and where secrets have a classification, a vault, and a redaction policy before the first deploy ever runs.

If you take one practice from this tutorial into your own agent workflows, take this one: separate planning from applying, and make the plan the thing the human approves. Every production incident story starts with someone typing "yes" to a command they never read. GoLive makes the read the workflow — detect, plan, approve, apply, verify — and gives your coding agent the runbook to execute it without improvising. Install the alpha, run the read-only half against your own app today, and you'll know exactly what production will ask of you before it asks.

Sources: github.com/mikehasa/golive-skill (MIT); the golive@alpha npm channel, version 0.1.0-alpha.7, verified October 1, 2026. All read-only commands executed live; apply documented from the project's verified SKILL.md and CLI help.