CloudCannon in 2026: a SaaS git-CMS with unlimited sites, user-based pricing, and a Forestry correction

What CloudCannon actually is, in one paragraph

CloudCannon is a fully-managed SaaS that runs your Jekyll, Hugo, Eleventy, Astro, or SvelteKit build for you, hosts the result on their CDN, and bolts a WYSIWYG editor on top of the Markdown / data files in your git repo. You connect a GitHub, GitLab, Bitbucket, or Azure DevOps repo; their build farm clones it, runs hugo or jekyll build or npx astro build on every push; non-technical editors get a visual editor that commits Markdown / data-file changes back to a branch; the same farm rebuilds and serves. It's the same idea Decap and TinaCMS implement open-source — content lives in git, not a database — but instead of you stitching together a build pipeline, an OAuth provider, and a host, CloudCannon owns all three.

Practically: if you've been building Jekyll sites for clients and the friction was always "the editor wants to fix a typo without learning git", CloudCannon is the path of least resistance. If you're a solo developer who's already comfortable with git push → Cloudflare Pages, you're paying for a managed editing workflow you may not need.

The marketing site, taken at face value

Curl is more useful than the visual: the homepage is served behind Cloudflare with a public cf-ray, cf-cache-status: HIT, and a custom cc-cache-status / cc-perf pair. The access-control-allow-origin: https://app.cloudcannon.com header tells you the SaaS app domain is split off the marketing one, which is the right architecture for a CMS but worth knowing if you're SSO-debugging:

$ curl -sI https://cloudcannon.com/
HTTP/2 200
content-type: text/html; charset=utf-8
cf-ray: 9f869fab585f3a9a-FRA
cf-cache-status: HIT
access-control-allow-origin: https://app.cloudcannon.com
cache-control: s-maxage=2419200, max-age=0, must-revalidate, public
cc-build-id: 21598202
cc-cache-status: HIT
cc-perf: fetch-headers=29;t=31

That cc-build-id: 21598202 is interesting — it's the same kind of build identifier their customers' sites would carry, exposed on their own marketing site. CloudCannon eats its own dog food, which is reassuring.

Pricing: what $10, $55, and $350 actually buy

The four public tiers, scraped straight out of the rendered page. We originally described these as per-site prices; that was wrong. CloudCannon's plans include unlimited sites and scale mainly by users, bandwidth, domains, and team features.

The pricing model is user-based, not per-site. Additional users are listed at $10/month per user, but the site count itself is unlimited across the plans we saw. For a single corporate site with five locales and a content team of three, Standard covers the whole team at $55/mo; a fourth user would make it $65/mo. For a freelancer or agency running multiple small client sites, the better question is bandwidth, custom domains, and whether clients need their own editor seats, not whether each site adds another base-plan fee.

The Decap / TinaCMS comparison is still unflattering on raw cost: a Decap admin on Cloudflare Pages with a Workers OAuth proxy is $0/mo at this traffic level. The honest answer for the price gap is that CloudCannon is selling the same thing AWS sells against EC2-on-bare-metal — they own the operational burden. If your editor is non-technical and the cost of a one-week debugging session for "the GitHub OAuth flow stopped working" exceeds the plan price, CloudCannon's price is justified. If you have a developer on retainer, it depends how much of that managed workflow you actually use.

Documentation: refreshed in 2026, search-first

The split into User / Developer is meaningful: editor-facing docs talk about visual editing, the slug field, and managing assets; developer docs cover the cloudcannon.config.yml manifest, build hooks, and the SDK for embedding their editor mode into a custom UI. Decap and TinaCMS docs are written for one audience (developers), which is fine for their open-source positioning but less workable when the customer is "marketing director who needs a CMS for the dev team they hired".

The Forestry / TinaCMS trail, corrected

Correction after CloudCannon feedback: CloudCannon did not purchase Forestry.io. TinaCMS is Forestry.io's successor; CloudCannon is simply another long-running product in the same git-CMS category. We still tested the public Forestry-related paths because they are relevant comparison traffic for buyers researching static-site CMS options.

$ curl -sI https://cloudcannon.com/forestry-migration/
HTTP/2 404

$ curl -sI https://cloudcannon.com/forestry/
HTTP/2 404

$ curl -sI https://cloudcannon.com/documentation/articles/migrate-from-forestry/
HTTP/2 404

$ curl -sI https://forestry.io/
HTTP/2 301
location: https://tina.io/forestry/

For a buyer evaluating CloudCannon today, this matters only as positioning context. TinaCMS owns the Forestry continuity story; CloudCannon's argument is different: hosted builds, visual editing, editor workflow, support, and operational ownership for static-site teams.

The app domain: a mild surprise

This is fine — most SaaS apps gate the login URL on a redirect from the marketing site — but it's a small example of "the public surface is not the same as the customer surface". Decap and TinaCMS, by contrast, expose the entire admin to anyone who points a browser at their /admin/ folder. Different model, different threat surface; CloudCannon's is harder to fingerprint, which is the right call for a paid SaaS.

What we measured against the public site

Where CloudCannon fits, where it doesn't

CloudCannon is the right answer when: the editor is non-technical and the dev team's time is more expensive than the CloudCannon plan; you want Jekyll or Hugo specifically (Astro support is newer, the polish around Jekyll is fifteen years deep); you're migrating from a WordPress monolith and you want a stepping-stone that keeps editor experience comparable while moving the architecture to static; the dev team has zero appetite for owning a build pipeline.

CloudCannon is the wrong answer when: you're a solo developer with a side-project blog (Decap on Cloudflare Pages is free and works); you have an opinionated build pipeline already (CloudCannon assumes it owns the build, working around that is fighting the product); the editor team is technical and PR-based content review is a feature, not a friction (in which case Decap's editorial workflow gives you the same flow at $0); you need a content database with relations, role-based permissions, and a media library for video — that's not what git-CMSes are for, look at Strapi or Directus.

Three things we'd change about the public site

1. Own the "Forestry alternative" comparison, not the migration story. Since TinaCMS is the Forestry successor, a CloudCannon page for people searching old Forestry terms should be a clear comparison page, not an acquisition-style migration page.
2. Make the unlimited-sites pricing clearer above the fold. "Unlimited sites" is a strong point for agencies and multi-site teams. It deserves to be visible earlier than the fine-grained plan details because it changes the scale math substantially.
3. Lean into Astro on the hero, not just the announcement banner. The announcement bar reads "40+ ready-made Astro components, built for visual editing — clone them, brand them, ship them!" — which is the strongest commercial line on the whole site, but it's stuck in a dismissable strip. Astro is where the new mid-2020s static-site builds are landing; CloudCannon's bet is right, the placement on the page is wrong.

Where this fits

One short, honest write-up per CMS we run, deploy, or scout. Adjacent in the same series: Decap CMS 3.12 in 30 lines, TinaCMS self-host on Docker, Ghost 5 on Docker SQLite, Open WebUI on Linux Docker, Dify 1.14.0 docker-compose. SimpleReview is the Chrome extension that turns whatever element you click on a broken admin — including a CloudCannon visual-editor field that's autosaving the wrong slug — into a draft code-fix PR you can ship without leaving the page.