Vercel, Cloudflare Pages, or GitHub Pages?

Free static hosting platforms look similar from far away. You push to Git, the site builds, a CDN serves the files, and a custom domain points to the result. The differences appear later: when traffic grows, when a build gets heavier, when a team needs preview deployments, or when the site stops being just static files.

This is not a ranking of “the best platform.” It is a decision guide for how long each platform stays the right choice, and when it is time to move. The numbers below were checked against official pricing and limits pages on July 2, 2026.

For a static technical blog, the boring rule usually wins: if the output is static HTML, there is no runtime server, and traffic is still small, GitHub Pages is the right level of complexity. If the site becomes an ad-supported content property with serious static traffic, Cloudflare Pages becomes the next candidate. If the site turns into a product app with authentication, dashboards, server functions, and a Next.js lifecycle, Vercel deserves a fresh look.

The short answer

For a personal technical blog, documentation site, or portfolio, GitHub Pages is enough for a long time. There is no runtime server, the output is static HTML, and the operational model is easy to understand.

For a content site that may grow in traffic, Cloudflare Pages is the platform I would watch next. Static asset requests are free and unlimited when they do not invoke Functions, and the surrounding Cloudflare ecosystem gives you DNS, WAF, Workers, R2, D1, and cache controls in one place.

For a Next.js application, preview-heavy team workflow, serverless functions, ISR, middleware, analytics, and product-app behavior, Vercel is usually the smoother developer experience. The trade-off is that the cost model becomes more detailed as the app uses more platform features.

The numbers that matter

The important detail is that not every number has the same meaning. GitHub Pages’ 100GB/month bandwidth and 10 builds/hour are soft limits. The 1GB published site limit and 10 minute deployment timeout are closer to hard operational constraints. Vercel’s 100GB and 1TB Fast Data Transfer numbers are included usage. Cloudflare Pages’ free/unlimited static asset requests apply when the request does not invoke Functions.

That is why the decision is not only about who has the biggest number. It is about what you want to stop thinking about.

GitHub Pages: best when the site is still just documents

GitHub Pages hosts static HTML, CSS, and JavaScript from a repository. That is a good fit for blogs, documentation, project pages, and portfolios where the build output is the product.

Its strength is operational simplicity. The repository, issues, Actions workflow, and Pages deployment all live inside GitHub. If Astro or another static site generator produces HTML, there is no runtime server to operate.

The boundary is also clear. GitHub Pages is not meant to be a general free hosting platform for an online business, e-commerce site, or SaaS application. GitHub’s own limits page recommends keeping repositories under 1GB, limits published sites to 1GB, times out Pages deployments after 10 minutes, describes a 100GB/month soft bandwidth limit, and mentions a default Pages build soft limit of 10 builds per hour.

How I would use it: start a blog here, keep images reasonable, generate canonical URLs, RSS, and a sitemap at build time, and move only when the limits become visible.

Cloudflare Pages: strongest when static traffic grows

Cloudflare Pages becomes attractive when static content starts getting real traffic. The key advantage is the static request model. Cloudflare’s Pages Functions pricing page says static asset requests are free and unlimited on both free and paid plans when they do not invoke Functions.

The build limits are clear. Free gives 500 builds/month, one concurrent build, and a 20 minute build timeout. Pro gives 5,000 builds/month and five concurrent builds. Business gives 20,000 builds/month and 20 concurrent builds. File count is 20,000 on Free and 100,000 on paid plans, with a 25MiB single asset size limit.

Dynamic behavior moves into Pages Functions, and Pages Functions use the Workers model. Workers Free includes 100,000 requests/day. Workers Paid starts at $5/month and includes 10 million requests/month. Cloudflare also states that Workers Paid does not add data transfer or bandwidth charges.

How I would use it: move a growing static blog here when traffic economics start mattering. Keep static pages static, avoid sending ordinary asset requests through Functions, and use Workers only for the parts that actually need code.

Vercel: better understood as an app platform

Vercel can host static sites, but its real advantage appears when the site behaves like an application. Next.js integration, preview deployments, branch-based collaboration, serverless functions, middleware, image optimization, analytics, and rollback all fit together.

The pricing line starts simply: Hobby is $0/month and Pro is $20/month. Hobby includes 100GB Fast Data Transfer, 1M function invocations/month, 4 CPU-hours, and 360 GB-hours of provisioned memory. Pro includes 1TB Fast Data Transfer, then overage pricing applies. The pricing page also frames Pro around included usage credits and pay-as-you-go resources.

The limits are also more app-shaped. Build time per deployment is 45 minutes. Hobby has 100 deployments/day and 100 deployments/hour. Function duration depends on project settings and Fluid compute, so for a static blog comparison the more important point is this: functions, image optimization, analytics, logs, and data transfer become separate operating concerns.

How I would use it: choose Vercel when the blog and product app genuinely share a lifecycle. If the site is only a Markdown blog, the convenience may not justify the platform surface area.

Cost scenarios make the choice clearer

1. A technical blog with 10,000 monthly page views

GitHub Pages is usually enough. If one page view transfers about 1MB of HTML, CSS, JavaScript, and images, 10,000 page views is roughly 10GB of transfer. That is far below GitHub Pages’ 100GB/month soft bandwidth limit.

