For years, the playbook for deploying a modern frontend application was simple: connect a GitHub repository to a platform like Vercel or Netlify, let their build pipelines generate your static assets, and push them to a Content Delivery Network (CDN).

While this model revolutionized web development, it introduced a hidden architectural tax. When your application scales and requires serverless database queries, file storage, or authentication, you are often forced to bolt on third-party cloud services. This introduces cold-start latency and fragmented pricing structures.

Cloudflare Pages shifts this paradigm. It is not just a static hosting platform; it is a unified, full-stack deployment ecosystem built directly on top of Cloudflare’s global edge network

The Core Concept: Infrastructure Without the Glue

At its core, Cloudflare Pages operates similarly to the tools you likely already use. You connect your Git repository, and every time you push code, Cloudflare builds and deploys your project globally.

However, the structural difference lies beneath the surface. Traditional platforms often rent underlying infrastructure from hyper-scalers like AWS and add an abstraction layer on top. Cloudflare Pages runs natively on Cloudflare’s own hardware, spanning over 335 cities globally.

Because it sits natively inside the Cloudflare ecosystem, your frontend code integrates out of the box with their broader developer platform:

• Workers (Serverless compute)
• R2 (Object storage with zero egress fees)
• D1 (Native serverless SQL database)
• KV (Global key-value storage)

Cloudflare Pages vs. Vercel/Netlify

When deciding where to host your next application, the generous limits of Cloudflare’s free tier are highly compelling. Because Cloudflare owns the underlying network pipes, they do not need to charge premium markups on bandwidth or request volume.

While Cloudflare gives away unlimited bandwidth and requests, their primary constraint on the free tier is concurrent builds. On the free tier, you can only run one build at a time. If you push code to three different projects simultaneously, they will queue up and run sequentially.

Architectural Deep Dive: Full-Stack Edge Architecture

Historically, static hosting platforms required you to spin up a separate cloud function or an entirely different backend server if you needed to process a form or query a database.

Cloudflare Pages solves this natively through Pages Functions. By simply adopting a file-based routing convention, any backend code you write is automatically compiled into globally distributed serverless functions running on Cloudflare Workers.

How File-Based Routing Works

If you create a top-level /functions directory in your project root, Cloudflare maps those files directly to HTTP endpoints:

my-project/
├── functions/
│   ├── api/
│   │   ├── hello.js       ➔ Executes on GET /api/hello
│   │   └── users/
│   │       └── [id].js    ➔ Dynamic routing: GET /api/users/:id
│   └── _middleware.js     ➔ Runs on every single request (Auth, Logging)
└── src/                   ➔ Your frontend application (React, Astro, Vue, etc.)

Writing an Edge Function

Because these functions run on V8 isolates rather than traditional Node.js containers, they boast near-zero cold starts. Here is how clean a native API endpoint looks:

// functions/api/users/[id].js

export async function onRequestGet({ params, env }) {
  const { id } = params;
  
  // Safely read an environment variable injected at the edge
  const apiKey = env.EXTERNAL_API_KEY; 

  // Perform a high-speed fetch to an external service or internal database
  const response = await fetch(`https://api.provider.com/v1/users/${id}`, {
    headers: { 'Authorization': `Bearer ${apiKey}` }
  });
  
  const userData = await response.json();

  return new Response(JSON.stringify(userData), {
    headers: { 'Content-Type': 'application/json' }
  });
}

Production Deployment Strategies

Cloudflare accommodates both Git-driven workflows and continuous integration (CI/CD) terminal pipelines.

Strategy A: The Git-Integrated Pipeline (Recommended)

This approach minimizes friction for teams. Cloudflare securely hooks into your Git provider (GitHub or GitLab) to listen for changes.

1. Navigate to the Cloudflare Dashboard and select Workers & Pages.
2. Click Create Application -> Pages -> Connect to Git.
3. Point to your repository and select your framework. Cloudflare detects settings for major frameworks automatically

