What is CloudCannon, and who is it for?
CloudCannon is a git-based CMS with its own hosting for static site generators. Your content stays as files in a GitHub, GitLab or Bitbucket repository. CloudCannon reads those files, shows editors a visual editing interface on the rendered page, and commits their changes back to the repository. There is no separate content database and no content API to maintain, which is the main difference from Contentful or Strapi.
On its technologies page CloudCannon lists Astro, Eleventy, Hugo, Jekyll, Next.js, Nuxt, SvelteKit, Gatsby and several others. As of October 2026 its pricing page shows Standard, Team and Enterprise plans, plus a Lite plan for agency partners. The plans differ by users, bandwidth, branching workflows and scheduling. Check the current numbers on the vendor page, since they change.
When does CloudCannon beat a classic headless CMS?
It fits marketing and documentation sites where the site is the product and the content is mostly pages, not records. Editors click on the page and change text, images and components in place. Developers keep a normal git workflow with branches, pull requests and deploy previews. That removes the sync step between “content in the CMS” and “code in the repo”, a common source of preview bugs on API-based setups.
It is the wrong choice when content must feed several channels, such as an app, a kiosk and a website, or when thousands of structured records change daily. A file in git is a poor place for a product catalogue. In those cases we recommend Sanity or Contentful, and for a free self-hosted option Strapi. The wider field of repository-based tools is compared in our list of git-based headless CMS platforms.
What do we build with CloudCannon?
Site configuration and editing model
Most of the work happens in the CloudCannon configuration kept in the repo. We define collections, input types and structures so that editors see friendly fields instead of raw front matter. We also register your page components as editable blocks, so a marketer can add a testimonial row without touching code.
Frontend with Astro or Eleventy
Astro is our default pairing for new builds because it ships little JavaScript and handles content collections well. For an example of an Astro Jamstack build with measured speed gains, see the case study on an Astro marketing site for a Series-B SaaS. That project did not use CloudCannon, so read it as a frontend reference. Our Astro developers can set up the same stack under CloudCannon editing.
Workflow, previews and review
We configure branch-based previews so changes get a URL before they go live, plus scheduling and roles for larger editor groups. We handle form submissions, redirects and search with build-time tools or small services next to the static output.
Migration into CloudCannon
Moving from WordPress or another database CMS means exporting content to Markdown or data files, rebuilding templates, and mapping old URLs to new ones. We script the export so it can run again until launch day. The steps are covered in our WordPress to headless CMS migration guide. CloudCannon also sells its own migration service, which is worth pricing against ours.
What does it cost to own?
The vendor subscription is the visible part. The drivers behind the rest are the number of editors, monthly bandwidth, how many sites you run, and how much component work the config needs. We scope the build after a short audit of your templates and content.
If you want engineers who already know the stack, see how to hire CloudCannon developers. Platform choice itself is easier with the headless CMS overview open next to this page.
Is CloudCannon right for your team?
Ask three things. Do editors mostly change pages, not records? Is one website the only consumer of the content? Does your team already work in git? Three yes answers point to CloudCannon. A no on the second question usually points to an API-first platform instead.
