At first, I only wanted a more convenient way to review a blog post.
I was drafting posts with AI and receiving HTML files to inspect. Change a sentence, receive a new file. Replace an illustration, open another file. A page that looked fine on a PC might look awkward on a phone.
Each revision meant generating another file and comparing it with the previous one. As the work continued, I began losing track of which file was the final version.
Sometimes exchanging files became more troublesome than writing the article itself.
One post became an entire series
The inconvenience became much clearer while documenting my smart-home experiences.
What began as one article grew into several as I described the door lock, smart buttons, failed plugs, lighting automation, and other experiments.
Every article needed explanatory illustrations and a mobile layout. Sometimes diagrams generated with AI displayed differently in a real browser than we had expected.
It was no longer a matter of making a single article. I needed a way to manage several drafts and their designs at the same time.
Could a GitHub branch become an editorial review space?
I had already been using GitHub for development, but I mostly thought of branches as places for code changes and feature testing.
Then I wondered: if blog drafts were Markdown files, why not manage them in a branch as well?
My first idea was to push drafts to a separate branch in a private GitHub repository, read and review the Markdown there, check the layout using Cloudflare Preview, and merge into main only after final approval.
That sounded quite promising at first.
But there was a catch.
If Cloudflare automatically deployed a preview for every branch, simply pushing a draft to GitHub could create a publicly reachable preview build.
I wanted to read and edit the draft first—not deploy a website every time I saved an article.
I also considered excluding editorial branches from automatic preview deployments. Even if possible, that would mean maintaining branch naming conventions and deployment exceptions.
I did not want to create a new management burden just to avoid the old one.
What about private previews?
Another possibility was to make the Cloudflare Preview itself private.
Cloudflare Zero Trust Access can restrict a site to approved accounts. While exploring the setup, however, I reached a step asking me to register a payment card.
The product had free usage options, but I did not want to register a payment method just to review blog drafts.
My actual requirement was simple: read the draft comfortably, check how it looks, and publish it when ready.
Zero Trust is not inherently a poor solution. It may be an appropriate choice for projects that genuinely require restricted access. For my blog, though, the setup felt larger than the problem I wanted to solve.
I stopped investigating private preview access at that point.
Returning to the original problem led to a simpler answer
I went back to my original aim: stop sending HTML files back and forth, while making it easy to review the writing and its final appearance.
Did the draft really need to go to GitHub before I had finished editing it?
I was already writing and reviewing it in a conversation with AI.
I could review the text in the conversation, make corrections, and only push the finished draft to a working branch. Then I could inspect the visual design on Cloudflare Preview and merge to main once it looked right.
The resulting workflow was straightforward:
Draft with AI → Review the text in chat → Approve the writing → Push a GitHub branch → Review the design on Cloudflare Preview → Merge to main → Clean up the preview.
A separate private Markdown-review branch and special rules to exclude that branch from deployment were no longer mandatory.
There was an important limit: without an access policy, a Preview URL may be publicly reachable. I decided that only content suitable for potential public exposure should go into a preview.
I learned that the last preview deployment can remain
Using Preview raised another question.
What happens to the preview after the working branch is merged into main?
I had assumed that once the changes reached production, the preview address would naturally disappear. But a preview is a separate deployment artifact; the final previewed version can remain available.
The production blog may continue to change while an unused preview still serves an older screen and code.
So I decided to use GitHub Actions to delete the relevant preview after the merge and production deployment process.
Unexpectedly, the hardest part was not writing the cleanup logic but managing authentication and permissions. While creating a Cloudflare API token and adding it to GitHub Secrets, I initially confused an account identifier with an email address, causing the automation to fail.
I eventually put together a preview-cleanup workflow. At that point, its actual deletion behavior still needed separate verification.
The token setup, GitHub Secrets configuration, automation, and troubleshooting were recorded in a separate Knowledge article.
More tools do not always mean a better process
I started with the inconvenience of sending HTML files back and forth.
One question led me through GitHub branches, automatic deployment, Cloudflare Preview, Zero Trust, and GitHub Actions.
Learning about these features was interesting. But I also realized that using every available feature is not necessarily the best way to work.
I am not looking for the most technically complex publishing system. I want a simple process that I can keep using.
I may add more automation as the need arises. For now, separating editorial review from visual review solves much of the original inconvenience.
A small annoyance with HTML files ended up changing how I thought about managing the entire blog.