Once linked, every single Pull Request automatically generates a unique, isolated Preview URL. This allows team members to test changes in a production-identical environment before merging code to the main production branch.

Strategy B: The Terminal-Driven Pipeline (Wrangler CLI)

If you run complex CI/CD environments (like GitHub Actions, GitLab CI, or Jenkins) and prefer to compile your application locally before shipping, you can bypass Git integration entirely using Cloudflare’s CLI tool, Wrangler.

# 1. Install the runtime tools globally
npm install -g wrangler
# 2. Authenticate your terminal with your Cloudflare account
wrangler login
# 3. Execute your local compilation step
npm run build
# 4. Atomically ship the compiled directory straight to the global edge network
wrangler pages deploy ./dist --project-name=my-app-production

Modern Framework Interoperability

Because modern web frameworks are moving away from purely static compilation toward hybrid Server-Side Rendering (SSR), Cloudflare partners directly with framework core teams to maintain high-performance runtime adapters.

• Next.js: Supported natively using the @cloudflare/next-on-pages adapter. It maps Next.js App Router features and API routes directly onto global edge instances.
• Astro: Offers an official, built-in Cloudflare adapter supporting hybrid rendering. This lets you select on a per-page basis whether to render to static HTML at build time or fetch data dynamically on the edge.
• SvelteKit & Remix: Both operate natively on the V8 edge model. They use Cloudflare’s architectural design to eliminate regional database latencies.
• Single Page Apps (React, Vue, Vite): Require no specialized server configurations. They compile directly to static assets and deploy straight to global edge storage out of the box.

Part 3 goes deeper into Cloudflare Workers — the engine powering Functions — and how to write and deploy edge compute directly.

What is Cloudflare?

Cloudflare is a global network infrastructure company. At its core, it sits between your users and your servers — intercepting every request, securing it, speeding it up, and routing it intelligently.

Think of it like a very smart security guard and delivery service combined. It stops bad actors at the door, serves cached content instantly, and only lets legitimate, optimized traffic through to your actual server.

Today, Cloudflare operates in over 335 cities across 125+ countries. Roughly 20% of all web traffic flows through its network. When a site goes down because of a DDoS attack, there’s a good chance Cloudflare is what stopped it.

How the internet actually works (briefly)

Before understanding Cloudflare, you need to understand the basic flow of a web request:

1. You type a URL — your browser needs to know where to find the server for that domain.
2. DNS lookup — your browser asks a DNS server: “What’s the IP address for example.com?”
3. Connection — your browser connects to that IP address.
4. Request travels — your HTTP request travels from your machine to the server, possibly across continents.
5. Response comes back — the server sends back HTML/CSS/JS/images.

Cloudflare inserts itself at step 2 onwards. When you put a domain on Cloudflare, you point your DNS at Cloudflare’s nameservers. From that moment, every request for your domain first hits Cloudflare’s network — not your server directly.

Setting up Cloudflare — your first 10 minutes

Step 1: Create an account

• Go to cloudflare.com and sign up for a free account. The free tier is genuinely useful — not a crippled trial.

Step 2: Add your website

• Click Add a Site from your dashboard.
• Enter your domain name (e.g. mywebsite.com)
• Choose the Free plan and click Continue.

Step 3: Update your nameservers

• Cloudflare will scan your existing DNS records and then give you two nameservers to set at your domain registrar (where you bought the domain — GoDaddy, Namecheap, Google Domains, etc.).

Step 4: Verify activation

• Once active, your Cloudflare dashboard will show a green “Active” status. Every request to your domain now flows through Cloudflare.

Core Concepts

To understand how Cloudflare protects and speeds up a website, you first need to understand how the foundational “plumbing” of the internet works. Here is a breakdown of core networking concepts and how Cloudflare layers on top of them.

1. DNS: The Phone Book of the Internet

