Jordan Polasek on Cloudflare Pages: A Practical Guide to Deploying Static Sites for Texas Businesses

Most Texas small businesses do not need a $400/month WordPress hosting plan. They do not need a website that takes three seconds to load. They do not need a CMS that requires a security patch every other week. What they actually need is a fast, secure, professional-looking marketing site that costs roughly nothing to host, never gets hacked, and survives a traffic spike when a piece of content actually catches on.

For the last few years, my default answer for that has been Cloudflare Pages. This post is the version of the conversation I usually have with a client who's asking why I picked it, how it works, and — the question I get most often — how to push an updated build over an existing site without nuking what's there.

Why Cloudflare Pages over the alternatives

There is no shortage of static-site hosts in 2026. Netlify, Vercel, GitHub Pages, AWS S3 + CloudFront, Azure Static Web Apps — all of them work. I tried most of them on real client environments before settling on Cloudflare Pages as my default. The reasons are practical, not philosophical:

1. It's free at the tier most Texas SMBs need. Unlimited bandwidth on the free plan. 500 builds per month. Custom domains, free SSL, free CDN. For a typical small-business marketing site, you will never pay Cloudflare for hosting.
2. The DNS is on the same dashboard. If you already have your domain at Cloudflare for DNS (and you should — their DNS is the fastest in the industry), Pages plugs into it without any cross-vendor friction. Add the project, point the custom domain, done. No CNAME-pointing rituals across two control panels.
3. The edge network is meaningfully fast. Texas users hit Cloudflare's Dallas, Houston, or San Antonio points of presence. First-byte times under 50 milliseconds are normal. Your bounce rate goes down because your site loads before the user has time to give up.
4. The security defaults are sane. Free SSL with automatic renewal. HTTP/3. DDoS protection. The WAF is available on paid plans but most small businesses don't need it for a marketing site.
5. It separates content from deployment cleanly. Each upload creates a new immutable deployment with its own preview URL. You can flip the production alias between deployments instantly. Rollbacks are one click.

For larger clients — anything with an actual application server, a database, or dynamic user accounts — Cloudflare Pages is not the right answer; you want a real PaaS or VM. But for the marketing-site-and-blog use case that covers the vast majority of Texas small business websites, it is hard to beat.

The basic deploy: from zero to live

The first deploy is straightforward enough that I usually walk a client through it on a screenshare:

1. Sign in to the Cloudflare dashboard (dash.cloudflare.com).
2. Left sidebar: Workers & Pages.
3. Click Create application → Pages → Upload assets.
4. Give the project a name (this becomes the your-project-name.pages.dev default URL).
5. Drag and drop the entire build folder onto the page. Cloudflare uploads everything and creates the first deployment.
6. Once it finishes, click Continue to project. You'll see the temporary .pages.dev URL — verify the site loads correctly there before adding a custom domain.
7. Click Custom domains → Set up a custom domain and enter your domain (e.g. jordanpolasek.com). If the domain is already on Cloudflare DNS, you can also add the apex and the www subdomain in one step.

Cloudflare provisions the SSL certificate automatically. From green-checkmark on DNS to live on the custom domain is usually under five minutes.

The follow-up deploy: uploading a new build without deleting the existing site

This is the part that trips most people up — and the part the documentation does not call out clearly enough. The Cloudflare UI has been redesigned a couple of times, and the "upload another version" workflow is not on the project's main dashboard.

To deploy a new version of an existing Pages project without removing what's already deployed:

1. Go to Workers & Pages in the Cloudflare dashboard.
2. Click your existing project (the one with the live site).
3. You'll land on the Deployments tab by default. This shows the deployment history — every prior upload is preserved.
4. Click the Create deployment button (top right). This is the button people miss; it doesn't say "upload" anywhere on it.
5. You'll be presented with the same upload UI as the original deploy — drag and drop your updated build folder.
6. Cloudflare uploads the new version, creates a fresh immutable deployment, and (assuming your project is set to auto-promote production) flips the production alias to the new build automatically.

If you want a folder-based update, not a full re-upload

One pattern I get asked about often: "I just want to upload a new image or a new blog post into the existing site, not re-upload everything." The honest answer is: Cloudflare Pages is designed around immutable deployments, not in-place edits. Each upload creates a new full snapshot of the site.

In practice this is fine. Drag the updated build folder onto Create Deployment, Cloudflare diffs it against the previous version, and only re-uploads what changed. The build will finish in seconds even on a multi-megabyte site, because the unchanged assets are already cached on the edge. You get to think about it as "uploading the folder" and Cloudflare handles the rest.

Connecting it to a Git workflow (optional)

If your site lives in a Git repository (GitHub, GitLab, or Bitbucket), you can wire Cloudflare Pages directly to it instead of dragging folders. Every push to the production branch triggers a build and deploy automatically; every push to a feature branch creates a preview deployment with its own URL you can share with the client for review.

For Texas small businesses I generally do not push this — the manual drag-and-drop workflow is closer to how non-developers think about a website, and it works fine. If the client has a developer in the family or already runs a Git workflow, I'll set up the Git integration; otherwise, I keep it simple.

The DNS hand-off question

A common situation: the client's domain is currently with GoDaddy, Namecheap, or some old registrar, and Cloudflare wants to manage the DNS. The right approach is to move the DNS to Cloudflare (the domain registration can stay where it is). Cloudflare's free plan handles DNS for unlimited domains; the performance and security benefits are real; and once DNS is on Cloudflare, Pages and the rest of Cloudflare's product family integrate cleanly.

This is a 30-minute job done correctly: export the existing DNS records, add the domain to Cloudflare, recreate the records (Cloudflare will pre-fill most of them via DNS scan), update the nameservers at the registrar, and verify propagation. I do this for every BVTech client whose website I take over.

What it costs

For a typical Texas small business marketing site:

• Domain registration: $9–$15/year (wherever you bought it).
• Cloudflare DNS: $0.
• Cloudflare Pages hosting: $0.
• SSL certificate: $0.
• CDN: $0.

Total ongoing cost: the price of the domain renewal. That's it. The site is faster than 95% of WordPress sites in the same category, more secure than most CMS-based sites, and impossible to "hack" in the conventional sense because there is no admin login to exploit.

The honest limits

Cloudflare Pages is the right answer for a marketing site, a blog, a portfolio, documentation, or a landing page. It is the wrong answer for anything that needs server-side processing — an e-commerce checkout (use Shopify or BigCommerce), a member portal (use a real PaaS or hosted platform), a database-backed application (use AWS or Azure), or any workflow that requires real backend code beyond what Cloudflare Workers can do.

If your Texas business needs a website to attract clients and tell your story, this is the stack. If your Texas business is a website — meaning the website is the product — you need to have a longer conversation about hosting, and BVTech is happy to have it with you.