Client editing for v0

Let clients edit your v0 site.

v0 gave you the components in minutes and you shipped them on Vercel. The client now wants a different headline, and regenerating the block in v0 means re-checking every prop and every style it touched.

Tusk is a client editing layer for sites you already built. You keep the code, the repo and the hosting. Tusk marks the text, photos and downloads the client may change, and the client changes them on their own live page. Nothing of Tusk runs between a visitor and the site.

Start with v0, free How the connect works

Getting the site out of v0

From the v0 chat, push the project to a GitHub repo (the Deploy / “Add to codebase” options), or download the code. Either way you end up with a Next.js app you own.
The Vercel project is usually already there. If not, import the repo; Tusk works with any host that can rebuild on a hook, and Vercel deploy hooks take one click to create.
Open the repo in Claude Code, Cursor, Codex or Windsurf. The connect happens there.

Connecting it, step by step

Add the Tusk MCP to your AI tool.
Log in once with npx @tuskcms/mcp login --site <slug> and approve the link. The token is issued for this site.
Say “Connect this site to Tusk CMS.” The agent marks the text, images and downloads inside your components, adds the build step that pulls published content, and asks you for a Vercel deploy hook (Project › Settings › Git › Deploy Hooks); then it publishes and verifies.
Invite the client. Their edits reach the live site through your own Vercel deploy, not through Tusk.

The MCP config, for Claude Code, Cursor, Codex or Windsurf. Nothing to install: it runs from npm on demand.

{ "mcpServers": { "tusk": { "command": "npx", "args": ["-y", "@tuskcms/mcp"] } } }

No MCP? Paste this one line into any AI tool that can read a URL and edit files:

Connect this site to Tusk CMS. Read https://tuskcms.com/llms-full.txt first and follow it exactly.

Start from a template

The easiest connect is the one with nothing to mark afterwards. Paste this as the first prompt in v0, fill in the brackets, and the site is born with the marks Tusk needs. Then follow the steps above to connect it.

Build a three-page website (home, work, contact) for [business name], a [what they do] in [city]. Plain, fast, mobile-first. IMPORTANT: this site will be edited by the client through Tusk CMS, so mark every element they may change with a data-tusk attribute named page.field, e.g. <h1 data-tusk="home.heading">, <p data-tusk="home.lead">, <img data-tusk="home.hero">, <a data-tusk="contact.brochure" href="…">. Repeated cards use data-tusk-list="page.field" on the container, data-tusk-item on one card and data-tusk-field="title" on its parts. Site-wide text (phone, footer address) uses globals.field. Rules: https://tuskcms.com/llms-full.txt under “Mark the HTML”. Do not invent a CMS, database or admin page: the marks are all Tusk needs.

Already have code? The Tusk starter repo shows what a marked-up site looks like: three pages, plain HTML, the build step and deploy config already in place. Copy its patterns into yours.

What the client gets

Their own login. They open an editor with a live preview of their real website beside the fields you marked, click a heading, a paragraph, a photo or a download, change it, and press Publish.
Nothing of yours. No repo, no v0, no code, no layout or styles. What you did not mark cannot be edited.
History of the last 30 days, with any version restored as a draft, so a bad edit is never permanent.
A Publish that reaches the live site through your own host, and a dashboard that tells you both whether it did.

What you keep

The codebase, the hosting and the deploy. Tusk triggers a deploy hook you own, and that link, encrypted, is all it holds of your host.
A static site that stays static: published content and images are written into your build by two zero-dependency scripts. The deployed site never calls Tusk.
The retainer. The client pays you; you pay Tusk by site. Clients never pay for their login.
The exit. Export gives you a site’s words, photos, fields and 30 days of versions as files; disconnect cuts every tie and the site keeps serving.

Questions v0 developers ask

I keep generating new blocks in v0. What happens to the marks?

A new block from v0 has no marks until you run the connect prompt again; existing marked blocks keep working. Nothing the client has published is lost, because content lives in Tusk keyed by field, not in the component.

Does Tusk run inside my Next.js app?

No. One small script runs before the build and saves the published content and photos as files in your project; your pages read them while they build. The deployed site never calls Tusk. Your app stays a normal Next.js app.

Server components, app router, RSC?

Fine. The marks are attributes on the rendered HTML, and the content arrives as one file, .tusk/published.json, that a server component can read at build time. For a static export, the second script writes it into the built HTML instead.

Connect your v0 site What your client sees Pricing

Also built with Lovable, Next.js, Cursor? Tusk works the same way. All builders: Lovable, Bolt, Replit, Claude Code, Codex, Cursor, Windsurf, Next.js, Astro, Eleventy, Framer, plain HTML, and any site with a build step or deploy hook.