# CMS Brew — full product details > Let clients edit the site. Not break it. CMS Brew lets a non-technical client edit their delivered website in plain language. The model writes a schema-validated content patch, never code, so safe edits publish in a click and anything risky is handed back to the developer. CMS Brew is for development agencies and freelance developers who hand off finished websites to non-technical clients. Instead of the client emailing every text change — or the developer rebuilding on WordPress just to get an editor — the client types what they want in a chat, and CMS Brew applies it as a schema-validated content patch to the site the developer already shipped. ## How it works ### 01 Connect — 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. ### 02 Edit — 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. ### 03 Publish — Safe changes go live Safe edits publish in one click. Bigger requests, like a new page or code, come straight to you. ## Guardrails the agency controls Every field CMS Brew maps gets a guard level the agency can change per field category in settings, taking effect on the client's next edit: - Open: Clients edit it freely. - Warn: Editable, with a heads-up before publishing. - Review: Hidden from clients and sent to you as a request. - Locked: Hidden and blocked entirely. A per-field choice. Defaults out of the box (every category adjustable except structural, which can be tightened but never opened): - Body content (paragraphs, labels, buttons): Open - Links (tel:, mailto:, menu links): Open - Images (photo swaps and alt text): Open - Page title (, og:title): Warn - Meta description (search-result snippet): Warn - Headings (the on-page <h1>): Warn - Structural and code ({expressions}, markup spans): Review at minimum Whatever levels the agency picks, a client cannot break the build: - The model never writes code. Every edit is a plain-text value for a field that already exists. - Structural and code fields can be tightened, never opened. They stay at Review or stricter. - Out-of-scope requests are not errors. They land in your inbox with the client's words attached. ## Publishing model Each publish is one Git commit to the site's repository, containing only the validated content values. The existing deploy pipeline picks it up and rebuilds, exactly as if the developer had pushed the commit — no separate content database, no runtime script injected into the site. Because every publish is a single commit, one click reverts it. ## Works with existing stacks No plugins, no proprietary SDKs, no rewriting the site. CMS Brew maps the existing codebase and commits directly to the repository. - Frameworks: Astro, Next.js, Vue, SvelteKit, Nuxt, Remix, Gatsby, Hugo - Hosting/previews: Netlify, Vercel, Cloudflare, GitHub Pages, GitLab Pages (edits are previewed through the host's own deploy previews) - Git hosts: GitHub, GitLab (each connects, publishes, and reverts the same way) ## Pricing One plan with everything included. Pay per website, never per seat. Everyday content edits are included under fair use, and the client who owns the site can be invited at no extra cost. It starts with a 7-day free trial ([sign up](https://cmsbrew.com/sign-up)). Launch offer: Launch offer: The first 20 customers get 50% off for 12 months with code BREW50 at checkout. ### Pro — $39/mo (the only plan) For freelance developers and agencies alike, from the first handoff to a full portfolio. - Websites included: 5 included (extra sites +$10 each/mo) - Annual billing: $312/year (8 months — 33% off) - Features: Unlimited chat edits; Inline text edits; Multi-page, blog and multilingual sites; One-click revert and version history; SEO-sensitive field warnings; Teammates and a shared team inbox; Email and Slack escalations; Guards policy for field permissions; Staged drafts and audit trail; MCP and CLI access; Personal founder support ## FAQ ### Can a client break the code? No. The editor never writes code. It can only change the specific content fields you allow, and anything risky is flagged for review before it goes live. ### Is the preview the real site or a simulation? It is your real site. The editor loads your actual deployed page in a frame, your CSS, your fonts, your images, and paints the pending change on top of it, so the client sees the edit on the real thing before anything is published. It works even when the deployment sits behind a password. ### What happens to the mapping when I refactor the site? It gets rebuilt. There is no schema file to keep in sync: the editable fields are re-read from your repository on every push, so renaming a component simply produces a new map. If a refactor moves text a client is halfway through editing, the edit follows it. If you delete that text, the edit is refused rather than landing in the wrong place. ### How does publishing actually work? One commit per publish, not one per edit: everything the client has pending goes together to the branch your site deploys from, as a single labelled commit that names what changed. Your pipeline rebuilds it exactly as if you had pushed it yourself, and if a build ever fails, your host keeps serving the last good one, so the live site does not change until it succeeds. There is no separate content database and nothing extra added to your site, so one click reverts any publish. ### Which hosts do you support? Vercel, Netlify, and Cloudflare, with live previews built right into the editor. And because every publish is just a normal commit to your repository, publishing works with any host that rebuilds your site from Git. ### Does it work on a site in more than one language? Yes. Each language of a page is listed on its own, so your client picks the German one and edits German. Translated text stays in its own language. Shared details like a phone number update everywhere at once. ### Can my client edit blog posts? Yes. Your client opens the post they want and edits it like any other page. If the text belongs to the blog layout rather than that one post, the editor says so. And you decide whether they can write new posts too. ### What happens when a client asks for a bigger change? Requests for new pages, layout changes, integrations, or code are refused in the editor and routed back to the agency with the client's original message attached. ### What does my client need to install or learn? Nothing. You send them an invite, they sign in with Google or a six-digit code emailed to them, and they type what they want changed the same way they would text it to you. There is no app to install, no password to keep, no dashboard to learn, and no git concepts like branches or pull requests to explain. ### Do you charge per client seat? No. You pay per website you connect, never per login. Invite the client who owns the site at no extra cost. ### What if my client never makes an edit? That is normal for handed-off sites, and the bill does not change: you pay per connected website, not per edit. You are paying for the handoff itself, an editor ready the moment the client needs it instead of a change-request email landing on you. If a site is truly done, disconnect it and it stops counting. ### What happens when the trial ends? Nothing breaks. The live site stays exactly as published, and nothing you or the client saved is lost. Editing is paused until you upgrade, though already-saved changes can still be published in the meantime. ## Links - [Home](https://cmsbrew.com/) - [Features](https://cmsbrew.com/features) - [Pricing](https://cmsbrew.com/pricing) - [About](https://cmsbrew.com/about) - [Contact](https://cmsbrew.com/contact) - [Sign up — 7-day free trial](https://cmsbrew.com/sign-up) - [Terms of Service](https://cmsbrew.com/terms) - [Privacy Policy](https://cmsbrew.com/privacy)