How to Host Your Website for Free with Cloudflare: Pages + Workers (2025 Guide)

From paying for servers to “free and global”

Here’s the part most newcomers miss: you don’t need a traditional host to get a fast, globally available site online. Cloudflare’s platform pairs Pages (for static files) with Workers (for optional serverless logic). That combination covers everything from a simple portfolio to a tiny app with API routes—no VPS, no Nginx, no patching.

The fastest path uses a direct, code-free deploy: drag-and-drop your built site into Pages and you instantly get a production URL with HTTPS on a world-scale CDN. When (or if) you need dynamic behavior—contact forms, authenticated endpoints, rate-limited API calls—you can add Workers alongside your static site.

Deploy in 60 seconds: the direct upload flow

  1. Prepare a folder containing index.html, CSS, JS, and assets.
  2. In Cloudflare dashboard, go to Workers & Pages → Create application → Pages → Use direct upload.
  3. Name your project (this also becomes your staging URL).
  4. Drag your folder (or a .zip) into the uploader and click Deploy.

That’s it. Cloudflare provisions TLS automatically and serves your site at <project>.pages.dev from its global edge. You can share the link immediately, test on mobile, and iterate without touching a server.

Connect a custom domain (optional but recommended)

When you’re ready to look polished, attach a custom domain. If your DNS already sits on Cloudflare, it’s nearly point-and-click inside the Pages project. If it doesn’t, you’ll add a CNAME pointing to your Pages subdomain. Cloudflare issues the certificate and routes traffic for you—no Let’s Encrypt wrangling.

Prefer visitors to always use your domain rather than .pages.dev? Add a managed redirect so the staging URL 301s to your branded host.

Edit, redeploy, and roll back with confidence

Change a hero image, tweak CSS, add a new page—then create a new deployment. Pages gives you atomic deploys, preview links for each version, and instant rollbacks. Outgrowing manual uploads? Flip to the Git-connected flow so every push builds and deploys automatically.

Add a backend with Workers (only if you need it)

Many sites are fine as pure static, but if you need runtime logic—form handling, data fetch with API key protection, rate limiting-drop in Workers. You can colocate a Worker in front of your Pages site to process requests, set headers, or serve JSON endpoints. Because Workers run at the edge, latency stays low worldwide.

  • Examples: contact form that writes to a KV/D1 store, newsletter signup that calls a third-party API with a secret, tiny JSON API for your frontend.
  • Tip: cache aggressively at the edge for GET routes and use short TTLs on dynamic pages.

Free-plan guardrails (what to know up front)

The free tier for Pages is generous for personal sites and prototypes. Direct uploads don’t “build” anything, and Git-connected projects have ample monthly build allowance. Workers on the free tier cover a healthy number of requests per day; when you outgrow that, paid plans scale linearly and are inexpensive compared with traditional hosting.

Practical takeaway: if you’re launching a portfolio, marketing page, docs site, or a small app with light serverless needs, you likely won’t hit ceilings early.

Two pro tips so you don’t get surprised

  1. Pages Functions require a build. If you want server-side code inside a Pages project (Pages Functions), deploy via the CLI (Wrangler) so the function code is compiled and bundled. Direct Upload is ideal for static files only.
  2. Workers run before the cache. Requests that go through a Worker count as Worker invocations even when content is cached. Design with caching in mind for cost and speed.

The five-step free path, recap

  1. Prepare your static site folder.
  2. Deploy via Pages → Direct Upload.
  3. Share the .pages.dev URL (HTTPS by default).
  4. Attach your custom domain and add a 301 from staging.
  5. Iterate with new deployments; add Workers only when needed.

Why this stack feels “unfairly good” for indies

You skip the old triangle of “buy hosting, configure a server, tune performance.” Instead you inherit a global CDN, automatic TLS, versioned deploys, and a clean path to add programmable logic later. For many personal sites, prototypes, and early-stage products, that’s the difference between shipping today and never getting around to it.

References