# Tusk CMS

> Tusk CMS gives the owner of a website a login where they can change the words, photos and downloads on it, without touching the code. Developers mark editable elements with `data-tusk` attributes and add one build step that writes published content into the site on deploy. The site stays on its own hosting; nothing of Tusk runs between a visitor and the site.

## Connect a site (start here)

- [Full connect guide](https://tuskcms.com/llms-full.txt): the complete, authoritative instruction for an agent connecting a site to Tusk. Three parts — PART ZERO, the preferred path as Tusk MCP tool calls (install the MCP, one login the human approves, register → mark → wire build → wire host → scan → publish → prove live → invite); PART ONE, the same runbook by hand through the browser (fallback); then the reference both lean on: the full `data-tusk` attribute grammar, field kinds, publishing modes, how to render pulled content, the public feed contract, the endpoint table, and the secrets rules.
- [Same guide as an API response](https://tuskcms.com/api/connect): identical bytes, `text/plain`, public and unauthenticated.
- [Connect page](https://tuskcms.com/connect): the page a developer opens. Primary path: add the Tusk MCP, log in once, ask the agent to connect the site, invite the client. Fallback without an MCP: paste one line that points at the guide above (hands-on runbook; budget 30-40 min, the agent stops for a few clicks only the human can make).
- [Marked-up example page](https://tuskcms.com/examples/marked-site.html): a working page with every attribute on it.
- Tusk MCP server (`@tuskcms/mcp`, on npm): for an agent with tools, this is the most hands-off path. Add it to your AI tool's MCP config as `npx -y @tuskcms/mcp`, then `npx @tuskcms/mcp login --site <slug> --scopes scan,fields,content,publish,deploy,invite` and approve once in the browser. Over the paired, scoped token it can register the site, scan pages, rotate the build token, record the deploy hook, publish and invite the client — the steps a browser session would otherwise gate. It exposes `get_instruction`, `create_site`, `scan_site`, `rotate_build_token`, `set_deploy` (record the deploy hook you wired in the site's own host), `publish`, `deploy_status` and `invite_client`, each mapping to a real endpoint below. `--site` binds the token to one site (least privilege).

## Build scripts (shipped, zero-dependency Node 18+)

- [tusk-pull.mjs](https://tuskcms.com/sdk/tusk-pull.mjs): fetches the published snapshot, downloads photos to `public/tusk/`, writes `.tusk/published.json`. Run it before the build.
- [tusk-apply.mjs](https://tuskcms.com/sdk/tusk-apply.mjs): writes published values into built HTML files, for plain-HTML sites. Run it after the build (`node tusk-pull.mjs && node tusk-apply.mjs dist`). Together these two are the site's content-sync step; there is no separate `tusk-sync.mjs`.
- [tusk-deploy-worker.js](https://tuskcms.com/sdk/tusk-deploy-worker.js): a copy-paste Cloudflare Worker that verifies Tusk's signed publish webhook and triggers a deploy, for hosts with no deploy hook. Four variables and no code changes: `DEPLOY_HOOK_URL`, and for GitHub's API (GitHub Pages, Firebase, Azure Static Web Apps, FTP or buckets deployed from Actions) `DEPLOY_HOOK_AUTH` and `DEPLOY_HOOK_BODY`.

## For people

- [Developer docs](https://tuskcms.com/docs): the same material written for a human reader.
- [What clients can and cannot do](https://tuskcms.com/clients)
- [Terms](https://tuskcms.com/terms), [Privacy](https://tuskcms.com/privacy)

## Notes

- Two values come from the site owner and from nowhere else: the site slug (`TUSK_SITE`) and the build token (`TUSK_TOKEN`, found in Tusk under Manage > Going live > Advanced > Build token). The build token is a secret — it belongs in `.env` and in the host's environment variables, never in a committed file.
- Tusk never hosts the site and never holds its hosting credentials. You wire the site's own host once (a deploy hook, or a build that pulls the feed) and record it in Tusk (`set_deploy`, or the dashboard); after that an owner's publish rebuilds the site through that hook. Nothing of Tusk sits between a visitor and the site.
- For a multi-page static site, the recommended path is Git + deploy hook, so publishing rebuilds the whole site. Adapter mode (Tusk deploys the files itself) suits a small, fully-captured site; it does not carry pages or assets Tusk has not captured. See the full guide, "How a publish reaches the live site".
- Nothing on this site, this file included, contains a credential.