Cloudflare Pages gives marketing teams a four-stage deploy pattern: an agent or a person commits a file, that commit opens a pull request, Cloudflare builds a preview URL for the branch, and merging to main publishes it live. The review gate sits at the pull request, which is the whole point.
That is the pattern. The interesting part is not the hosting. Everything published on GoodVibeMarketer, including this post, moves through those four stages.
Most write-ups of this treat Cloudflare Pages as a faster, cheaper place to put a website. It is that. Free tier, global CDN, builds in under a minute. If that were the whole argument you could stop reading, because a slightly faster marketing site is not worth a migration.
The argument is about who is allowed to publish.
On a hosted CMS, publishing is a button. Somebody with a login clicks it and the change is live. There is no state between “not published” and “published”, which is fine when the only things touching your site are humans who understand consequences, and becomes a problem the moment you point an AI agent at it. An agent with CMS credentials is an agent with a publish button.
That risk is not specific to publishing. The wider version of it, teams deploying agents faster than they build anything to govern them, is the subject of the governance gap.
The deploy pattern below adds exactly one thing a CMS does not have: a place where a change is finished, reviewable and still not live. Everything else follows from that.
The four stages, in the order a change moves through them:
- Stage one: a commit, not a save. The change lands as a file in a Git repository, with an author, a diff and a one-command revert.
- Stage two: the pull request is the review gate. The change sits finished and inspectable, and stays off production until a person merges it.
- Stage three: the preview URL is what you review. Cloudflare builds every branch, so you read the rendered page rather than a markdown diff.
- Stage four: merge to main is the publish button. Publishing becomes a side effect of approval, and rollback is the same move in reverse.
Stage One: A Commit, Not a Save
In a CMS, an edit overwrites a database row. In this pattern, an edit is a commit to a file in a Git repository, and the difference matters more than it sounds.
A commit is atomic. It has an author, a timestamp, a message, and a diff showing exactly what changed against what was there before. It can be reverted in one command. Ten commits can be reverted in one command. Nothing is overwritten, because the previous version is still in the history.
For an agent, this is the difference between working and being unsupervisable. When my content agent writes an article, it writes a markdown file to a path, draws an image, updates a tracker, and commits. If it gets the topic wrong, or lifts a claim it should not have, the fix is to close the branch. There is nothing to undo, because nothing happened to the live site.
This is also the point where a marketing site stops being a product you rent and becomes a repository you own. I went through that migration in detail in how I rebuilt this site with Claude Code, and the honest summary is that the ownership was not the payoff. The payoff was that agents could suddenly reach the site at all, because the site was now files rather than a locked admin panel.
One commit, one unit of work, one thing to review or throw away.
Stage Two: The Pull Request Is the Review Gate
This is the load-bearing stage. The other three are plumbing.
A pull request is a proposed change sitting on its own branch, complete and inspectable, that has not touched production. Someone has to merge it before it goes anywhere. That is a structural gate, not a policy anyone has to remember, and it is the only reliable way I know of to run generative publishing at any volume without the quality falling over.
Note what it changes about the economics of saying no. In a CMS workflow, rejecting AI output means either catching it before it goes live or cleaning up after it. Both cost real attention, so in practice teams stop looking. Here, rejection is closing a tab. The branch is deleted, the article never existed, and the cost of a bad run is roughly zero. When rejection is free, you reject more, and the average quality of what ships goes up without anyone becoming more disciplined.
Editorial judgment is the quality gate, but judgment applied inconsistently is not a gate at all. Putting it at the merge point means it gets applied on every run, including the ones nobody is watching.
Set it up so every agent run opens a draft pull request rather than a normal one. Draft is the correct default: it says out loud that the thing is unfinished until a human has looked. On this site, the content agent runs on a schedule, writes one article, and pushes it to its own branch, which becomes a draft pull request. It has no path to main. There is no configuration option it could set, no permission it could be granted by accident, that would let it publish. The gate is in the topology, and that is far stronger than the gate being in the prompt.
If you want the full shape of the scheduled job that does this, the AI content workflow write-up covers the repo, the agent brief and the cost cap.
Stage Three: The Preview URL Is What You Actually Review
Cloudflare Pages builds every branch, not just main, and gives each one its own URL. Open the pull request and there is a link to the fully rendered site with that change in it.
This is what makes the gate usable by marketers rather than only by engineers. Nobody on a marketing team should have to review a change by reading a diff of markdown. They should read the page. Is the headline right, does the hero image render, do the links go where they claim to, does the call to action point at something that still exists. Those are editorial questions and they are answered by looking at the page, not the source.
The preview also runs your build, which means your build can run checks. This site fails the build if a post has no hero image, if the share card is under 1200 pixels wide, or if the meta description falls outside 120 to 160 characters. Those rules used to live in an instructions file, which is another way of saying they were followed until they were not. Share cards on a dozen routes had quietly drifted to a default card with retired positioning on it and nobody noticed for months, because nothing errored.
Rules that only exist in prose get skipped. The same rule written as a build check gets enforced on every branch, before a human sees it. That frees the reviewer to do the one thing a check cannot do, which is judge whether the argument is any good.
A failed build on a branch is a normal Tuesday. A failed build on production is an incident. This stage is where you move all your failures into the first category.
Stage Four: Merge to Main Is the Publish Button
Main is the only branch wired to the production domain. Merge the pull request, Cloudflare builds it, the static output lands on the CDN, and the change is live in about a minute.
The useful property here is that publishing is not a separate step. It is a side effect of approval. There is no state where a change has been reviewed, approved and then forgotten before someone remembered to press deploy, which is a genuinely common failure in CMS teams with a staging environment.
Rollback works the same way in reverse. Revert the commit, which is one command or one button, and the previous version rebuilds and redeploys. You are not restoring a backup or hunting through revision history in an admin panel. You are moving the pointer back one step.
Where This Actually Breaks
Three honest failure modes, because the pattern is not magic.
The first is the rubber stamp. If the agent produces one article a day and the reviewer has three minutes, the merge button gets pressed on volume rather than judgment, and you have rebuilt the CMS with extra steps. The pattern gives you a place to say no. It does not give you the will to say no. The fix is to cap the volume at whatever a person can genuinely read, which is almost always less than what the agent can generate.
The second is reviewing the wrong artefact. Teams new to this review the diff, spot nothing obviously wrong in the markdown, and merge. Then the page renders with a broken image or a heading level that skips two. Review the preview URL. Always. The diff is for the person who wrote the check, not the person approving the article.
The third is trusting the brief to do a check’s job. Instructions to an agent are probabilistic and build checks are not, so anything you can express mechanically belongs in the build rather than in prose. That boundary is the practical version of the point I made about the brief becoming the control surface: the brief sets direction and judgment, the checks enforce the non-negotiables, and confusing the two is how quality quietly slips.
All three are habits rather than settings. No amount of configuration fixes a reviewer who has stopped reading, and that is the part teams tend to work out together on their own output rather than from a document. It is most of what an AI marketing workshop spends its time on.
Questions people ask
Can an AI agent publish to a website safely?
Not if it holds a publish button. It can publish safely when every change it makes has to pass through a state where the work is finished but not yet live. In this pattern that state is a draft pull request: the agent commits to its own branch, a person reads the preview and merges. The agent has no route to production.
How is this different from a CMS with a staging environment?
A staging environment is a second copy of the site that someone has to remember to check and someone has to remember to promote. Here the preview is built automatically for every branch, and merging is itself the publish step. Approval and release are the same action, so nothing sits reviewed but unshipped, which is the usual staging failure.
Do I need a developer to set this up?
For the initial wiring, someone comfortable in a repository helps. Connecting Cloudflare Pages to a GitHub repo and turning on branch previews is a short job, but it is a technical one. Running it afterwards is not. The daily work is opening a preview URL, reading the page and pressing merge, which is an editorial job rather than an engineering one.
Does this work on Netlify or Vercel?
Yes. Branch previews and Git-triggered builds are standard on all three, so the pattern transfers without changes. The host is the least important decision here. What matters is that every automated change opens a draft pull request, and that a person reviews the rendered preview rather than the diff before anything reaches main.
Start With the Gate, Not the Host
If you take one thing from this, it should not be “move to Cloudflare Pages”. It should be that agentic publishing needs a state between finished and live, and that a pull request is the cheapest one available.
You can build this on other hosts. Netlify and Vercel both do branch previews. Cloudflare Pages is what I use because the free tier is generous and the builds are quick, but the host is the least interesting decision in the stack. The gate is the decision.
The order to do it in: get the site into a repository as files, wire branch previews, make every automated change open a draft pull request, then move your editorial rules into build checks one at a time as you catch things in review. Each step is useful on its own, which means you can stop at any point and still be better off than you were.
This deploy pattern is the spine of the Editor’s Stack, the architecture that runs everything on this site. If you want to see how the pieces fit together, from the briefs the agents read to the checks that gate the build, the Blueprint lays out the whole system and is free to read. Start there if you would rather build it yourself than hire anyone.