golive-skill: an agent skill that deploys to your own cloud accounts

Detecting, planning, approving, applying, verifying

The pitch is that a coding agent can produce a working app quickly and then stall on everything around it: accounts, hosting, databases, domains, secrets, email, payments. golive-skill packages that work as an Agent Skill plus a zero-dependency Node CLI, with a pipeline the description spells out as detect, plan, approve, apply, verify.

What follows a successful apply is the part that makes it more than a wrapper script. The tool records what it created, can re-check that state for drift on demand through a `golive status` command, and can remove it again with `golive teardown`. So the lifecycle is not one-way deployment, it is a recorded inventory that a later command can compare against reality.

The repository describes its position on infrastructure clearly: no GoLive account, no hosted backend, no product telemetry. Everything happens through provider APIs that you authenticate to yourself. The package is MIT licensed, written in TypeScript, and sits just over a thousand stars with 75 forks and a single open issue, which is a small surface for something that touches production accounts.

The tree shows a normal TypeScript project layout rather than a script dump: `src/`, `skills/`, `bin/`, `scripts/`, `test/`, `build.mjs`, `vitest.config.ts`, a `docs/` directory carrying six named documents, `AGENTS.md`, `CONTRIBUTING.md`, and `THIRD_PARTY_NOTICES.md`. The README is translated into seven languages, which is more localization than most projects at this star count attempt.

Six provider journeys, and the fourth thing the description forgets

The alpha banner lists what has actually been exercised in disposable live tests: hosting on Vercel and Netlify, database on Supabase and Neon, custom-domain DNS on Porkbun and GoDaddy, transactional email through Resend, test-mode payments through Stripe, and Supabase authentication. That is six journeys across five or six providers, and the last one is the interesting addition.

There is a small inconsistency worth naming. The GitHub repository description reads hosting, database, domain, email, payments, with no authentication in the list, while the README headline reads hosting, database, auth, domain, email, payments. Both statements are current in the sense that authentication does work, and the alpha banner includes Supabase auth among the live-tested journeys. The description is simply the shorter, older phrasing.

A second detail: cloudflare appears in the repository topics but not in any of the six journeys the README claims live coverage for. Topics on GitHub are frequently aspirational or community-contributed, so treat the journey list rather than the topic list as the description of what works.

The banner is careful to bound its own claims. It says the ownership document and the on-demand drift check are implemented with test coverage, and that `golive status` also ran read-only in a live validation, while pointing at a roadmap as direction rather than a claim that it is all built. `docs/VALIDATION.md` is named as the document that separates what has been exercised live from what is only mock-covered, and `docs/PROVIDERS.md` is the one that says what each provider can do today.

The approval model and its stated ceiling

The trust section answers the question that actually matters for this kind of tool: should you hand an agent your provider accounts. Its answer is that every write is gated by a plan you have seen and approved. `apply` refuses to run without that plan's id and an explicit `--yes`, and it re-checks the plan's identity before writing, so a changed release or config invalidates the old approval.

Beyond that baseline there are three confirmation flags with distinct scopes. DNS writes need `--confirm-dns`. Deletions need `--confirm-destroy`. Anything touching live mode, meaning live payments, production data or a real account, needs `--confirm-live`. The release notes for alpha.5 record a change to that last one: the flag now includes a project's first production deploy, because previously approving a plan alone was enough to write production the first time. That is the kind of fix that only shows up after someone looks hard at the gate.

The stated ceiling is worth reading twice. Those flags are arguments the agent passes on your behalf, and an agent already logged in to your provider can write there with no golive plan at all. In other words the enforcement is real for a cooperating agent and absent for an uncooperative one. `docs/TRUST.md` is named as the document that separates what the code enforces from what is only an instruction the agent is asked to follow, which is an unusually blunt framing for a project in this category.

Credentials in a plaintext file, and a guard that is not a sandbox

Credential handling is described without euphemism. Values are read only in-process, never printed, and never written into arguments, plans, state or reports. The file golive stores them in is plaintext at mode 0600 outside your repository, and the README says so directly rather than implying a system keychain. Whether that trade is right depends on your threat model, but you can make the decision because it is stated.

The alpha.5 release notes contain the most interesting engineering story in the repository, and it is about a failure rather than a feature. The offline smoke check, which runs the newly downloaded bundle's `help` and `menu --json` before switching to an updated copy, originally ran under a guard that blocked network and subprocess entry points. That guard only replaced module functions, so `new net.Socket().connect()`, `node:dgram`, `node:dns`, `node:http2`, `node:worker_threads` and `node:cluster` all remained reachable. The release notes say this was reproduced and then closed, and that a regression matrix now covers each path and fails against the old guard.