The important variable is not visitor count by itself. It is page views multiplied by transferred bytes per page. A media-heavy article that transfers 3MB per view reaches about 90GB at 30,000 page views.

2. An ad-supported content site with 500,000 monthly page views

Now the traffic model matters. At 1MB per page view, 500,000 page views is roughly 500GB of transfer. That is well beyond GitHub Pages’ soft bandwidth limit and beyond Vercel Hobby’s included 100GB Fast Data Transfer.

This is where Cloudflare Pages starts making more sense. The key is to keep ordinary static asset requests static and avoid accidentally routing everything through Functions.

3. Blog plus account features and dashboards

At this point the comparison changes. The question is no longer “where do I host static files?” It becomes “which app platform matches my rendering, data, and deployment model?”

If the product is centered on Next.js, Vercel may be the fastest path. If the product is edge-first and likely to use Workers, D1, R2, or KV, Cloudflare may be the better long-term platform.

4. SaaS product expansion

GitHub Pages is not the platform for this stage. Cloudflare Pages can be part of a static shell plus Workers architecture, but the boundaries need design. Vercel gives a polished app deployment workflow, but the cost dimensions should be tracked intentionally.

Feature comparison

When to stay and when to migrate

Stay on GitHub Pages while:

• the site is a blog, documentation site, or portfolio
• there is no login or server API
• builds finish within 10 minutes
• the published site stays under 1GB
• monthly transfer is comfortably below the soft 100GB limit
• GitHub Actions is enough for build and deploy

Move to Cloudflare Pages when:

• static traffic is growing
• bandwidth economics matter more than platform simplicity
• redirects, headers, and cache behavior need more control
• Cloudflare DNS, WAF, R2, D1, KV, or Workers are likely to join the system
• a few lightweight APIs can live in Pages Functions

Move to Vercel when:

• Next.js is the product framework
• preview URLs are a core collaboration workflow
• ISR, middleware, serverless functions, or image optimization are real requirements
• the blog and app should deploy together
• Pro cost and usage-based billing are acceptable

Migration advice

The easiest sites to migrate are the ones that avoid platform lock-in at the content layer.

1. Keep content in Markdown, MDX, or a portable CMS model.
2. Keep URL structure independent from the hosting platform.
3. Generate canonical URLs, sitemap, RSS, and structured data in the framework.
4. Keep large images and files easy to move to object storage later.
5. Document redirects before changing URL structure.
6. Keep environment variable names boring and portable.

For an Astro site, moving from GitHub Pages to Cloudflare Pages is usually repository connection, build command, output directory, custom domain, and DNS cutover. The build command is pnpm build, and the output directory is dist.

If you are moving language paths, do not use broad wildcard redirects without checking the generated files. For example:

# public/_redirects
/ko / 301

That only redirects the Korean language landing page to the root. If you also want to move /ko/posts/*, create the new URLs first and maintain slug-level redirects. A broad pattern that sends /ko/posts/example to /posts/example can create 404s and lose search traffic.

Moving from GitHub Pages to Vercel follows the same content and domain principles. The difference is strategic: if the site remains an Astro static blog, Vercel mainly gives you preview convenience and dashboard ergonomics. Cloudflare Pages gives you stronger static traffic economics.

The current choice for this stage

A technical blog can start on GitHub Pages when it is still a document site, not an application. The articles are static HTML, the publishing workflow is Git-based, and there is no runtime server to operate.

That choice is not permanent. If traffic grows and the site becomes more ad-supported, Cloudflare Pages is the next serious candidate. If a small product grows into authenticated apps with dashboards and server APIs, Vercel or a Cloudflare Workers-based architecture should be evaluated again.

The right platform is not the strongest platform in isolation. It is the platform that matches the current complexity while leaving enough room to move when the complexity changes.

FAQ

Should a personal blog start on Cloudflare Pages instead?

It can. If you already use Cloudflare DNS and expect to add Workers, R2, D1, cache rules, or WAF controls, Cloudflare Pages is a strong starting point. If your workflow is simply Markdown in GitHub plus a static build, GitHub Pages keeps the system smaller.

Is Vercel’s free plan okay for a static blog?

Yes. The question is whether you need the platform surface area. Vercel becomes more compelling when the blog is part of a Next.js product, preview deployments matter to a team, or serverless functions and framework features are part of the roadmap.

When should an ad-supported blog migrate away from GitHub Pages?

Watch transferred bytes, not only visitors. A small number of image-heavy posts can use more bandwidth than many lightweight text pages. If monthly transfer approaches GitHub Pages’ soft bandwidth limit or traffic becomes a business concern, plan a Cloudflare Pages migration while keeping URLs, canonical tags, and redirects stable.

Sources

• Vercel Pricing
• Vercel Limits
• Cloudflare Pages Limits
• Cloudflare Pages Functions Pricing
• Cloudflare Workers Pricing
• GitHub Pages overview
• GitHub Pages Limits

Read next

For the SEO side of this decision, read GitHub Pages SEO for Blogs: Is Static Hosting Bad for Search?. For the framework decision behind this site, read Astro vs Next.js for a Technical Blog: Why This Site Starts Static.