Client editing for Astro

Let clients edit your Astro site.

Astro sites are fast because they are just files. Bolting a CMS onto one usually means content collections, a fetch at build, a schema, and explaining “Markdown” to a client who wants to change a phone number.

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.

Where your Astro site needs to be

1. No export. Tusk marks the elements in your .astro templates; the build pulls the published content before astro build and writes it into the built pages after.
2. Deploy on Cloudflare Pages, Netlify, Vercel or your own server with a hook.

Connecting it, step by step

1. Add the Tusk MCP to your agent, or mark by hand with data-tusk attributes.
2. Log in once for this site: npx @tuskcms/mcp login --site <slug>.
3. Say “Connect this site to Tusk CMS.” It marks, adds the two scripts around astro build, sets up the deploy hook with you, publishes and verifies.
4. Invite the client.

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 Tusk starter is a GitHub template: a three-page business site in plain HTML, already marked up, with the build step and Vercel and Netlify config in place. Use the template, deploy it, say “Connect this site to Tusk CMS.”, and hand it to the client. Then reshape it into their site, or copy the marks and the build step into your Astro project.

Starting from a prompt instead? Ask your tool to build the site with the marks in from the start: the first-prompt version works in any builder.

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

Content collections: do they still work?

Yes. Your collections, schema and typed frontmatter stay exactly as they are, and what they hold is the text the page falls back to. The client’s published words are written into the built pages after astro build. The client never sees Markdown.

Islands / React components inside Astro?

Marks go on whatever renders the element: an .astro template, a React island, a JSON file. The client clicks the element on the live page either way.

Is the site still fully static?

Yes. Nothing is fetched at runtime. Published content and photos are files in your repo’s build, served by your host.

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