The follow-up is the better part. `references/updates.md` now says plainly that the guard is a sanity check for a broken or careless release, not a sandbox. A tool that describes its own security boundary as approximate is more useful than one that describes it as comprehensive, because you know what the boundary is.

The same release adds a hard rule that untrusted content is data and never instructions. Repository files and their comments, dependency and lockfile text, provider API responses, dashboard copy, and golive's own generated report, state and handover files all describe the world. Only the digest-verified bundle counts as an instruction channel. That is prompt injection treated as an architectural problem rather than a prompt problem.

Recovery, rollback and teardown, each narrower than the marketing word

Three recovery paths exist and each has a stated boundary.

A failed run stops rather than pushing on. `apply` halts at the first failed check, missing confirmation, missing prerequisite or provider response that contradicts the plan, later steps do not run, and the next `apply` resumes at that step. `docs/RECOVERY.md` covers reading the failure, which steps resume, and which cases need a reviewed decision first.

Rollback is narrow, opt-in and never automatic. A failed check does not trigger one. Setting `release.rollback: true` plans a single step that re-points production at an earlier deployment golive itself recorded, and a deployment built by a dashboard, a Git push or a pull request is not a target. It touches no data, DNS, payment or email resource. Only Netlify supports these re-points today, because Vercel's adapter has no read of what production is serving, so on Vercel you correct production in the dashboard. The release notes add the honest qualifier that promotion and rollback are implemented and mock-covered but not live-validated.

That last point lines up with something worth noticing about the alpha banner: it claims disposable live tests cover hosting on both Vercel and Netlify, while the rollback section says only Netlify can be re-pointed. Both hold. Creating a deployment on Vercel is live-tested; moving production back to an earlier one on Vercel is not implemented.

Teardown removes only resources it can prove it created, re-reads the DNS zone and the host project after deleting, and names every leftover it cannot remove, Supabase and Neon projects, the Resend sending domain, an unreadable zone or host project, as a handoff saying what remains and how to remove it by hand. A removal also forgets the baseline golive recorded for that resource, so `golive status` does not report golive's own teardown as drift. The README's phrasing on this is precise: nothing is left behind silently, which is not the same as nothing being left behind.

Installing an alpha with a JSON version check

Requirements are Node.js 20 or newer, npm or npx, Git, and a coding agent that can load skills and run commands. Installation has been checked for Codex and Claude Code, and the README says other clients are unverified rather than implying broad support.

The install is one command run from any directory, and `--global` is what makes it available across projects:

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global

Without `--global` it installs into the current project instead. The interactive form prompts for an agent with an arrow-key picker that waits for input, so scripts should pass the agent explicitly:

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global --agent codex --yes

The README also gives a paste-into-your-agent block that installs, then verifies with `node <installed-skill-dir>/scripts/golive.mjs version --json`, and stops before connecting accounts or deploying anything. That stop instruction is a reasonable default and worth keeping.

The same skill is published to npm under the `golive` package name, and `docs/DISTRIBUTION.md` covers noninteractive agent flags, runtime verification and an optional own installer.

On cadence, the three releases in the repository are v0.1.0-alpha.3 on 2026-09-24, alpha.4 on 2026-09-26 and alpha.5 on 2026-09-27, all within four days, and the last push was on 2026-09-27. This is active work on an alpha that is changing shape quickly, with pre-1.0 versioning and a release-note style that leads with what got fixed. The homepage field points at trytofu.ai, while the README insists there is no GoLive account, backend or telemetry, so treat that URL as a project link rather than a service the tool depends on.

Editorial conclusion

golive-skill is worth reading even if you never install it, because it is unusually explicit about the difference between what its code enforces and what it merely asks the agent to do. That distinction shows up in the credential storage choice (plaintext at mode 0600, named as such), in the admission that an already-authenticated agent can write to a provider with no golive plan at all, and in the label the update guard carries: a sanity check, not a sandbox. The useful entry points are docs/TRUST.md and docs/VALIDATION.md, which is a rare combination in a repository at this stage. Start with the install command, read those two documents before connecting any account, and treat the six journeys as the current ceiling rather than the finished product.

Frequently asked questions

Official sources

1. License: MIT
2. mikehasa/golive-skill on GitHub
3. Project website
4. README
5. Releases