CloudCannon’s Astro offering answers a question that comes up on every Astro site built for someone else: the developer is happy editing Markdown in a repository, and the client is not. CloudCannon puts a visual editing layer on top without moving the content out of Git.
The premise it builds on is stated plainly on the page: “Astro stores everything as flat files in Git” — Markdown, frontmatter, components, config. CloudCannon edits those files and commits.
Two editing models, and the choice matters
This is the part worth understanding before evaluating anything else, because the two routes imply different work.
The page-builder route. Editors assemble pages from component blocks stored in frontmatter, with live previews in the Visual Editor. Content is structured data; the developer defines which blocks exist.
The source route. Edits save directly back into the .astro file, driven by data-editable attributes that the developer places on the elements editors should be able to change. The FAQ states the guarantee that makes this tolerable: “Anything you don’t mark stays untouchable.”
That sentence is the crux. Opening a .astro file to a non-technical editor sounds alarming until the editable surface is an explicit allowlist. You decide what is reachable; everything else is not.
What the developer has to do
The documented setup is smaller than you might expect, and the page says it can be incremental:
- A
cloudcannon.config.ymldescribing collections and inputs. - Editable region attributes on the components editors should change.
- Optionally, Zod schemas mapped to CloudCannon schemas — which means an existing Astro content collection schema can carry over rather than being redefined.
- Optionally, Snippets for MDX components, and a pinned Node version.
The page describes “Most of the setup” as the config file plus the editable region attributes.
How it stays out of your way
Editors work on branches and preview on staging sites before committing; the page says “Editors commit through CloudCannon’s interface,” while developers keep working locally, which it characterises as giving “zero conflicts.”
Treat that last phrase as the vendor’s framing rather than a property of distributed version control — branches reduce collisions, they do not abolish them. But the underlying model is sound and genuinely different from a headless CMS with its own database: editor changes arrive as ordinary commits, so your history, review tooling and rollback story are unchanged. If CloudCannon disappeared tomorrow, the content would still be in the repository in the same format.
The limitations to check against your build
These are stated on the page and they are the ones that decide suitability:
- Visual Editing requires a static build. Server-driven sections need static fallbacks for the editor to render them.
- CloudCannon hosting serves static output. If part of your site is server-rendered, that part stays on your existing platform.
- Without Visual Editing it still works as a headless CMS, with no build required — a lighter mode if the visual layer is not the point.
So the fit is cleanest for a content site that prerenders. For an Astro project leaning on SSR — the node adapter, on-demand routes, API endpoints — expect to split hosting or provide fallbacks, and budget time for that rather than discovering it late.
The page states no prices. It links to a pricing page and offers a trial, so the commercial terms are something to establish before you build the integration rather than after.
Worth a look if
You maintain an Astro site that someone else writes for, you want to keep content in Git, and your pages are mostly prerendered. The data-editable allowlist model is the detail that makes it worth evaluating over a conventional headless CMS: it gives editors a WYSIWYG surface without surrendering the template.
Start with the config file and a single collection rather than wiring the whole site — the incremental path is explicitly supported, and it is the cheapest way to find out whether the editing model suits your client before committing to it.
