VibeHost

Full agent workflow

Your coding agent builds, deploys, shares — end to end. The path that needs no humans in the middle.

The scenario: you're working with a coding agent (Claude Code, Codex, Cursor, Antigravity, Windsurf, OpenCode, Copilot CLI, Gemini CLI, Hermes Agent — or a chat client like ChatGPT). You've written some code with the agent's help. You want it shipped — and you want the agent to do the shipping, the sharing, the iteration.

This recipe is the canonical "agent owns the deploy lifecycle" walkthrough.

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 — per-agent setup is short, each guide has the exact config:
  3. First tool call triggers OAuth; click approve in browser.

After this, your agent has the full MCP tool surface 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 (in order):

  1. Inspect the project — reads package.json, identifies build command.
  2. Buildnpm install + npm run build in your shell (you may be prompted to confirm).
  3. create_app(name: my-agent-site, runtime: static) — creates the app.
  4. create_deployment(app: my-agent-site, dir: ./dist) — uploads.
  5. set_visibility(app: my-agent-site, value: public) — opens to the internet.
  6. add_custom_domain(app: my-agent-site, hostname: agent-demo.example.com) — prints DNS record.
  7. Reports back — URL + the CNAME you need to add.

Most of these are write tools; well-behaved coding agents (Claude Code, Cursor, Codex, Antigravity, Windsurf, etc.) confirm with you before each. 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, calls create_deployment again, returns the new URL (same alias, new immutableUrl).

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

Agent calls get_deployment_logs, reads the response, summarizes. Useful when a deploy isn't behaving — the agent can grep the logs for clues faster than you can.

Verifying the agent's work

The single most useful command for agent-driven workflows:

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

Agent calls get_app (the MCP wrapper around vibehost app inspect). One response includes: runtime, visibility, password gate, all channels, recent deployments, custom domains, all grants, active share links.

This is the agent-friendly canonical readout. Use it before any non-trivial decision.

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.

Agent runs:

  1. vibehost pull my-marketing → downloads to ./tmp/.
  2. Edits the CSS files (via your text editor tools).
  3. create_app(name: my-marketing-variant).
  4. create_deployment(app: my-marketing-variant, dir: ./tmp/).
  5. Returns the new URL.

The "remix from a live deploy" pattern, fully agent-driven.

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.

Agent:

  1. Asks you to create a PAT in the dashboard (it can't — PAT management is browser-session-only 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. Optional: 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.).

Agent calls list_apps, then get_app for each, then synthesizes.

Useful as a quarterly cleanup pass. Catches access misconfigurations before they become security issues.

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

Agent:

  1. create_deployment(...).
  2. curl the returned URL.
  3. If non-200 → rollback_deployment(app: my-app) and explain what failed.

This is the agent equivalent of a pre-deploy hook. Useful when you trust the agent to make the deploy decision but not the verification.

When the agent is wrong

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

  1. openWorldHint: true tools require confirmation in well-behaved coding agents (Claude Code, Cursor, Codex, Antigravity, Windsurf, OpenCode, Copilot CLI, Gemini CLI, Hermes Agent). For destructive ops (delete_app, delete_deployment), 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> + agent metadata. Review it monthly.
  3. vibehost app inspect is your truth. Don't trust what the agent says; verify with a direct inspect.

If you want zero confirmation prompts (truly autonomous agent), use a PAT against the REST API directly — but 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 repeatedly to production is risky. Prefer batch-mode: agent prepares the change, you review the diff, agent ships.
  • Cost visibility. Agents don't naturally check your billing dashboard. 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 the promote-after-soak workflow, write a script and have the agent run it.

See also

On this page