Deploy, version & share HTML from any AI tool

AI agents — Claude Code, Cursor, v0, ChatGPT — increasingly emit standalone HTML: reports, dashboards, prototypes, explainers. Wovo is where all of it lives. The mental model is four steps:

Wovo deliberately isn't “another deploy button.” The value is the accumulating, organized, multiplayer library — the part the deploy buttons skip.

Three ways to ship your first page. Pick whichever fits how you work.

A · Let your agent set itself up (recommended)

Paste this prompt into Claude Code, Cursor, or any agent. It asks you two quick questions — this project or every project, publish automatically or on request — then connects through your browser (no token to copy). From then on, the HTML your agent builds lands in your library on its own.

Set up Wovo (wovo.dev) so the HTML you build for me gets a home in my private library.

1. Run: npx @gowovo/wovo setup
   (it opens my browser once so I can approve the connection — you never handle a token)
2. When it finishes, tell me what you configured and give me the link to the private test page it published.

The defaults are fine — it publishes finished pages to my library automatically. If I'd rather set Wovo up for every project on this machine, re-run with --scope user; to publish only when I ask, add --behavior ask.

Prefer the terminal? The same thing is just npx @gowovo/wovo setup — it detects your tool, installs the publishing skill, registers the MCP server, and ships a private test page.

B · From the browser (no setup)

Sign up, create a workspace, then click Upload in your library and drop in an HTML file (or paste markup). It's live instantly.

C · From your terminal

export WOVO_URL=https://wovo.dev
export WOVO_TOKEN=your-deploy-token       # from workspace Settings
export WOVO_WORKSPACE=your-workspace

npx @gowovo/wovo deploy ./report.html

Agents can also use the MCP server directly (below) — tell them “deploy this to Wovo” and they hand back a live link.

The wovo CLI deploys from any terminal — no install required via npx.

Connect your AI tool

One command signs you in through the browser (no token to copy) and sets your agent up to publish what it builds to your library — automatically, as part of the work:

npx @gowovo/wovo setup

Deploy manually

# one file
npx @gowovo/wovo deploy ./report.html

# every .html under a folder — grouped into spaces by subfolder
npx @gowovo/wovo deploy ./site --tool claude-code

# list everything in the workspace
npx @gowovo/wovo list

Configuration

Settings resolve in this order: CLI flags → ./wovo.json → environment variables. Drop a wovo.json in your project so you don't repeat yourself:

{
  "url": "https://wovo.dev",
  "token": "your-deploy-token",
  "workspace": "your-workspace",
  "tool": "claude-code"
}

Flags

In folder mode the CLI walks every .html file (skipping dotfiles and node_modules), derives each slug from the relative path, and uses the top-level folder name as the space.

The Wovo MCP server lets your agent deploy from inside the tool you already live in. Register it once with Claude Code (or any MCP client):

claude mcp add wovo \
  --env WOVO_URL=https://wovo.dev \
  --env WOVO_TOKEN=your-deploy-token \
  --env WOVO_WORKSPACE=your-workspace \
  -- npx -y -p @gowovo/wovo wovo-mcp

Tools exposed

Signed-in workspace members can deploy without touching a terminal. Open your library at /w/<workspace>, click Upload, and either choose an HTML file, pick a folder, or paste raw markup. The page appears in your library immediately and is versioned on every re-upload.

Both the CLI and MCP server are thin clients over two endpoints. Hit them directly with curl or from your own scripts.

POST /api/deploy

Authenticated with Authorization: Bearer <token>. JSON body — html is the only required field:

curl -X POST https://wovo.dev/api/deploy \
  -H "Authorization: Bearer $WOVO_TOKEN" \
  -H "content-type: application/json" \
  -d '{
    "workspace": "your-workspace",
    "slug": "q3-report",
    "title": "Q3 Report",
    "space": "reports",
    "sourceTool": "claude-code",
    "html": "<!doctype html>…"
  }'

Returns { ok, workspace, slug, version, url, rawUrl }. A per-workspace token is bound to its own workspace (the body's workspace is ignored for those).

GET /api/pages?workspace=<slug>

Returns { ok, workspace, count, pages } — the page list used by wovo list. Reads are public for public/unlisted workspaces.

A workspace is your team's library, living at a shareable URL: /w/<workspace>. Inside it, pages are organized two ways:

• ▸Spaces — a folder-like grouping (e.g. reports, eng, design). Set with --space or the top folder name on a directory deploy.
• ▸Source tool — every page is tagged with the tool that made it (claude-code, cursor, cli…) so you can filter by origin.

The library is searchable and filterable. Workspace visibility (private / unlisted / public) controls who can see the library listing itself — set it in Settings.

Every time you deploy to an existing slug, Wovo snapshots a new version rather than overwriting. The latest version is served; older ones are kept. Pages with more than one version show a v2, v3… badge in the library and viewer.

Each page carries its own access level, set in the page panel under Access:

Access is enforced on both the viewer (/p/…) and the raw content route (/raw/…), so a protected page can't be reached by guessing the raw URL.

Every page has two surfaces:

• ▸/p/<ws>/<slug> — the viewer, with Wovo chrome (title, version, copy-link) wrapping your page.
• ▸/raw/<ws>/<slug> — the pure HTML, exactly as authored. This is what an iframe embed points at.

Shared links unfurl with an auto-generated Open Graph card. Public pages also carry a small “Published with Wovo” badge that links back to Wovo. Paid plans remove it.

Link your own domain to a public page so visitors open your HTML at report.yourcompany.com instead of a wovo.dev/p/… URL. TLS is automatic; Wovo serves the page at the domain root with no Wovo chrome.

Link a domain

• ▸In Settings → Custom domains, enter your domain and pick the public page it should serve.
• ▸Or use the CLI: wovo domains add example.com --page my-slug.
• ▸Only public pages can be linked — private, team, and password pages are rejected.

DNS setup

Add these records at your DNS provider (replace with your domain):

• ▸Apex (example.com): A @ → 76.76.21.21
• ▸Subdomain (report.example.com): CNAME report → cname.vercel-dns.com

Ownership verification

If the domain is already registered elsewhere on Vercel, you may need a one-time TXT record. Wovo surfaces the exact challenge from Vercel in Settings when that happens — copy it verbatim into your DNS panel.

CLI

wovo domains list
wovo domains add report.acme.com --page quarterly-report
wovo domains status report.acme.com
wovo domains remove report.acme.com

All commands use your deploy token (WOVO_TOKEN) and hit the authenticated /api/domains endpoint — domain listings are never public.

Limits (beta)

During the free beta, each workspace can link one custom domain. Unlink the current domain to switch to another. Tier-based limits will apply when billing launches.

Each workspace has its own deploy token, shown in Settings. Use it as WOVO_TOKEN for the CLI and MCP server. You can rotate it at any time — the old token stops working immediately, so any leaked token is one click from dead.

The free Hobby tier covers public & link-only pages, one workspace, and 25 pages with 30-day history. Personal ($6/mo) unlocks private pages, 500 active pages, and permanent history; Team ($19/mo for up to 10 members, then $2/mo each) adds 1,000 active pages, shared workspaces, roles, and analytics.

See full pricing →