Client editing for Bolt

Let clients edit your Bolt site.

Bolt built and deployed the whole thing from a prompt. The client’s first request after launch is a new photo and a price change, and the honest answer is “I need to prompt it again and re-deploy, give me a day.”

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.

Getting the site out of Bolt

  1. In Bolt, connect the project to GitHub, or download the project as a zip and push it to a repo. Bolt’s output is a normal Vite or Next project.
  2. Deploy that repo on Netlify (Bolt’s default), Vercel or Cloudflare Pages. Any of them gives you a deploy hook URL.
  3. Open the repo in an agent that speaks MCP: Claude Code, Cursor, Codex or Windsurf.

Connecting it, step by step

  1. Add the Tusk MCP to the agent.
  2. Log in once: npx @tuskcms/mcp login --site <slug>. The token it gets is issued for this one site.
  3. Say “Connect this site to Tusk CMS.” It marks the editable elements, adds the build step, sets up the deploy hook (it can create one with the Netlify CLI; on Vercel you create it and paste the link), publishes, and confirms the site picked it up.
  4. Invite the client. Next time the price changes they change it.

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 Bolt, 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 Bolt, 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 Bolt developers ask

Will Bolt overwrite the Tusk changes next time I prompt it?

If you keep working in Bolt on the same files, a regeneration can drop attributes; re-run the connect prompt afterwards and it re-marks in seconds. The published content survives because it lives in Tusk, not in the file. Once the client owns their content most studios only return to Bolt for real feature work.

Bolt hosts on Netlify for me. Does that still work?

Yes. Netlify has build hooks; the agent can create one with the Netlify CLI and save it in Tusk, or you paste one. A client Publish triggers the Netlify build, which pulls the content and serves your own files.

Vite, not Next. Is that a problem?

No. The build step is two zero-dependency scripts around your build command: one pulls the content before it, one writes it into the built pages after. Vite, Astro, Eleventy or a static folder all work the same way.

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