The Domain Name System (DNS) translates human-readable domain names (like example.com) into computer-readable IP (Internet Protocol) addresses (like 192.0.2.1). Computers need these numerical addresses to find and talk to each other.

Common DNS Record Types You’ll Actually Use

When configuring your domain, you will interact with these primary record types:

• A Record
  Purpose: Points a domain name directly to an IPv4 address.
  Example: example.com -> 192.0.2.1
• AAAA Record
  Purpose: Points a domain name directly to an IPv6 address (the newer, longer IP format).
  Example: example.com -> 2001:db8::1
• CNAME Record
  Purpose: Creates an alias. Points a subdomain to another domain name instead of a direct IP address.
  Example: www.example.com ->example.com
• MX Record
  Purpose: Directs incoming email traffic to your designated mail server (such as Google Workspace or Microsoft Outlook).
  Example: mail.example.com
• TXT Record
  Purpose: Holds administrative text notes. It is most commonly used to verify domain ownership for third-party services (like Google Search Console) or configure email security frameworks.
  Example: v=spf1 include:_spf.google.com ~all

2. The Traffic Flow: Standard vs. Cloudflare Proxy

To see exactly what happens when a user requests a website, let’s look at the architectural shift between a traditional direct connection and a Cloudflare-proxied connection.

The Cloudflare Advantage: Speed & “The Orange Cloud”

World’s Fastest DNS: Cloudflare operates 1.1.1.1, which is the fastest public DNS resolver globally, boasting an average response time of roughly 11ms.

Proxied (Orange Cloud) vs. DNS-Only (Grey Cloud):

• Orange Cloud (Proxied): Web traffic is intercepted and routed through Cloudflare’s network before hitting your server. This hides your server’s true IP (Origin IP Protection), keeping it safe from direct attacks.
• Grey Cloud (DNS-Only): Cloudflare acts purely as a phone book. It hands your real server IP directly to the user, bypassing Cloudflare’s security and performance features.

3. CDN & Caching: Serving Content Faster

A Content Delivery Network (CDN) consists of a globally distributed group of servers. Instead of forcing every user to travel across oceans to your primary server (the Origin Server), copies of your files are saved closer to the user.

Caching Behaviors

Caching is the act of saving a temporary copy of a file at the network edge.

• Default Behavior: Cloudflare automatically caches static files (images, CSS, JavaScript, fonts). It does not cache dynamic HTML files by default (like your checkout page or user dashboard).
• Cache Everything: You can force Cloudflare to cache absolute everything including raw HTML, by creating a Cache Rule (formerly Page Rules):

