CMS for SvelteKit sites, nothing to integrate.
No integration, no SDK, no schema. Your client edits the SvelteKit site by chat, and every publish is a plain commit your host rebuilds from.
No credit card, cancel anytime.
Built for SvelteKit
Your client edits the page, not a form. Risky changes wait for you.
CMS Brew maps the text and images in your Svelte components and Markdown, and the client edits them on the page or in chat. Per-field guards decide what publishes on its own and what waits for you.
- No integration, SDK, or script tag, so Svelte support is never the missing feature
- Markdown, frontmatter, and dynamic routes like blog/[slug]
- New pages, layout, and code go to you, in the client's words
Side by side
CMS Brew vs Traditional headless CMS
| CMS Brew | Traditional headless CMS | |
|---|---|---|
| Integration work | Connect the GitHub or GitLab repository. That is the setup. | Install an SDK, define a schema, rewrite pages to fetch from an API. |
| Svelte support | Not a feature, a non-issue: CMS Brew edits the repo, not the runtime. | Often secondary: SDKs and visual editors are React-first. |
| Where content lives | In your repository, in the files SvelteKit already builds from. | In the vendor's database, behind their API. |
| What the client learns | Nothing. They type what they want changed. | The studio UI and your content model. |
| Review before publish | Per-field guards and a review queue, included. | Roles and approval workflows, usually on higher tiers. |
| Cost model | $39/mo for 5 sites, unlimited editors. | Per-seat pricing that grows with every editor you invite. |
The honest trade-off
If a site needs thousands of structured entries, localization pipelines, or content shared across several apps, a traditional headless CMS earns its schema, even with thinner Svelte tooling. For the delivered client site with a handful of pages, moving content out of the repo is cost without payoff.
How it works
Three steps, then it's live.
- 01Connect
Point it at the site you built
CMS Brew turns every page, blog post and language into a simple list of things your client can edit. No rebuild, no plugin.
- 02Edit
Clients edit in plain words
Your client says what to change in chat, or clicks the words on the page and retypes them. They see it live before it ships.
- 03Publish
Safe changes go live
Safe edits publish in one click. Bigger requests, like a new page or code, come straight to you.
FAQ
What people ask before switching.
Stop being the person who updates the phone number.
Give your client the keys to the content. Keep the keys to the code.
Prefer to talk first? Book a 30-minute call