"We want to rebuild our corporate website with Astro, but we need a CMS where the client can edit articles." "We want to keep monthly headless CMS costs down." Inquiries for client corporate websites of this nature have been growing since April. A compelling new choice is CloudCannon, welcomed by Astro as its official CMS partner. It adopts an architecture that edits Markdown files directly in Git, pairing perfectly with Astro Content Collections. It is particularly effective for corporate sites with 100–500 articles and 2–5 editors.
This article outlines design guidelines for corporate site client renewals adopting Astro × CloudCannon, along with migration steps from WordPress and alternative headless CMSs.
Why Astro × CloudCannon is ideal for corporate website client work today
Astro is the fastest-growing SSG (Static Site Generation) framework in 2026 and already an industry standard for corporate client projects. However, when editors are non-engineers, requiring them to edit Markdown directly is not always practical.
Previously, pairing Astro with headless CMSs like microCMS or Contentful was the dominant approach, but operating expenses and learning curves remained persistent hurdles. CloudCannon offers several distinct characteristics:
| Dimension | Traditional headless CMS | CloudCannon |
|---|---|---|
| Data storage | CMS vendor database | Markdown in Git repository |
| Editing UI | Rich editor + API fetching | Rich editor + direct Git commits |
| Version control | Proprietary to CMS | Git commit history |
| Sync with local development | Fetched via API on demand | The repository itself |
| Vendor lock-in | High | Low (all data remains in Git) |
In short, the core corporate website resides in your development repository, and CloudCannon simply provides the editing UI. Even if the client decides to switch CMSs in the future, all Markdown files remain entirely in their possession.
Overall architectural picture
Our standard architecture for client projects is structured as follows:
- Content layer (Git repository) — Markdown / MDX managed via Astro Content Collections
- Editing layer (CloudCannon) — Direct Git commits via rich editor
- Build layer (Cloud Build / GitHub Actions) —
astro build→ static asset generation - Delivery layer (GCS / Cloudflare / Vercel) — Global distribution via CDN
CloudCannon synchronizes with GitHub or GitLab repositories, and when editors save changes in the rich editor, it creates Git commits under the hood. This keeps engineers on their familiar pull request workflow while freeing content editors from having to understand Markdown syntax.
5 design guidelines to master in client development
1. Design Astro Content Collections schemas with non-technical editors in mind
Fields defined in Astro's src/content/config.ts using Zod schemas map directly to CloudCannon form controls. In the early project stages, establish the following three elements:
import { z, defineCollection } from "astro:content";
const newsCollection = defineCollection({
type: "content",
schema: z.object({
title: z.string().max(60),
date: z.date(),
category: z.enum(["プレスリリース", "お知らせ", "イベント"]),
featuredImage: z.string().optional(),
draft: z.boolean().default(true),
}),
});
It is especially critical to restrict input options using enum. Free-text inputs lead to formatting discrepancies across editors, breaking downstream filters.
2. Spin up preview environments per editing branch
While CloudCannon edits generate Git commits, it is best practice not to merge directly into main. For client engagements, we recommend the following flow:
- Editor saves in CloudCannon → automated commit to a
content/draft-YYYYMMDDbranch - Preview URLs generated per branch via Vercel or Cloudflare Pages preview features
- Engineers merge into main after staging review
3. Delegate image optimization to Astro
Images uploaded via CloudCannon are placed in public/images/ within the repository. The standard practice is to use Astro's astro:assets component to convert them uniformly to webp / avif during build time.
---
import { Image } from "astro:assets";
import heroImage from "../../public/images/news/2026-04-launch.jpg";
---
<Image src={heroImage} alt="サービスローンチ" widths={[400, 800, 1200]} />
4. Structure multilingual sites with locale folders + Astro i18n
CloudCannon follows a one-file-per-page model. For multilingual corporate sites, organize files by locale by separating src/content/news/ja/ and src/content/news/en/. Routing is configured on the Astro side with astro:i18n.
5. Phased, parallel migration from WordPress is safest
When migrating client sites from WordPress, take a phased approach rather than an immediate cutover:
- Keep WordPress as a headless CMS via GraphQL, fetching and rendering content with Astro
- Concurrently shift new content creation to CloudCannon
- Convert and migrate legacy posts to Markdown at a rate of 100 articles per month
- Decommission WordPress once all content is migrated
The strategy of phased migration using existing GraphQL endpoints outlined in our Headless WordPress migration guide works just as effectively with Astro × CloudCannon.
Choosing between CloudCannon and other CMSs
When asked whether CloudCannon eliminates the need for microCMS, Contentful, or Sanity, we structure our recommendations as follows:
| Use case | Recommended CMS |
|---|---|
| 100–500 articles, 2–5 editors, corporate site | CloudCannon |
| 1,000+ articles, 10+ editors, media business | microCMS / Contentful |
| Multi-product, API-first architecture | Contentful / Sanity |
| Editors are exclusively engineers | Direct GitHub editing (no CMS needed) |
CloudCannon's sweet spot is corporate-scale editing volumes. For media businesses planning large-scale growth, alternative CMS platforms remain recommended.
Key checkpoints in custom development contracts
Because CloudCannon is a SaaS platform, agree on the following terms with the client in development contracts:
- CloudCannon billing owner: Whether the agency sets up the account and transfers production billing to the client
- Editor role design: Separating publish privileges from draft privileges
- Backup responsibilities: Markdown remains in Git, but establish a long-term retention policy for media files
- Avoiding CMS vendor lock-in: Clearly document offboarding procedures in the contract if switching CMSs later
Combining these terms with the maintenance contract framework in Managing corporate website client renewals substantially reduces post-handover friction.
Conclusion
Astro × CloudCannon is a modern stack that balances editor usability with vendor lock-in avoidance in corporate website client renewals. Keep these five principles in mind for client delivery:
- Design Content Collections schemas around non-technical editors
- Create preview environments on a per-branch basis
- Delegate image optimization to Astro
- Handle multilingual setups with locale folders and Astro i18n
- Migrate from WordPress in phased parallel stages
At GleamHub, we specialize in corporate site client renewals utilizing Astro and CloudCannon. If you are currently on WordPress and want to transition to a static architecture while keeping the editing experience smooth, please reach out.









