If your blog uses GitHub and Cloudflare, you can inspect how an article will look before releasing it. One way is to use a GitHub working branch and a Cloudflare Workers Preview deployment.
But a private GitHub repository does not automatically make its Preview website private.
How should writing, review, and production deployment be separated?
Reviewing writing and reviewing design are different jobs
I check two things when reviewing a blog post.
The first is the wording and substance. Is the narrative natural, are the facts right, and are any expressions unnecessary? A Markdown draft is sufficient for this review. I do not need a deployed page.
The second is the layout and visual design. I need to check type sizes, image placement, spacing, and responsive layouts. That is easier in an environment that displays the actual website.
Those two reviews do not need to be tied to the same deployment step.
My first idea: use a private GitHub branch
Initially I considered pushing drafts to a branch in a private GitHub repository and reviewing the Markdown directly on GitHub.
However, when Cloudflare Workers Preview Builds are enabled, pushing a non-production branch can automatically start a Preview deployment.
To avoid deploying during editorial review but allow deployment for design review, I would need branch-specific build exclusions or another branch-management convention.
That is technically workable. But maintaining deployment exceptions simply to review a draft felt like unnecessary overhead.
I also investigated restricting Preview access
Cloudflare Workers Preview is convenient for looking at a site without changing production. But its Preview address may be publicly reachable unless access restrictions have been configured.
I looked into Cloudflare Zero Trust Access, which can restrict entry to specified accounts. During setup, I encountered a screen requesting a payment method. I did not want to register a credit card just to expand the review setup for my personal blog, so I postponed using Access.
That does not mean Access necessarily requires a paid plan. It means I chose not to adopt it given my project's size and my setup preferences.
Without access controls, a Preview must not be treated as a confidential storage area. Avoid including credentials or content not intended for potential public access.
My final choice: finish the draft in chat first
Instead of adding more infrastructure, I separated the stages:
- Draft: Write the Markdown article with ChatGPT.
- Editorial review: Refine the flow and wording in the same conversation and approve the final text.
- Prepare the Preview: Commit and push the approved article to a GitHub working branch.
- Visual review: Inspect the live preview and its mobile layout on Cloudflare.
- Publish: Merge into
mainafter corrections and verification. - Clean up: Confirm production deployment, then delete the unused Preview.
This method avoids pushing a draft to GitHub just to read it, and it does not require special deployment exclusions during editorial review.
Because the Preview is only created after the text is reasonably settled, it can also reduce unnecessary builds.
Important implementation details
Preview and Production use different addresses. Root-relative internal links such as /ko/knowledge/ can keep navigation on the current hostname in both environments. SEO canonical links and sitemaps, on the other hand, should point to the official production domain.
Also, if the blog generator excludes posts with draft: true, that post may not appear on Preview either. Before including a work-in-progress post in a Preview build, remember that the resulting page might become publicly reachable.
Finally, do not assume a Preview disappears automatically after merging into main. Distinguish branch Previews from deployment-specific URLs and clean them up through the supported deletion mechanism.
The order matters more than the number of tools
GitHub Private repositories, Cloudflare Workers Preview, and Cloudflare Access all serve useful purposes. But that does not mean every small blog needs all three from the start.
Review the writing before deployment, use Preview for design inspection, and publish only the approved result.
Following this sequence provides an organized editorial workflow without unnecessary configuration.