Investigating Zenn, note, GitHub Pages, and Your Own Site

Choosing a personal technical-blog platform only by reader reach creates migration problems later.

The first question in my comparison was where the canonical source should live.

Then I checked URL continuity, review and publishing automation, and acceptable operational work.

This makes hosted services such as Zenn or note and an Astro site different distribution choices rather than mutually exclusive platforms.

The source and the destination can be separated.

Split the decision into five criteria

1. Canonical source

Keeping articles as Markdown in Git allows the content to be reused after changing the publishing destination.

Dependence on a service-specific editor or syntax creates migration work for images, embeds, tables of contents, and links.

For long-lived technical notes, keep source files and original images outside the publishing service.

2. URL continuity

A service URL shortens the path to publishing, but it is affected by service behavior and account status.

A custom domain requires setup, but makes it easier to keep the same public URL after changing hosts.

A custom domain alone does not create search traffic.

URL structure, internal links, content, and continued publishing still matter.

3. Discoverability and ownership

Hosted services can provide internal audiences and service-specific discovery paths.

An independent site gives control over structure, design, URLs, and measurement, but does not automatically provide the same discovery paths.

The two goals can coexist.

Keep Git as the canonical source and republish selected articles to Zenn, for example.

Make the canonical version clear to both readers and yourself.

4. Automation

A technical blog may eventually need to:

Review articles through pull requests
Run Markdown linting and link checks
Create previews for each push
Separate drafts from published articles
Build RSS and sitemaps

A Git-centered setup makes these tasks easier to add to CI.

A hosted editor is quicker to start, but repository-level checks and publishing steps depend on the service.

5. Operations

With an independent site, you maintain dependencies, build failures, domains, and backups.

Static hosting reduces always-on server work, but does not remove updates or configuration checks.

A hosted service reduces infrastructure work, but pricing, features, and terms can change.

Check what official documentation supports

Zenn’s official manual documents Markdown syntax and GitHub repository integration.

That supports a workflow in which Git manages sources and a hosted service distributes them.

GitHub integration does not mean that you own the service’s URLs, presentation, analytics, or export behavior.

GitHub’s official documentation describes Pages as publishing static web assets from a repository.

Astro has an official GitHub Pages deployment guide, making it a natural fit for Markdown-to-static-site workflows.

Cloudflare’s official guide documents building an Astro site from a Git repository.

This supports starting with static output and adding provider-specific capabilities only when needed.

Compare the options on the same axes

Option	Best suited to	Confirmed strength	Migration or operations concern
Zenn or note	Publishing quickly and testing response	Short path from writing to publishing	Verify URLs, presentation, and export behavior
GitHub Pages	Git-centered static publishing	Traceable relationship between source and build	Check `base` and URLs for project sites
Astro + Cloudflare Pages	Growing an independent site	Git integration, previews, and custom domains	Maintain provider settings and dependencies
VPS or your own server	Controlling the runtime	Freedom over server and data processing	Security, upgrades, monitoring, and backups

These strengths are not permanent guarantees.

Confirm prices, free tiers, publication rules, and export features when adopting an option.

Starting with Zenn or note

If the first goal is to finish and publish an article, a hosted service is reasonable.

It lets you test writing pace and reader response before investing in a build system or design.

Do not keep these assets only inside the service:

Markdown sources
Original image files
Slugs and publication dates
External links and embeds

When adding republication targets, define the canonical source.

Linking back to the canonical article makes it easier to explain where the current version lives.

Choosing GitHub Pages

GitHub Pages publishes static web assets from a GitHub repository.

Deploying Astro’s static build through GitHub Actions preserves history and enables review.

A project site includes the repository name in its public URL.

Align Astro’s site and base with that URL, then verify internal links, RSS, and sitemap URLs under the same assumption.

A custom domain removes the repository name from the public URL.

Add an external service or another runtime only when the feature is actually needed.

Choosing Astro with Cloudflare Pages

Cloudflare Pages can build from a Git repository and configure deployments or previews per push.

Astro’s documentation covers both static deployment and a Cloudflare adapter for runtime features.

That makes it possible to begin with Markdown and static output, then evaluate forms or search later.

Embedding Cloudflare-specific APIs such as R2, KV, or D1 increases the cost of moving to another host.

A clear expansion order is static build, CI and previews, custom domain, then dynamic features.

My choice and remaining uncertainty

For long-lived technical notes, I would manage Markdown, images, and metadata in Git and generate the site with Astro.

GitHub Pages and Cloudflare Pages can both be initial hosts.

The important constraint is not locking the canonical article inside a hosting dashboard.

I would still republish selected articles to Zenn when reader reach is the immediate goal.

Prices, features, terms, and export behavior can change.

This comparison should therefore be read as an order of questions to verify during adoption, not as a permanent ranking of services.