Blog Access Limits

Cloudflare Workers is indeed excellent, but it tracks your access counts and imposes a daily usage cap.

If you are running a simple static blog—one without features such as user logins, comments, or dynamic API interactions—I highly recommend prioritizing deployment via Cloudflare Pages instead.

As long as you aren’t abusing resources, access to static websites hosted on Pages is essentially unlimited.

This means I don’t have to worry about DDoS attacks, concurrency issues arising from increased traffic, or the need to upgrade to a paid service plan simply because my site hits a daily threshold of one thousand or ten thousand visits.

As long as my domain name remains active, I can continue updating my blog—or simply hosting my blog and website—indefinitely.

Feature	Cloudflare Pages (SSG)	Cloudflare Workers (SSR)	Workers Static Hosting
Daily Traffic Capacity (Free Tier)	Nearly Unlimited (Hundreds of thousands to over a million PVs)	Approx. 10,000 – 30,000 PVs (Subject to a limit of 100,000 requests/day)	Static assets: Unlimited; Dynamic content: Limited
Bandwidth/Data Transfer	Unlimited	Depends on request count (No separate bandwidth cap)	Same as left
Ideal Use Cases	Purely static blogs (Recommended)	Requires dynamic rendering, comments, personalization, etc.	Hybrid sites (though Pages is generally recommended)
Cost Risk	Zero	Paid fees apply if limits are exceeded (Starting at $0.30 per million requests)	Low
Other Limitations	500 builds/month; 20,000 files	CPU time: 10ms/request	Static assets: 20,000 files

Blog Architecture Migration

I am currently transitioning from SSR (Server-Side Rendering) to SSG (Static Site Generation) and migrating my hosting from Cloudflare Workers to Cloudflare Pages.

According to AI, this transition should have no negative impact, as the content consists of static web pages anyway—provided that the URLs remain unchanged.

Should I wish to switch back from SSG to SSR in the future—returning to Cloudflare Workers to add features like user logins, comments, and so forth—the process will remain relatively straightforward.

Currently, I have commented out the line adapter: cloudflare(), within my astro.config.mjs configuration file. I then added the line output: 'static'; this ensures that the build process generates standard HTML files within the dist directory. In the future, if I need to switch back, I simply need to revert this configuration file to its previous state.