Why I host everything on Cloudflare Pages

The hosting problem every developer eventually faces

Every side project, client site, and internal tool I build eventually needs to live somewhere. For years, that meant juggling a mix of VPS instances, shared cPanel hosts, Vercel, Netlify, Firebase Hosting, and GitHub Pages — each with its own billing dashboard, deployment workflow, and set of quirks. The cognitive overhead was real. One evening I moved everything to Cloudflare Pages, and I haven't opened another hosting dashboard since.

This isn't a sponsored post. It's just what happened when I stopped treating hosting as a necessary evil and started treating it as part of the developer experience worth optimizing.

The best infrastructure is the kind you stop thinking about. Cloudflare Pages got me there — one dashboard, one deploy command, one mental model for every project from portfolio sites to production APIs.

What is Cloudflare Pages, exactly?

Cloudflare Pages is a JAMstack hosting platform that deploys your static assets (HTML, CSS, JS, images) to Cloudflare's global edge network — currently spanning 300+ data centres across 100+ countries. Unlike traditional hosting where your files live on one server in one region, Pages puts them everywhere simultaneously. When a user in Mumbai hits your site, they get served from a nearby edge node, not a server in Virginia.

It integrates directly with GitHub and GitLab. Push to main, and your site is live in under 30 seconds. Preview deployments are created automatically for every pull request, with a unique URL you can share with a client for review. That alone replaced my entire staging workflow.

Why I switched: the five real reasons

1. A genuinely free tier that doesn't expire

The free plan includes unlimited bandwidth, 500 builds per month, unlimited sites, and custom domain support with automatic HTTPS. There's no trial period, no credit card required, and no bandwidth throttling after a certain threshold. For personal projects and client microsites, this means zero hosting cost indefinitely. I have over a dozen live sites on the free tier right now, including the CDN file manager I built for futeducation.com.

2. Zero cold starts — ever

Cold starts are the silent killer of developer experience on serverless platforms. On AWS Lambda or Firebase Cloud Functions, if your function hasn't been invoked recently, the first request after a period of inactivity suffers a 200–800ms cold start penalty. Cloudflare Workers — the runtime that powers Cloudflare Pages Functions — runs on V8 isolates instead of containers. There is no cold start. The first request is as fast as the thousandth.

// Cloudflare Pages Function — runs at the edge, zero cold start
export async function onRequest(context) {
  const { request, env } = context;
  return new Response(JSON.stringify({ status: "ok" }), {
    headers: { "Content-Type": "application/json" }
  });
}

This matters enormously for API endpoints, form handlers, and any function that might receive sporadic traffic. On the NEET predictor tool I built for futeducation.com, lead submissions hit a Workers endpoint and are written to a Google Sheet in real time — with consistent sub-100ms response times regardless of traffic pattern.

3. Git-based deploys with zero configuration

You connect your GitHub repo once. Cloudflare reads your build command and output directory, and from that point forward, every push triggers an automatic deploy. No CI/CD pipeline to configure, no deploy.yml to write, no secrets to manage across platforms. For a monorepo or a project with multiple environments, you set up separate Pages projects pointing at different branches — staging on develop, production on main.

# Zero config needed — just tell Pages your build command once
Build command:   npm run build
Output directory: dist
Root directory:  /

# Cloudflare handles the rest — preview URLs, branch deploys, rollbacks

4. Edge Workers co-located with your static site

This is the feature that separates Cloudflare Pages from every other static host. Pages Functions let you add server-side logic — form handling, API proxying, authentication, dynamic OG image generation — without leaving the Pages ecosystem. Your Worker runs in the same edge network as your static assets, which means there's no cross-region latency between your frontend and your backend logic.

I use this pattern constantly: the static HTML is served from the edge, and any dynamic requests (form submissions, API calls, auth checks) are handled by a co-located Pages Function. The entire stack lives in one Git repo, deploys as one unit, and scales to any traffic level automatically.

5. The Cloudflare ecosystem compounds the value

Once you're on Pages, the rest of Cloudflare's product suite becomes trivially easy to integrate. R2 for object storage (S3-compatible, no egress fees). D1 for a SQLite database at the edge. KV for global key-value storage. Queues for async job processing. Analytics for privacy-respecting traffic data with zero JavaScript overhead. Each of these is one binding declaration away in your wrangler.toml. No separate SDK to install, no IAM policy to configure, no billing account to link.

# wrangler.toml — bind R2, KV, and D1 in one config
[[r2_buckets]]
binding = "ASSETS"
bucket_name = "my-cdn-bucket"

[[kv_namespaces]]
binding = "CACHE"
id = "abc123"

[[d1_databases]]
binding = "DB"
database_name = "my-app-db"

What I actually run on Cloudflare Pages today

My own portfolio at ravisrivastava.in is on Pages. The CDN file manager I built for futeducation (handling uploads to GitHub via the API and serving assets through jsDelivr) uses a Cloudflare Worker as its backend, also deployed through the same workflow. The RSoftInnovations client site is on Pages. Several client landing pages, internal tools, and NEET-related microsites — all on Pages. The operational overhead across all of these is essentially zero. I push code, the site updates. That's the entire workflow.

When Cloudflare Pages is not the right choice

It's worth being honest: Pages is a static-first platform. If your application needs long-running server processes, persistent WebSocket connections, or heavy server-side rendering with a Node.js runtime (Next.js App Router with complex RSC usage, for example), you'll hit the edge runtime's constraints. Workers have a 128MB memory limit and a 50ms CPU time limit per request on the free plan. For compute-heavy workloads — video transcoding, ML inference, large file processing — you need a different tool. But for the vast majority of web projects I build — marketing sites, dashboards, APIs, form handlers, client portals — Pages handles it perfectly.

Getting started in under five minutes

Connect your GitHub account at pages.cloudflare.com. Select your repo. Set your build command and output directory. Click Deploy. Your site is live on a *.pages.dev subdomain with HTTPS in under a minute. Add a custom domain by entering it in the Pages dashboard — Cloudflare handles the DNS, certificate provisioning, and renewal automatically if your domain's nameservers point to Cloudflare. The entire setup, from zero to production with a custom domain, takes less time than configuring an S3 bucket policy.

---

If you want help setting up a Cloudflare Pages deployment pipeline for your project — or integrating Workers, R2, or D1 into an existing stack — get in touch. I'm available for consulting and project work.