Deploy Agent-Built Apps with GoLive: Hosting, Databases, Domains, Auth, Email, and Payments

What GoLive Does

GoLive is an open-source Agent Skill for taking an agent-built application from source code to real infrastructure. It inspects the repository, detects required services, proposes provider-specific changes, asks for approval, applies those changes through your own accounts, and verifies what it can observe.

The project is designed to bridge the gap between generating an application and operating it for real users. Depending on the app, that may involve hosting, a database, environment variables, authentication, a custom domain, transactional email, and test-mode payments.

GoLive does not require a GoLive account or hosted GoLive backend, and it does not include product telemetry. Provider access remains tied to your own accounts and logins.

Alpha warning: The current release is 0.1.0-alpha.3. Several journeys have been exercised with disposable live resources, but the broader checklist in the project roadmap is not a claim that every launch workflow is complete.

Key Features

• Repository detection: GoLive inspects the application and identifies the infrastructure and services it appears to need.
• Provider preservation: It keeps providers already used by the application instead of automatically replacing them.
• Approval-first execution: Destination accounts, resource details, changes, and available cost information are presented before provider changes are made.
• Human handoffs: Signups, browser logins, identity checks, purchases, inbox access, and other human-only actions remain under your control.
• Verification: GoLive checks observable results and clearly reports anything blocked or unverified.
• Lifecycle records: It records created resources, supports an on-demand golive status drift check, and can generate handoff artifacts.
• Controlled teardown: Resources created during a run can be removed through a separately planned and approved teardown workflow.
• Guided provider support: For providers without built-in adapters, GoLive can attempt a best-effort flow using official CLIs, official MCP integrations, APIs, or dashboard instructions.

Current Alpha Scope

The most established alpha paths cover two hosting providers and two database providers:

• Hosting: Vercel and Netlify.
• Databases: Supabase and Neon.
• Custom-domain DNS: Porkbun and GoDaddy have live-tested record-writing journeys with Vercel.
• Transactional email: Resend domain setup, DNS verification, and a real application send have been tested.
• Payments: Stripe test-mode keys, webhook registration, signed-event verification, and a real test-card payment have been exercised.
• Authentication: Supabase Auth policy configuration and an opt-in signup journey have live evidence. Password recovery and account isolation are implemented and mock-covered but have not yet completed equivalent live validation.

The live-tested application pairings are Vercel with Supabase and Netlify with Neon. Other cross-pairings may have mocked coverage rather than the same level of live proof. Cloudflare DNS is experimental and is not yet a validated alpha path.

Prerequisites

Before installing GoLive, prepare the following:

• Node.js 20 or newer.
• npm and npx.
• Git when using the GitHub and Skills CLI installation channel.
• A coding agent capable of loading skills and running commands.

Installation has been checked with Codex and Claude Code. Other agent clients are currently unverified.

Install GoLive with the Skills CLI

To install the skill once for all projects, run this command from any directory:

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

The interactive installer asks you to select an agent. Move with the arrow keys, select with Space, and confirm with Enter.

Install Noninteractively for Codex

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

Install Noninteractively for Claude Code

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

For a project-local installation, run the command from the project repository and omit --global. The installation copies the skill instructions, provider references, and prebuilt runtime. It does not connect provider accounts or deploy the application.

Install from npm

The same release is available as the golive npm package. This channel can install the skill without Git or the Skills CLI.

Codex Installation

npx golive@alpha install --agent codex

Claude Code Installation

npx golive@alpha install --agent claude

Add --global to install under your home directory instead of the current project:

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

The npm installer refuses to overwrite an existing destination and does not connect provider accounts. Both installation channels carry the same project release.

The npm package also exposes individual terminal operations:

npx golive@alpha help
npx golive@alpha version
npx golive@alpha detect
npx golive@alpha menu
npx golive@alpha plan
npx golive@alpha verify
npx golive@alpha handoff

The terminal apply operation requires an approved plan ID and explicit confirmation. These commands perform individual operations; they are not a replacement for the complete conversational skill workflow.

Start GoLive in Your Coding Agent

