VibeHost

Build, deploy, and share with an agent

Your coding agent builds, deploys, and shares the app, with no person needed in between.

Say you're working with a coding agent such as Claude Code, Codex, Cursor, Antigravity, Antigravity CLI, Windsurf, OpenCode, Copilot CLI, or Hermes Agent, or with a chat client like ChatGPT. You've written some code with the agent's help, and you want the agent to ship it, share it, and handle the changes that follow.

This recipe walks through that case, where the agent owns the whole deploy lifecycle.

Pre-flight

One-time setup:

  1. Sign up at vibehost.com (Google sign-in works).
  2. Connect your agent to the MCP server at https://api.vibehost.com/mcp. Setup is short, and each guide has the exact config:
  3. The first tool call starts OAuth. Approve it in the browser.

After this, your agent has every MCP tool and can run the whole lifecycle.

The conversation

Open a chat with your agent in the project directory. Type:

Deploy this folder as a new VibeHost app called my-agent-site. It's a Vite + React build.

Then make it public, set up a custom domain at agent-demo.example.com, and give me the URL + DNS instructions.

The agent runs these steps in order:

  1. Inspect the project. It reads package.json and finds the build command.
  2. Build. It runs npm install and npm run build in your shell. You may be asked to confirm.
  3. create_app(name: my-agent-site, runtime: static) creates the app.
  4. Upload the build output and deploy it. Choosing an upload path lists the steps and the fields each call returns. An agent that can reach the API sends the files over signed URLs, and one with no HTTP egress writes them with create_file.
  5. set_app_visibility(appId, visibility: public) opens the app to the internet.
  6. add_custom_domain(appId, hostname: agent-demo.example.com) prints the DNS record.
  7. Report back. The agent gives you the URL and the CNAME you need to add.

Most of these are write tools. Well-behaved coding agents (Claude Code, Cursor, Codex, Antigravity, Antigravity CLI, Windsurf, etc.) ask you before each one, and you can pre-approve a session.

Iterating with the agent

Now change the headline to "Built by an agent", redeploy, and tell me when it's live.

The agent edits the file, runs npm run build, and deploys again. Only the files that changed are uploaded, and the URL stays the same. It can keep serving the previous release for most of a minute after the deploy finishes (52 seconds when measured), so have the agent check the page before it reports back. Choosing an upload path has the detail.

Look at the latest deployment logs and tell me if anything's wrong.

The agent calls get_logs, reads the response, and sums it up. This helps when a deploy isn't behaving, since the agent can grep the logs faster than you can.

Verifying the agent's work

For agent-driven work, this is the request you'll use most:

Use inspect on my-agent-site and tell me everything about it.

The agent calls get_app, the MCP wrapper around vibehost app inspect. One response covers runtime, visibility, password gate, all channels, recent deployments, custom domains, all grants, and active share links.

It's the most complete readout an agent can get, so have it run one before any decision that matters.

Patterns that work well

Pull the latest deploy of my-marketing into ./tmp/, apply this color change to all .css files, deploy as my-marketing-variant.

The agent runs:

  1. vibehost pull my-marketing → downloads to ./tmp/.
  2. Edits the CSS files with your text editor tools.
  3. create_app(name: my-marketing-variant).
  4. Uploads ./tmp/ and deploys it, as described in Choosing an upload path.
  5. Returns the new URL.

The agent remixes a live deploy without you touching a file.

Set up a GitHub Actions workflow that deploys this to VibeHost on push to main. Use a PAT scoped to apps:deploy on this app only.

The agent:

  1. Asks you to create a PAT in the dashboard. It can't create one itself, because PAT management works only in a browser session by design. See Personal access tokens.
  2. Writes .github/workflows/deploy.yml following the CI recipe.
  3. Tells you to add the PAT as a VIBEHOST_TOKEN secret.
  4. Optionally pushes a test commit, if you give it git write access.

List all my apps, their visibility, and who has access. Flag anything that looks weird (public + password set, private with no grants, etc.).

The agent calls list_apps, then get_app for each app, and pulls the results together.

Run it as a quarterly cleanup pass. It catches access mistakes before they turn into security issues.

Deploy this to my-app, which is public. Run a smoke check against the URL, and roll back if it fails.

The agent:

  1. Calls deploy(...), which returns an id, a status and the url.
  2. While status is starting, polls get_deployment(deploymentId: <that id>).
  3. If it ends failed → reports error from get_deployment and stops. If it ends superseded, a newer deploy replaced this one; it says so and stops.
  4. If healthy and the app is public with no password → curl the returned URL until it serves the new content; if the page is broken, rollback(appId) and explain what failed.

The smoke check only means something for an app anyone can open. A private or password-protected app does not answer an anonymous curl with the site, so the agent must not read that as a failed deploy, and must not roll back because of it. There, healthy is the result.

This works like a pre-deploy hook run by the agent. Use it when you trust the agent to decide on the deploy but want a check on the result.

When the agent is wrong

Agents miscategorize, miss confirmation prompts, or hallucinate tool args. Three safety nets catch this:

  1. openWorldHint: true tools require confirmation in well-behaved coding agents (Claude Code, Cursor, Codex, Antigravity, Antigravity CLI, Windsurf, OpenCode, Copilot CLI, Hermes Agent). For destructive operations (delete_app, remove_custom_domain), the prompt is harder to skip.
  2. The audit log is your receipt. Every MCP tool call writes to vibehost audit with actor=<your-user> and agent metadata. Review it monthly.
  3. vibehost app inspect shows what is actually there. Don't take the agent's word for it. Check with a direct inspect.

If you want no confirmation prompts at all, for a fully autonomous agent, call the REST API (https://api.vibehost.com/api/v1) directly with a PAT. Write the orchestration code yourself rather than trusting an LLM's tool routing.

Where this falls short

  • Long-running agents drift. A 4-hour agent session deploying to production again and again is risky. Prefer batches: the agent prepares the change, you review the diff, and the agent ships it.
  • Agents don't watch cost. They don't check your billing dashboard, and they'll happily deploy 50 apps in an afternoon. Watch your quotas.
  • Branching is manual. Agents are bad at "create a feature channel, iterate there, promote when good." If you want to let a change soak before promoting it, write a script and have the agent run it.

See also

On this page