URL Pattern: example.com/*
Setting: Cache Level ➔ Cache Everything

You can also explicitly instruct Cloudflare how to cache your content using HTTP Response Headers sent directly from your origin server application:

HTTP

# Tell Cloudflare and browsers to cache this file for 24 hours (86,400 seconds)
Cache-Control: public, max-age=86400

# Tell Cloudflare never to cache this sensitive/dynamic file
Cache-Control: no-store

4. SSL/TLS: Encrypting the Web

SSL/TLS (Secure Sockets Layer / Transport Layer Security) is the cryptographic protocol that turns insecure http:// into secure https://, encrypting the data moving between a browser and a server.

Cloudflare eliminates manual certificate management by issuing and renewing free TLS certificates automatically. However, you must choose the correct SSL Mode based on your server’s setup:

• Full (Strict) [Recommended]: Encrypts the entire journey. Traffic from the user to Cloudflare is encrypted, and traffic from Cloudflare to your origin server is also encrypted using a verified, valid SSL certificate installed on your server.
• Flexible [Use with Caution]: Encrypts only half the journey. Traffic from the user to Cloudflare is secure, but traffic from Cloudflare to your origin server travels over the open, unencrypted internet. Only use this as a temporary fix if your origin server cannot support an SSL certificate.

5. Security: DDoS Mitigation & WAF

Because Cloudflare sits like a protective shield in front of your server, it can filter out malicious web traffic before it ever touches your infrastructure.

DDoS Mitigation

A Distributed Denial of Service (DDoS) attack attempts to crash your server by overwhelming it with an artificial flood of traffic from millions of infected devices (botnets).

Cloudflare handles this at the network level. Because its network capacity is so vast, it simply absorbs the immense flood of garbage data at its edge data centers. Cloudflare’s automated systems have successfully blocked historic volumetric attacks scaling up to 3.8 Terabits per second seamlessly without affecting legitimate users. This unmetered protection is turned on by default, even on their free plan.

WAF (Web Application Firewall) Rules

For targeted malicious activity (like spam bots, scraping, or hacking attempts), you can write customized rules to Block, Bypass, or Challenge traffic using variables like geographic location, IP address, or specific URLs.

• Example: Block an Entire Country
  If you don’t do business in a specific region and see heavy bot traffic from it, you can block it entirely:
  (ip.geoip.country eq "CN") ➔ Action: Block
• Example: Rate-Limit a Login Page
  Stop brute-force password guessing attacks on sensitive endpoints:(http.request.uri.path eq "/login" and cf.threat_score gt 10) ➔ Action: Managed Challenge

In Part 2, we move to Cloudflare Pages — how to deploy static sites and full-stack web apps directly onto Cloudflare’s network.

I write TypeScript at work. I write TypeScript at night. Same language, completely different experience.

At work, there’s a process. PRs get reviewed. Deployments are planned. There’s a staging environment, a QA cycle, and at least three people who will catch your mistakes before they hit production.

At home, there’s just you, a blank repo, a Claude window open on the side, and the quiet pressure of never actually finishing anything.

I’ve been shipping side projects on weekends for the past few years — LLM experiments, agent pipelines, half-finished SaaS ideas and the lessons I’ve picked up have made me a significantly better engineer at my day job too. Not because the code is better (it usually isn’t), but because the constraints are completely different.

2026 feels like a genuine inflection point for solo builders. The tools changed. The ceiling moved. Here’s what I’ve learned.

1. The hardest part isn’t the code — and AI didn’t change that

I used to think I wasn’t shipping because I needed to learn more. Better architecture. Cleaner abstractions. The right framework.

That was a lie I told myself.

Now I hear a new version of the same lie: “I’ll ship once I figure out the right AI stack.” Agents vs RAG vs fine-tuning. Which model. Which orchestration framework. It’s the same procrastination wearing a different hoodie.

The hardest part of shipping a side project is deciding what to cut. At work, the scope is defined for you. As a solo builder, every decision lands on you and the instinct is always to add, never to remove. AI makes this worse, not better, because the surface area of what you could build has exploded.

The projects I’ve actually shipped share one trait: I made a ruthless list of what the MVP was not going to do, and I held that line.

Practical tip: write a “not doing” list before you write a single line of code. In 2026 this list should explicitly include: not building a custom model, not adding an agent until the non-agent version works, not integrating five AI APIs when one will do. Mine usually has 10+ items now. It’s the most useful document in the project.

2. Your production instincts will slow you down — but your AI instincts might too

Four years of professional engineering gives you good instincts. Test coverage. Error handling. Scalable data models. Clean separation of concerns.

These instincts will actively hurt you on a side project in the early stages.

I’ve caught myself spending an afternoon setting up a proper monorepo with shared packages for a project that had zero users. I’ve agonized over database schema design for an app I hadn’t validated at all yet.

But in 2026 there’s a new trap: over-engineering the AI layer.

I’ve watched myself spend a weekend building a multi-agent orchestration system for a problem that a single well-prompted API call would have solved in an hour. I’ve added RAG pipelines to projects where the context window was already big enough to hold everything. I’ve reached for LangChain when a fetch request would do.

The mindset shift I needed: AI features have the same rules as every other feature. Start with the dumbest version that could possibly work. A hardcoded prompt in a single file ships faster than a beautiful agent framework with zero users.

You can always refactor. You can’t always get those weekends back.

3. Agents changed the math on what one person can build — but not in the way you think

This is the one that actually surprised me.

What moved the ceiling for solo builders in 2026 isn’t smarter models, it’s agents that can take actions. Code execution. Browser use. API calls. File systems. The ability to give an AI a goal and have it work toward it autonomously while you sleep.

I’ve run LLM experiments, built small tools on top of TensorFlow and NumPy, played with fine-tuning and embeddings. What used to take a team a recommendation engine, a content moderation layer, a smart search, a data pipeline — can now be prototyped by one person over a long weekend.

But here’s the part people skip: the leverage is in knowing when not to use it.

Agents are remarkably bad at knowing when they’re confused. They’ll confidently go down the wrong path for a long time before failing. The engineers building things that actually work are the ones who understand the failure modes deeply enough to build guardrails not the ones who just wire up the most impressive-looking pipeline.

The useful mental model I’ve landed on: treat an AI agent like a very fast junior intern who never asks for help. You need to spec the work clearly, define what done looks like, and check the output. The productivity gain is real. The “just let it run” fantasy mostly isn’t.

If you’re not building with agentic workflows in your side projects yet, start now. Not because it’s trendy but because the gap between what one person can ship with agents vs without is genuinely large and growing.

4. Vibe coding is real and the discourse around it is wrong

Let me say something that might be unpopular: I vibe code my side projects. A lot.

I describe what I want, iterate on the output, fix the weird bits, describe the next thing. My side project codebases would horrify a senior engineer. They’d also horrify me if I looked at them too carefully.

They have users.

The discourse splits into two camps: people who say vibe coding is the future and you don’t need to know how to code anymore, and people who say it produces garbage that will collapse under any real load. Both are mostly wrong.

What’s actually true: vibe coding is a fantastic way to move fast on the parts of a project that don’t matter yet, and a terrible way to handle the parts that do. The skill is knowing the difference.

I use it for: boilerplate, first drafts of UI components, writing tests for logic I’ve already written, exploring unfamiliar APIs, gluing things together.

I don’t use it for: anything touching money, auth, data integrity, or anything I’d be embarrassed to explain in a code review.

The engineers who will get the most out of this era are the ones who use AI to move fast on the easy stuff and apply their actual engineering judgment to the 20% that matters. Not the ones who either refuse to touch it or outsource their thinking entirely.

5. Side projects in 2026 are the best technical education available

This is the one I didn’t expect when I started.

When you own the whole stack — frontend, backend, deployment, debugging at 1am, plus now: prompt engineering, model selection, eval loops, context management, cost optimization — your intuition about systems improves faster than any course or job could teach you.

The AI tooling space is moving so fast that the only way to actually understand it is to build with it. Not read about it. Not watch conference talks. Build something real where you feel the pain of a bad prompt in production, where you see your inference bill spike and have to fix it, where an agent does something completely unexpected and you have to understand why.

I’ve learned more about LLMs from breaking them in side projects than from everything else combined.

My code reviews got sharper. My architectural instincts improved. My ability to evaluate AI tools honestly — not based on hype but based on whether they actually helped me ship — got significantly better.

Side projects are where you build the judgment that no job description can teach you.

Where I’m going next

I’m starting to build in public — sharing the process, the stack choices, the AI experiments that failed, and the ones that worked.

If you’re a full-time SWE building side projects in private, I’d encourage you to do the same. The accountability is worth it. The feedback is worth it. And honestly, the people you meet who are doing the same thing are worth it too.

Follow along on X: @vizydev

If any of this resonated — or if you disagree with any of it — drop a comment. I’m genuinely curious what other engineers building in 2026 are seeing.

I write about full-stack engineering, AI/LLM experiments, and building things on the side. If you found this useful, consider following for more.