Why I Chose Cloudflare After Comparing a Bunch of Blog Options

A practical comparison of Naver Blog, Tistory, Medium, WordPress, and a Cloudflare-based blog stack, with the final decision focused on long-term cost and control.

Contents

This post is about the thought process behind rebuilding my personal development blog.

I used Tistory and Naver Blog for quite a while. I wrote about algorithm practice, iOS development, small setup notes, game logs, and whatever else I happened to be working on at the time. Looking back, a surprising amount of it is still useful.

Sometimes the notes around the actual topic are more interesting than the topic itself. I can see the old version of me writing comments with full confidence that future me would read them someday. Future me did, in fact, read them. (Thanks, past me.)

But after using those platforms for a long time, the limitations also became clear.

The posts are still there, but they are not easy to manage in the structure I want now. Keeping the original text as Markdown is awkward, and running Korean and English versions side by side takes extra work. Connecting posts with app operations, automation notes, and deployment records is also not very natural.

When I revisit old posts, I usually get two thoughts at once: "Oh, I actually did this" and "Why did I do it like that?" That is a familiar feeling if you write code long enough. Old code and old posts can be reference material and a mystery novel at the same time.

So if I was going to organize the blog again, I wanted a structure that would be easier for future me to maintain.

This time I started with a different set of criteria.

I did not want just another place where I could publish posts. I wanted something closer to a personal technical archive for app development notes, Cloudflare operations, automation work, and cost decisions.

The criteria looked like this:

• Keep the monthly fixed cost as low as possible. This matters. (The budget is not exactly infinite.)
• Run it under the existing koujiapps.com domain.
• Keep the original posts as Markdown.
• Publish Korean and English versions together.
• Add comments, view counts, and admin features only where they are actually useful.
• Keep security-sensitive areas separate from the public blog.

With those rules in mind, there were quite a few options to consider.

Blog Tools I Considered

I did not start with "I am definitely going to build this on Cloudflare." I first looked at the available choices.

It felt a bit like shopping for blog tools: put one in the cart, check the price, remove it, look at the features, put it back in, think about operations, remove it again. Shopping is fun. Checkout pages are less fun.

Naver Blog

Naver Blog is strong for Korean search exposure and general accessibility. I already had posts there, and it is familiar to Korean readers.

But for a development blog, it is not ideal if I want structured source files, a natural connection to my own site, and a reliable publishing workflow. It is fine for personal notes, but it felt a little too constrained for the main technical blog I want to build now.

Tistory

Tistory feels more suitable for technical posts than Naver Blog, and it has been a decent home for developer writing for a long time. Since some of my old posts are already there, it is still worth keeping around.

But if I want long-term automation, Korean and English publishing, and direct control over image storage, I still need a separate operating model.

Medium

Medium is good at making long-form writing readable. The reading experience is comfortable and familiar.

But it does not fit the goal of running the blog under my own domain while controlling comments, view counts, images, and publishing flow in my own way. It is a good publishing platform, but not quite the technical archive I want.

It is a nice place to read. It is not necessarily the place where I want to move in with all of my tools and stay for years.

Developer Blog Platforms Like Velog

Developer-focused platforms are great for writing and sharing posts quickly. Markdown support lowers the writing friction, and the audience is already developer-oriented.

The direction is different, though. Publishing into a community platform and owning a blog system inside my own site are not the same thing.

GitHub Pages or Static Blog Generators

Jekyll, Hugo, and Astro were also possible options. They work well with Markdown, and the cost can stay very low.

The issue is that comments, view counts, admin writing, and image uploads eventually need either a backend or a group of external services. For a simple technical blog, that can be enough. For what I wanted, it felt slightly too static.

Ghost

Ghost is clean and focused on writing, newsletters, and memberships. It also feels lighter than WordPress in many ways.

For my use case, the monthly cost and operation model were the main concerns. If I were building a publication or newsletter business, Ghost would be a stronger candidate. For a personal development archive that should stay cheap for a long time, it was not my first choice.

After going through those options, the final comparison came down to two paths.

Should I attach WordPress?

Or should I build only the pieces I need on Cloudflare?

The Final Comparison: WordPress vs Cloudflare

WordPress is the realistic, fully formed CMS option.

Writing, comments, admin screens, themes, plugins, and SEO features are already there. Not having to build everything from scratch is a big advantage.

The Cloudflare approach is different. It is not a complete blog product. I have to assemble the pieces myself: public pages, image storage, comments, view counts, and admin screens.

