Hosting a static site: Cloudflare, Netlify or a VPS

Hosting a static site looks like the easy part of the project. The site is a folder of HTML, CSS and image files built at the moment of publication, and almost any hosting can serve it. That is what makes the choice misleading: they all serve it fast, and the differences only appear at the first exhausted quota or the first redirect that does not do what you thought.

This site and Palmora Property, a real estate portal we operate for a client, are built with Astro. The website and web app of Challenge Us, a group challenge app that we developed, have been served as static files by Cloudflare since September 2026. Here is what we take from these choices, along with the rules that the vendors themselves publish. If the question is still whether to leave WordPress, start with why migrate to a static site with Astro.

What a static site host must do

Before comparing names, here is the list of what you expect:

• Build and deploy at every publication, with no manual intervention, including when the content comes from a CMS: a headless site with Astro and Sanity is rebuilt at every publication thanks to a webhook.
• Keep previous versions and go back to one of them in a single step when a publication breaks something.
• Serve private previews of a branch, to review before publishing.
• Handle redirects and headers (cache, security, noindex on previews) in files versioned with the site.
• Serve HTTPS on your domain, certificate included.

Netlify and Cloudflare tick these boxes. The difference lies elsewhere: in what is counted.

What is counted, and why that is the real criterion

Files served

At Cloudflare, the Workers static assets documentation states that requests for these files are neither billed nor limited, and that storing them adds no cost. Only the requests that run the Worker’s code, for on-demand rendering for example, follow the Workers price list. For a genuinely static site, a traffic spike therefore does not change the bill.

At Netlify, the page that explains credits describes, in October 2026, credit-based plans: 300 credits a month on the Free plan, 1,000 on Personal, and from 3,000 on Pro. This balance is used up as follows:

On the Free plan, twenty production deploys are therefore enough to use up the month. These amounts change: reread the page before deciding.

Code executed

This is where most of the surprises come from. A “static” site often keeps a few functions: a form, a webhook, a page rendered on demand. Netlify counts this computation in credits, 10 per gigabyte-hour; at Cloudflare, every request that wakes the Worker is billed according to its price list. A function called on every visit makes the bill climb with traffic, which cancels the point of going static. It is better to have rare functions, called only when a visitor acts: the article on forms and search on a static site shows how.

The shared account

The least visible trap: on some plans, the balance belongs to the account, not to the site.

That is why we moved Challenge Us, in September 2026, out of a Netlify team shared with other projects, where exceeding the quota paused all of the team’s projects. The lesson goes beyond this case: a client, or a product that has a life of its own, is better off with its own hosting account.

The settings that surprise

The order between redirects and files. The same configuration behaves differently from one host to another:

The Challenge Us website sends any address that is not one of its pages to the app: that rule lives in the code of its Worker rather than in _redirects, where it would have masked the site’s pages.

The index.html page. By default, according to its documentation, Cloudflare redirects /index.html to /. The Challenge Us web app turns this behaviour off: its service worker serves index.html on every launch, and a redirect there would make the app fail to open.

The headers actually served. A headers file only applies to the responses to which the host applies it.

As soon as a page is rendered on demand, check the response itself, with curl -sI on the public address, rather than the configuration.

None of these settings is serious once you know it, and all of them can be checked before going live, on the preview address.

What about a server of your own?

Serving a folder of files from a private server is simple. We run a single server ourselves that hosts about a dozen services: it is the right tool for business applications, rarely the best for a public site. The reasons:

• no worldwide delivery without adding a CDN in front;
• certificates, system updates and monitoring become your responsibility again;
• no built-in rollback, unless you build it.

It makes sense when a constraint requires it: hosting that is already paid for and imposed, a data location requirement, or visitors behind corporate networks or in countries that filter certain services. In that last case, the host matters less than the page itself: fonts and resources hosted on the site, no call to a third-party service.

Cloudflare, Netlify or your own server: what changes

How to choose, in four questions

1. Does the site run code on every visit? If not, a host that does not count files served makes traffic irrelevant to the budget.
2. How many deployments a month? At a host that counts them, a site published ten times a day by an editorial team does not cost what a site updated every week costs.
3. Is the account shared with other projects? If so, what happens when one of them uses up the balance?
4. Who manages the domain and the DNS? Having the DNS with the same provider as the hosting simplifies certificates and switchovers.

Answer these four questions, then test the configuration on a preview address before attaching the domain. If your current site runs on WordPress or Drupal, our migration to a static site keeps every address, puts the site live on hosting for a few euros a month and monitors the switchover for fourteen days.

Frequently asked questions

Sources

1. The Workers static assets documentation (new tab)developers.cloudflare.com
2. The page that explains credits (new tab)docs.netlify.com
3. The usage limits published by GitHub (new tab)docs.github.com