Open the application repository in your coding agent. If the newly installed skill does not appear, reload skills or start a new agent session.

In Codex, invoke the skill in chat with:

$golive Help me take this app live.

In Claude Code, use:

/golive Help me take this app live.

You can also provide more specific instructions in plain language:

Use the golive skill to take this app live. Keep the providers it already uses.
Show me the destination accounts and plan before changing anything.
Use test resources for now.

golive skill is not a terminal command. A Skills CLI installation does not add a global golive executable. The coding agent runs the CLI included in the installed skill directory. The npm package separately provides commands through npx golive@alpha.

Understand the Deployment Workflow

A typical run follows a controlled sequence rather than immediately creating resources.

1. Inspect: GoLive analyzes the repository and detects existing provider integrations and missing infrastructure.
2. Clarify: The agent asks which provider or account should be used when the answer cannot be determined from the app.
3. Authenticate: You complete provider login steps in a separate terminal or browser.
4. Confirm destinations: GoLive checks the connected account, team, or organization so you can verify where resources will be created.
5. Plan: The agent presents resource names, IDs when available, settings, changes, and relevant cost information.
6. Approve: No provider changes should be applied until you approve the plan.
7. Apply: GoLive provisions and connects the approved resources.
8. Verify: The agent checks the deployment, integrations, and observable application behavior.
9. Record: Created resources and verification results are saved for later status checks, handoff, or teardown.

If the plan changes after approval, GoLive requires another approval. Some work, such as attaching authentication or a domain, may occur in a follow-up plan after the initial deployment.

Example: Deploy an App That Already Uses Supabase

Suppose the repository already contains a Supabase integration but has no selected hosting provider. Begin with:

$golive Take this app live using test resources. Keep its existing Supabase integration.

GoLive may ask whether you want Vercel, Netlify, or another provider. Choosing Vercel follows the alpha’s live-tested Vercel and Supabase path. It will then determine whether to use an existing Supabase project or create a new disposable test project.

You may be asked to authenticate separately:

vercel login
supabase login

After login, let the agent identify the connected Vercel team and Supabase organization. Review those destinations carefully before approving the plan.

An approved plan can include creating the hosting project, creating or selecting the database project, transferring required environment values, deploying the application, and verifying the result. Once complete, GoLive reports the live URL, verification evidence, and any checks that remain incomplete.

Protect Credentials During Setup

Do not paste provider secrets into agent chat unless a provider workflow explicitly and safely requires a particular mechanism. On macOS, GoLive can use a native hidden-input dialog for a required API key. The dialog explains why the key is needed and where it will be stored. The value is written directly to a local credentials file rather than printed in chat or command output.

Other platforms use your editor as a fallback. Continue to inspect what is being requested, use appropriately scoped test credentials where possible, and confirm that the destination account is correct.

Verify More Than the Homepage

A successful deployment URL is only the beginning. Verification should match the application’s actual behavior. Depending on the selected path, GoLive can check areas such as:

• Whether the hosting deployment completed and serves the application.
• Whether database environment variables were wired into the deployment.
• Whether the application can connect to its database.
• Whether authenticated CRUD or session-isolation checks succeed on supported paths.
• Whether a custom domain has the required DNS records, ownership proof, and HTTPS response.
• Whether Resend verifies the sending domain and the application can perform a real send.
• Whether a Stripe test payment reaches a signature-verified webhook event.

Anything GoLive cannot observe should remain explicitly unverified. For example, inbox delivery is confirmed by a human because GoLive does not inspect the recipient’s inbox.

Check Deployment Drift

GoLive implements an on-demand golive status workflow that compares recorded expectations with observable provider state. This is a drift check, not continuous monitoring or alerting.

golive status

When using an npm installation, consult the package help for the terminal operations available in the installed alpha:

npx golive@alpha help

Run status checks after manual provider changes, before handing a project to another owner, or before planning teardown. Treat inaccessible or unverifiable resources as findings to investigate rather than assuming they are healthy.

Create a Handoff Record

