GoLive keeps a launch plan tied to your provider accounts
GoLive detects an app's service needs, builds a plan, and applies approved changes through your hosting and service accounts. Its useful promise is an inspectable record of what was created and what verification couldn't establish. For a solo builder moving an agent-built app onto Vercel or Netlify, that could replace a collection of loosely remembered dashboard actions. It also means giving a coding agent access to resources that can cost money and affect users.
Our 232-file checkout occupied 5.1 MB and contained about 78,891 lines of source. The skill includes a bundled runtime, while source development uses pnpm. Those are different entry points. The README documents installation for Claude Code and Codex and says installing the skill alone doesn't connect accounts or deploy. That separation is sensible: you can inspect the workflow before putting a provider session within the agent's reach.
What happened when we ran it
Our GoLive source install failed with exit 1 after 9 seconds at commit 8fd3d8e. The log names ERR_PNPM_IGNORED_BUILDS and identifies the ignored script as esbuild@0.28.2. It tells the operator to run pnpm approve-builds to choose which dependency scripts may execute. The tail repeats that error and says the lockfile passed supply-chain policies. The recorded failure concerns script approval, not a reported lockfile-policy violation.
We cloned the repository on 2026-10-12 in the lab-node:22 image, inside an unprivileged Debian container with 3 CPUs and 8 GB of RAM and no secrets. The scan found 1 CI workflow, no Dockerfile, and a tests directory. No build, test, dependency-count, or audit result followed in the supplied measurement. Approving the script is the log's suggested next action, not a fix we verified or a reason to authorize every dependency script.
Approval flags do not isolate an already logged-in agent
The GoLive approval and credential rules require a plan identifier and explicit confirmation for applying changes. Extra flags cover DNS writes, destruction, and live-mode actions, including the first production deploy. GoLive also checks that an approval still matches the release and configuration. These controls help prevent a stale plan from silently becoming a different set of writes.
Our 9-second install failure happened before those controls could be exercised. The README itself acknowledges their limit: an agent passes the flags, and an agent already logged into a provider can use another command to write there. Credentials are stored in a restricted local plaintext file outside the repository, rather than a keychain. I would use separate test projects and narrowly scoped access while evaluating GoLive, instead of treating its plan mechanism as an account-level permission boundary.
Rollback covers recorded Netlify deployments, not your whole stack
The README describes deployment rollback as an opt-in change to a deployment GoLive previously recorded. It does not restore database data, DNS, payments, or email resources. Netlify supports the documented repointing path, while Vercel requires correction through its dashboard because GoLive's adapter cannot read what production serves. Promotion and rollback are described as implemented with mocked coverage, without live validation. That is a specific operational limitation, not just an alpha label.
The measured source snapshot occupied 5.1 MB, but the resources it could eventually create live outside that checkout. Teardown deletes only resources GoLive can prove it created and reports leftovers requiring manual removal. Supabase and Neon projects and the Resend sending domain are among the documented manual handoffs. A cleanup report therefore needs a person who will act on it. If you expect one command to reverse an entire launch, this workflow won't meet that expectation.
A reachable deployment still needs application checks
GoLive writes golive.yaml and local state and report files so later work can identify resources and unfinished actions. Its verification separates pass, failure, warning, and skipped results. The README explicitly explains that a ready deployment doesn't prove the app works, and that an environment-variable name can exist with the wrong value. Those distinctions are useful when a signup flow or payment callback depends on settings spread across several providers.
The 9-second failure gives us no independent deployment verification to add. The maintainers describe narrower disposable-provider journeys and distinguish them from guided providers and unvalidated combinations. Account creation, purchases, identity checks, and some email confirmation steps remain human work. Continuous monitoring and general backup restoration are not delivered by the on-demand status command. Match the supported adapter to your actual provider before reading a broad launch checklist as product coverage.
Alpha.9 has recent maintenance and explicitly limited evidence
The last push was 2026-10-11, the day v0.1.0-alpha.9 was published. GitHub returned 1,277 stars and 1 open issue or PR. Recent closed pull requests include releases and monitoring adapters, so the small open count doesn't mean nothing is happening. The latest release added UptimeRobot support and explicitly calls it mock-covered without a live run. I would preserve that qualifier in an adoption decision.
Pulumi fits when you want infrastructure definitions in a programming language, while OpenTofu fits declarative infrastructure managed outside a conversational skill. Both ask you to own the configuration rather than accept GoLive's launch workflow. Choose GoLive when its supported providers match a disposable app launch and its handoff record would save you work. Before connecting an important account, resolve the measured esbuild approval blocker and inspect the exact plan your agent proposes.