But my main criteria were not only writing convenience. I cared more about long-term cost and source ownership.

From that perspective, WordPress and Cloudflare have very different tradeoffs.

Where WordPress Makes Sense

WordPress is a good choice if the goal is to start quickly.

It has an admin UI, themes, comments, plugins, and a large ecosystem. If I want to write directly in a browser, edit comfortably, and add search, SEO, or analytics through plugins, WordPress is clearly convenient.

Purely as a writing experience, WordPress is ahead of a custom build. It is a proven CMS for a reason. When you look at the admin interface, it is easy to understand why so many people use it.

The part I kept coming back to was cost and operations.

With WordPress.com, features depend on the plan, and plugin access opens up only at certain tiers. With self-hosted WordPress, I would still need to think about hosting cost, backups, security updates, caching, and spam protection.

That does not mean WordPress is bad. For blog operations alone, it is probably the easier route.

But in my case, Cloudflare was already part of the site and app infrastructure. If I could put the blog on top of the same foundation, I could reduce another fixed monthly cost. Yes, this is a recurring theme. The wallet is persistent.

Building Directly on Cloudflare

The Cloudflare approach is not the same as installing a finished CMS.

Instead, I can combine only the parts I need.

• Serve public blog pages mostly as static content.
• Store changing data such as comments and view counts in D1.
• Store images in R2.
• Protect the admin screen separately.
• Keep post sources as Markdown.

At that point, it starts to feel less like a blog and more like a small operations system. It is more work, but it also makes the data flow and cost points much easier to see.

For normal readers, most page loads can stay static. That matters for cost. Static pages are fast, require very little server-side work, and do not become expensive just because traffic grows a little.

Only state-changing actions need APIs: posting a comment, increasing a view count, or using the admin area.

For my personal development blog, that structure made more sense.

Looking at the Cost

The most important part of the Cloudflare option was the free tier.

Cloudflare Workers Free has a daily request limit, D1 has daily read/write free quotas, and R2 includes monthly storage and request allowances. R2 also has no egress fee, which makes it attractive for blog images.

For this blog, the rough assumption is:

• 100 visitors per day (wishful thinking)
• 5 post views per visitor (also wishful thinking)
• 1 new post per day
• Images compressed to WebP where possible
• Around 500KB total image size per post on average

At that level, the early monthly cost should be close to 0. The important word in that sentence is "0". It is a calming word.

The key risk is images.

Markdown text is tiny. Even if I wrote every day for 50 years, the text itself would not be the problem. Images are different. If every post starts carrying several megabytes of original PNG or JPG files, storage grows quickly.

So I set an image budget first.

With that budget, even one post per day for 50 years can still stay inside a practical storage range. Of course, some posts will need more images, so the average matters more than being strict on every single article.

Also, writing every day for 50 years is already a slightly dramatic assumption. But setting a long-term budget makes each image decision easier today.

Security Details Should Not Be Over-Explained Publicly

Once an admin feature exists, security has to be considered.

For a public post, I think it is better to explain the direction without exposing detailed implementation.

The basic direction is simple:

• Separate the public blog from the admin area.
• Require authentication before opening the admin screen.
• Add spam protection to comment posting.
• Apply size limits to uploads and API requests.
• Keep switches for features that could increase cost.
• Set low budget alerts early.

That is enough to explain the operating principle without turning the post into a public checklist of internal details.

The important goal is not to claim "perfect security." It is to make sure that if something goes wrong, I can reduce the blast radius quickly.

Conclusion

WordPress is the easier choice if I want to start quickly and write comfortably.

Building on Cloudflare takes more design and implementation work at the beginning. In return, it gives me tighter control over the domain, source files, data structure, publishing flow, and long-term cost.

I am treating this blog as a long-running place for app development and operations notes, not as a short-term side page. That is why I chose the Cloudflare structure: low fixed cost, Markdown source files, and only the dynamic features I actually need.

To summarize:

• If writing convenience is the top priority, WordPress is easier.
• If long-term fixed cost matters more, a Cloudflare-based structure can be better.
• The Cloudflare path requires active decisions around images, API usage, and admin security.
• For a personal development blog, static posts plus a few dynamic features is a realistic starting point.

That is the direction I am starting with.

Instead of trying to build a perfect CMS on day one, I want the base structure to survive years of posts without making the monthly cost creep up. I can make it fancier later.