Edge Hosting on Cloudflare Workers

What Edge Hosting Means for You

Most small business sites run on a server that builds each page when someone asks for it. That server has to stay patched. It slows down when it gets busy. It can go down on a Sunday night and nobody knows until Monday.

We do it another way. Your site is built once into plain HTML files. Those files sit on Cloudflare, which has data centers in hundreds of cities. When a customer opens your page, the nearest one hands it over. There is no database to wait on and no plugin to update.

What you get is a page that shows up fast on a cheap phone with one bar of signal. That is the person you are trying to reach. It is also why we could raise 40 sites in our network to a 99 or 100 mobile PageSpeed score in one day. Fast is the default here, not a project.

Why We Left a Per-Deploy Bill Behind

We used to host on Netlify. It worked. Then its credit plan started to bill every production deploy. That sounds small until you count how often a real business site changes.

Say you fix a phone number, add a photo, and post a blog in one week. That is three deploys. Now add a spelling fix the next morning. Every one of those costs money on a credit plan. The quiet result is that people start batching fixes to save credits. A wrong phone number stays up for a week because it is cheaper to wait.

Cloudflare Workers static assets has no charge per deploy. So we ship a fix the minute it is right. That is the time we sell you. Nobody waits for a batch.

How the Worker in Front Is Wired

Plain files cannot do everything. A few jobs need a little code. We put one small Worker in front of the files to do them. It runs only for the requests that need it. Everything else goes straight to the files.

• The www redirect. Both addresses land on one canonical address, so Google sees one site, not two.
• Forms. A quote form posts to the Worker. The Worker checks it and hands it to your CRM as a tagged contact. See CRM and phone for where it goes next.
• Gated content. Some guides ask for an email first. The Worker checks for a cookie and serves the full page or the short one.

Here is the shape of it. This is a working Worker with a static assets binding named ASSETS.

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.hostname.startsWith("www.")) {
      url.hostname = url.hostname.slice(4);
      return Response.redirect(url.toString(), 301);
    }
    if (url.pathname === "/api/quote" && request.method === "POST") {
      const form = await request.formData();
      if (!form.get("phone")) {
        return new Response("Please add a phone number.", { status: 400 });
      }
      // hand off to the CRM here
      return Response.redirect(new URL("/thanks/", url).toString(), 303);
    }
    return env.ASSETS.fetch(request);
  },
};

What the File Limit Teaches You

Each Worker can hold a set number of files. The free plan caps it at 20,000. The paid plan raises that to 100,000. A normal business site is far under either one.

A directory is not. A site that lists every shop in every city can grow past 20,000 files faster than you think. Each listing page, each city page and each photo size counts as a file.

The lesson we learned is to count files before launch, not after. Our build prints the file count every time. If a site is heading toward the cap, we plan for it early. We move it to the paid plan, or we split large photo sets out to storage. That is a quick choice made on day one. It is not a failed deploy on the day you add your last city.

This is also why every new directory we build starts on Cloudflare. See the directory factory for how those sites are put together.

What It Saves the Owner

Here is what you stop doing when your site lives at the edge.

• You stop paying for plugin updates and security patches on a server.
• You stop waiting on a batch of fixes to save deploy credits.
• You stop worrying about a traffic spike after a TV spot or a viral post. Static files do not fall over under load.
• You stop guessing if the site is up. There is no origin server to go down.

We handle the DNS, the TLS certificate and the Worker. You tell us what should change, and it is live the same day. That is part of hosting and IT.

What We Learned the Hard Way

A deploy that says it worked does not prove the right files went out. We check the live page after every deploy. We fetch it and look for a line we just changed. If that line is not there, the deploy did not happen, whatever the log says.

We also learned to purge the cache on purpose. A new page can hide behind an old cached copy for a while. So we clear it when a change matters, like a new phone number.

Last, keep the Worker small. Every line in it runs in front of every customer. The less it does, the less it can break. Most requests never touch it at all.

Next, see how the files themselves get made on static site builds, or read the full guide on Cloudflare static hosting.