For a while, both of my websites ran on a virtual private server I paid for monthly. It worked — but recently I moved them onto Cloudflare Pages, which costs nothing, deploys automatically, and has less that can break. This is a walk through how that works, why it’s possible, and — just as importantly — when it’s the wrong choice.
The thing most people don’t realise about a “website” Link to heading
A lot of websites don’t need a server at all.
If your site is a blog, a portfolio, a landing page, or a company brochure — anything where every visitor sees the same pages — then it’s a static site. It’s just a folder of HTML, CSS, JavaScript, and images. There’s no live program running, no database being queried, nothing being calculated when someone visits. The files were finished the moment they were built, and the “server” is doing nothing more than handing those finished files to whoever asks.
That’s the key insight. If nothing needs to run, you don’t need a machine that’s always on. You just need somewhere to keep the files and hand them out — and that turns out to be something several companies will do for free.
The opposite of a static site is a dynamic site — something that generates pages on the fly per visitor. A site with user logins, a live database, a checkout that processes payments, a forum. Those genuinely need a running server. But far fewer sites need this than people assume.
What Cloudflare Pages actually does Link to heading
Cloudflare Pages connects to your code repository — mine are on GitHub — and does two things:
First, when you push a change, it builds the site on their machines. My blog runs on a static-site generator, so Pages runs the build command, turns my content into finished HTML, and does that on their infrastructure instead of mine. (For a plain HTML site there’s nothing to build — it just takes the files as they are.)
Second, it serves the result from Cloudflare’s global network — servers spread across the world, so a visitor loads the site from somewhere physically near them. That’s genuinely faster than a single server sitting in one country, which is what I had before.
The workflow after setup is the part I like most: I write a post, commit it, and push. A minute later it’s live. No logging into a server, no manual upload, no command to run. The push is the deploy.
Why it’s free — and whether that’s a catch Link to heading
The honest answer: it’s free because static files are cheap to serve, and Cloudflare would rather have you inside their ecosystem than charge you a few rupees for bandwidth. The free tier includes unlimited sites, unlimited bandwidth, a generous number of builds per month, free SSL certificates, and their CDN. For a personal site or a small business site, you will almost certainly never hit a limit.
There’s no bait-and-switch that I’ve found. The paid tiers exist for teams that need more concurrent builds or advanced features — none of which a normal website needs. I’m not paying anything, and nothing is nagging me to.
The trade-offs, stated honestly Link to heading
This isn’t a free lunch with no downsides. There are real ones, and if you’re weighing this up you should know them.
You give up the server — including the things a server can do. This is the big one. The moment your site needs something dynamic — a contact form that emails you, a login, a database, a background job, anything that runs — Pages alone can’t do it. There are workarounds (external form services, serverless functions), but if you’re running actual server software, this model doesn’t fit. I moved my sites off a server precisely because they didn’t need one. If yours does, keep the server.
You’re dependent on one company. Your site lives on Cloudflare’s platform, built their way. Moving to another provider later means redoing the setup. With your own server you can pick it up and move it anywhere. This is a mild lock-in, not a severe one — your actual content stays in your own git repository, which is the part that matters — but it’s real.
Old-style server config doesn’t carry over. One of my sites had an Apache .htaccess file and a cgi-bin folder from its shared-hosting days. Neither means anything on Cloudflare Pages — that platform works completely differently. If your current site leans on server-specific configuration, redirects, or scripts, you have to re-create those the Cloudflare way. For me it was nothing; for a more complex site it could be an afternoon.
Build settings can bite you. A static-site generator has a version, and if the hosting platform builds with a different version than you tested with, the site can render wrong or fail to build. It’s fixable — you pin the version explicitly — but it’s the kind of thing that trips people up on the first deploy.
When free hosting is right — and when it isn’t Link to heading
Reach for it if: you have a blog, a portfolio, a landing page, a documentation site, a small-business brochure site, or anything where visitors read rather than interact. If you’re currently paying for a VPS only to serve a static site, you’re paying for a server to do a job a free service does better.
Keep your own server if: you run anything that needs to be always-on and doing something — a database-backed app, automation workflows, self-hosted tools, background services. In my case I still keep a server for exactly those reasons; it’s just that the websites no longer need to live on it.
That distinction — static versus dynamic, files versus a running program — is the whole decision. Get that right and the hosting choice answers itself.
The takeaway Link to heading
Moving my sites to Cloudflare Pages meant no monthly hosting bill for them, faster loading worldwide, automatic deploys on every push, free SSL, and noticeably less that can break — because there’s no server to patch, secure, or wake up at 2am for. The cost was giving up the ability to run server-side code on those sites, which they never needed anyway.
If you’re paying every month to host a website that’s really just a set of files, it’s worth asking whether you need to be paying at all. For a lot of sites, the honest answer is no.