The handoff workflow creates ownership documentation for the infrastructure GoLive knows about. The README reports that golive handoff --write has been exercised on a disposable Vercel-only fixture and that its generated artifacts were audited to avoid credential-shaped values.

golive handoff --write

A handoff is useful before transferring the project to a client or another engineering team. Review the generated document and its JSON counterpart, confirm every provider account and resource owner, and separately communicate secrets through an appropriate secure channel.

Tear Down Disposable Resources Safely

When a test deployment is no longer needed, ask the skill to plan removal:

$golive Plan teardown for the resources created by this project. Show me everything that will be removed before deleting anything.

The teardown path is approval-gated. Live validation included a disposable Netlify project that was blocked from deletion without --confirm-destroy and then removed after explicit confirmation. Tested cleanup has also included DNS records, Resend sending keys, and a Stripe test-mode endpoint created by GoLive.

Always inspect the teardown plan for shared databases, domains, DNS zones, email configuration, payment endpoints, and projects that may now contain valuable data. GoLive’s ability to remove a resource does not mean that removal is appropriate.

Advanced Tips

Prefer Tested Pairings for Early Experiments

For the strongest current evidence, begin with Vercel and Supabase or Netlify and Neon. Other combinations may work, but mocked coverage is not equivalent to a completed live run.

Use Explicit Test Resources

Ask for disposable or test resources while evaluating the alpha. Stripe support is specifically validated in test mode; the README does not claim equivalent live-mode payment readiness, refund handling, subscription handling, or entitlement validation.

Declare Optional Supabase Auth Journeys Carefully

Supabase Auth policy setup can manage signup, email confirmation, minimum password length, mailer settings, site URL, and redirect allowlists through an approved plan. The optional signup journey is enabled through configuration such as:

auth:
  e2e: true

Password recovery and account isolation also have configuration flags:

auth:
  recovery: true
  isolation: true
  identityPath: /your-identity-route
  isolationPath: /your-rows-route

These latter journeys are implemented and mock-covered but not yet live-validated according to the alpha documentation. Isolation requires application routes with the expected behavior; missing or unsuitable routes produce a handoff task rather than a false pass.

Treat Confirmation Flags as Safety Gates

Operations that can affect live systems use explicit gates. Examples described by the project include --confirm-dns for DNS writes, --confirm-live for certain real-account or live-value operations, and --confirm-destroy for teardown. Do not bypass these checks without reviewing the exact plan and destination.

Distinguish Built-In Adapters from Guided Providers

For an unsupported provider, GoLive checks for an official CLI, official MCP integration, or API before falling back to dashboard guidance. This remains best-effort assistance. Completion and verification depth are not guaranteed, so expect a specific blocker and next action when automation cannot continue.

Experiment with Release Features Conservatively

The project includes implemented but not live-validated preview, release-check, promotion, and rollback capabilities. Preview behavior is opt-in through golive.yaml:

release:
  preview: true

Promotion and rollback use additional opt-in values:

release:
  preview: true
  promote: true
  rollback: true

Because these capabilities are not yet live-validated, use them only in controlled test environments and inspect each generated plan. Successful deployments can record the provider’s deployment identity in .golive/state.json, allowing later capabilities to refer to a specific deployment rather than an ambiguous URL.

Important Limitations

• The project is early alpha software.
• Not every framework or new-user account setup has been validated.
• Dedicated backend servers, containers, object storage, monitoring, analytics, background jobs, and several other launch categories remain roadmap items.
• Continuous monitoring and alerting are not included; status checking is on demand.
• Cloudflare DNS is experimental rather than a validated alpha path.
• Supabase password recovery and account isolation are implemented but have not completed live validation.
• Resend custom SMTP for Supabase Auth is implemented and mock-covered but not live-validated.
• Guided providers do not receive the same completion or verification guarantees as built-in adapters.

Conclusion

GoLive provides an approval-driven way to move an agent-built application onto infrastructure you own. Start with disposable resources, prefer the live-tested provider pairings, verify destination accounts before approving changes, and review every unresolved finding. Once the deployment is proven, use status checks and handoff documentation to preserve operational context, then use the gated teardown workflow when test resources are no longer needed.