cloudhal.com is built with Cloudhal
Why our own marketing site runs on the platform it describes, and what that teaches us.
This site is a Cloudhal project. It was created with cloudhal init, uses its own theme (cloudhal-marketing), and every word you read here is Cloudhal content: pages made of sections, posts in a collection, menus pointing at ids.
We do this for two reasons. First, it keeps us honest: every rough edge a new user would hit, we hit first, and we write it down. Second, the safety story is easier to show than to explain. Changes to this site go through the same snapshots, previews and approvals as yours.
Where does a change go?
The repository holds the theme and the configuration; the words live in Cloudhal. Pick a change to see the path it takes:
- An editor in Studio, or an agent over MCP, changes the draft
- Every change is a snapshot
- Preview on the real site, with automatic checks
- A person approves; publishing points the live site at the snapshot
- No build and no deploy: the change is live in seconds and can be rolled back
- An editor in Studio, or an agent over MCP, changes the draft
- Every change is a snapshot
- Preview on the real site, with automatic checks
- A person approves; publishing points the live site at the snapshot
- No build and no deploy: the change is live in seconds and can be rolled back
- An editor in Studio, or an agent over MCP, changes the draft
- Every change is a snapshot
- Preview on the real site, with automatic checks
- A person approves; publishing points the live site at the snapshot
- No build and no deploy: the change is live in seconds and can be rolled back
- The theme declares the settings (src/settings.ts); the values live with the site
- An editor or an agent picks a seed colour, a font pairing, corners and motion
- Contrast is checked for light and dark before it is saved
- Preview, approve and publish like any other content change
- A pull request to the cloudhal-dev/cloudhal.com repository
- Merging to main starts Workers Builds, which runs cloudhal deploy
- A post-deploy check asks the site and Studio; if either stops answering, both Workers roll back
- Content is untouched: it lives in the store, not in git
- Dependabot opens one pull request for every @cloudhal/* package
- A workflow bundles both Workers without deploying (cloudhal deploy --dry-run)
- Patch releases merge by themselves; minor releases wait for a person
- The merge deploys through Workers Builds, with the same post-deploy check
What lives where
| What | Where it lives | How it changes |
|---|---|---|
| Pages, posts and menus | The site's store (D1) | Studio or MCP, approved |
| Images and files | The media library (R2) | Studio or MCP |
| Design settings | The site's store; the theme declares them | Studio › Appearance or MCP |
| Block types and layouts | Git: src/blocks.ts, src/components | Pull request |
| Worker, D1 and R2 names | Git: wrangler.jsonc, cloudhal.json | Pull request |
| Cloudhal version | Git: package.json | Dependabot pull request |
The site deploys only from stable releases, so it never runs ahead of what you can install.
Two days of changes
Show the data
| who | Snapshots |
|---|---|
| Setup | 4 |
| Agent (MCP) | 16 |
| Publish | 1 |
October 20–21, 2026, counted with list_snapshots before this post was rewritten. The agent's snapshots are the launch post and its images.
The launch post, Cloudhal is open source, and this rewrite were made by an agent through this site's MCP server, with the key's owner approving the publish. The repository is public: cloudhal-dev/cloudhal.com.