DEV Community: cloudflare

How to Automatically Start a Cloudflare Tunnel When You Sign In to Windows

Travis Calvert — Tue, 20 Oct 2026 22:45:49 +0000

If you use Cloudflare Tunnel to expose a local development server, self-hosted application, or internal dashboard, you've probably encountered this problem:

Everything works until you restart Windows.

Your application might still be running, but the Cloudflare Tunnel process isn't. Suddenly, your public hostname is unreachable until you manually launch cloudflared again.

Here's how to automate that process using Windows Task Scheduler.

The problem

A typical Cloudflare Tunnel setup uses a command like:

cloudflared.exe tunnel run --token YOUR_TUNNEL_TOKEN

That works perfectly well in an interactive terminal.

But closing the terminal, signing out, or restarting Windows stops the process.

You can solve this by configuring Windows to launch the tunnel automatically when you sign in.

Step 1: Create a startup script

Create a PowerShell script named Start-Tunnel.ps1.

For example:

$cloudflared = "C:\Tools\cloudflared.exe"
$tokenFile = "$env:LOCALAPPDATA\CloudflareTunnel\token.txt"

if (-not (Test-Path -LiteralPath $cloudflared)) {
    throw "cloudflared.exe was not found."
}

if (-not (Test-Path -LiteralPath $tokenFile)) {
    throw "Tunnel token file was not found."
}

$token = (Get-Content -LiteralPath $tokenFile -Raw).Trim()

if ([string]::IsNullOrWhiteSpace($token)) {
    throw "Tunnel token is empty."
}

& $cloudflared tunnel run --token $token

Update the executable path to match your installation.

The script reads the tunnel token from a separate local file instead of embedding it directly in the script.

Security note: Your tunnel token is a credential. Don't commit it to GitHub, include it in screenshots, or share it in support requests. Restrict access to the token file to your Windows account.

Step 2: Configure Windows Task Scheduler

Open Task Scheduler and select Create Task.

Under General:

Give the task a descriptive name, such as Cloudflare Tunnel Startup.
Select Run only when user is logged on.
Use your normal Windows account.

Under Triggers:

Create a trigger that runs At log on.
Select your Windows account.

Under Actions, create a new action:

Program/script:

powershell.exe

Add arguments:

-NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Scripts\Start-Tunnel.ps1"

Replace the script path with your actual location.

Under Settings, review the options that control whether the task can start again while an existing instance is running.

Save the task.

Step 3: Test it

Right-click the task and select Run.

Check Task Manager for the cloudflared.exe process.

Then verify that your public hostname actually reaches your local application.

A running process alone doesn't prove the tunnel is connected successfully.

Finally, sign out and sign back in to confirm that the task launches automatically.

What about running the tunnel before login?

A sign-in task starts only after the specified user logs on.

If you need the tunnel to be available immediately after Windows boots, before anyone signs in, you'll need a different approach, such as a properly configured Windows service.

That distinction matters for unattended servers.

Where this basic approach gets complicated

Task Scheduler handles the initial launch, but a production-quality setup involves more than just running a PowerShell script.

You may also want:

Protection against duplicate launchers
A predictable way to stop the tunnel
Logging for troubleshooting
Secure token storage
Clean installation and removal
Reliable cleanup of child processes

These details can take longer to get right than the initial scheduled task.

A ready-made alternative

I built Cloudflare Tunnel Auto-Start Kit for Windows under Blacktop Logic to package the Windows sign-in approach into a reusable toolkit.

It includes PowerShell installation, startup, status, and uninstall scripts, along with process management and logging.

It is designed for user sign-in startup, not as a replacement for a Windows service.

The kit is available as a one-time $19 purchase:

https://payhip.com/b/FnwaJ

If you're comfortable maintaining your own scheduled task, the manual approach above may be all you need.

If you'd rather avoid building and troubleshooting the supporting scripts yourself, the kit is another option.

Published by Blacktop Logic — practical software utilities for developers and self-hosters.

Urdu voice notes to text on a free tier: Whisper pinned to Urdu, Roman Urdu without drift, and an honest error rate

Low Key Builds — Tue, 20 Oct 2026 18:16:54 +0000

Pakistan runs on WhatsApp voice notes. WhatsApp now writes transcripts for some languages, but Urdu is not in any list of supported languages I could find, and a Hindi transcript of Urdu speech comes out in Devanagari, which most Pakistanis do not read.

So I built Sunlo, a free web app: drop in a voice note, get Urdu script, Roman Urdu (the way people actually type on WhatsApp) and an English translation. Disclosure: I made it, and this post is how it works, including what it gets wrong.

The constraints: no budget, no audio stored anywhere, and a cheap Android phone as the main client.

1. Whisper on Workers AI, language pinned to Urdu

Cloudflare Workers AI hosts whisper-large-v3-turbo. The one setting that matters is language: 'ur'. Left to auto-detect, Whisper often decides Urdu speech is Hindi (the spoken languages are close) and writes Devanagari.

const w = await env.AI.run('@cf/openai/whisper-large-v3-turbo', {
  audio: base64Audio,      // WhatsApp .opus works as-is
  language: 'ur',          // never auto-detect for Urdu
  task: 'transcribe',
  vad_filter: true,        // skips silence in voice notes
});

WhatsApp's .opus files go straight in; no ffmpeg needed on the server.

2. A hard daily cap, enforced before the model runs

The free Workers AI allocation is 10,000 "neurons" a day. Whisper turbo costs about 46 neurons per audio minute ($0.00051/min at $0.011 per 1k neurons). The Worker keeps a per-day counter in D1 and reserves the estimated cost before calling the model, so parallel requests cannot overshoot, then corrects it with the real duration afterwards:

const est = seconds / 60 * 46.4 + 40;
const b = await env.DB.prepare('SELECT neurons FROM budget WHERE day=?').bind(day).first();
if ((b?.neurons || 0) + est > 8000) return json({ error: 'daily_cap' }, 503);
await env.DB.prepare(`INSERT INTO budget (day, neurons) VALUES (?, ?)
  ON CONFLICT(day) DO UPDATE SET neurons = neurons + excluded.neurons`).bind(day, est).run();

Per-visitor limits use a salted daily hash of the IP, so nothing identifying is kept. Audio and text are never written anywhere; D1 only holds counts, durations and timings.

3. Roman Urdu: transliterate, do not translate

Roman Urdu and English come from one call to Llama 4 Scout (about 11 neurons for a short note). The first prompt said "write it in Roman Urdu" and the model drifted into English words ("patient ko dusre se alag karna include hai"). Saying TRANSLITERATE, with two examples of how people type, fixed it:

"roman": TRANSLITERATE, do not translate. Write every Urdu word as the same
Urdu word in Latin letters, the way Pakistanis type on WhatsApp
(for example "main kal aaunga, aap fikar na karein").

Llama 3.1 8B was cheaper but changed words ("aaj", today, became "kal"). Scout, Llama 3.3 70B and gpt-oss-120b were all fine on clean text.

4. Long recordings: cut at silence, in the browser

Lectures and interviews are longer than one request should be. The browser decodes the file with AudioContext({ sampleRate: 16000 }), which also resamples to what Whisper wants, then cuts it into ~150-second pieces. Each cut goes at the quietest 50 ms window in the last quarter of the piece, so words are not split:

for (let w0 = lo; w0 < hi; w0 += win) {
  let e = 0;
  for (let j = w0; j < w0 + win; j++) e += mix[j] * mix[j];
  if (e < bestE) { bestE = e; best = w0 + (win >> 1); }
}

Pieces are transcribed one by one, joined, and then translated in a single pass, because translating fragments separately produced nonsense at the seams.

5. Share target: one tap from WhatsApp

On Android, an installed PWA can appear in WhatsApp's Share sheet. The manifest declares a share_target with a multipart POST; the service worker catches it, stashes the file in Cache Storage and redirects to the page, which picks it up:

"share_target": { "action": "/share-target", "method": "POST",
  "enctype": "multipart/form-data",
  "params": { "files": [{ "name": "audio", "accept": ["audio/*", ".opus", ".ogg"] }] } }

How accurate is it?

I ran the first 30 clips of the FLEURS Urdu test set (28 downloaded) through the live API, encoded as Opus like a WhatsApp note:

Condition	Word error rate	Character error rate
Clean	20.8%	8.5%
White noise at 15 dB SNR	23.0%	9.3%

That counts spelling variants and "70" against "ستر" as errors, so the text reads better than one wrong word in five suggests. Real voice notes are harder than read sentences.

The failure I worry about most: in a noisy test, "jald rihaa" (released quickly) was heard as "jal raha" (burning), and every model I tried, including the 70B and 120B ones, then translated the sentence as hostages being set on fire. A recognition slip becomes an alarming English sentence. The prompt now tells the model not to invent dramatic meanings, but the honest fix is in the interface: every result says it is a machine transcript and to check money, medicine, addresses and times against the audio. The method and examples are on the accuracy page.

Try it

sunlo.appin60.com is free, needs no account, and handles notes up to 10 minutes. If you speak Urdu, I would like to hear where it goes wrong: sunlo@appin60.com.

Your Cloudflare Edge Is in the Wrong Country — colo= vs loc= and a 6-Second Page That Became 1 Second

Daanial Farrukh — Tue, 20 Oct 2026 17:42:21 +0000

A presales war story about a slow site behind Cloudflare — the edge location almost nobody checks — and the two-line test I now run before anyone touches the server.

The complaint came in the usual way. “The website is slow. Can you look at the server?”

It was a public-sector portal. The server was in Pakistan. Almost every visitor was in Pakistan. And the site sat behind Cloudflare, because “Cloudflare makes it faster.”

The team had already done the normal things. They checked CPU. They checked memory. They restarted Apache once, just in case.

“The server is fine,” they said. “But the page still takes six seconds.”

I asked one question. “How long does it take if you skip Cloudflare and hit the server directly?”

Silence. Nobody had tried.

So we tried. Same laptop, same browser, same page — pointed straight at the origin IP.

About one second.

Six seconds through Cloudflare. One second without it. Same server, same content, same moment.

“So Cloudflare is slowing us down?”

Not Cloudflare itself. Where Cloudflare was serving them from.

The Trap — The Edge You Never Look At

That’s the trap. A slow site behind a CDN does not show up as a slow server. Every server metric is green, so everyone keeps looking at the server.

The problem was not on the server. It was on the map.

What a Cloudflare “colo” Actually Is

Cloudflare runs data centres all over the world. Each one is called a colo (short for colocation), and each has a three-letter airport code: LHE for Lahore, DXB for Dubai, MCT for Muscat, SIN for Singapore.

The colo is the Cloudflare data centre that your visitor actually talks to. It is not a setting on your site. Cloudflare uses Anycast: the same IP address is announced from every data centre, and the visitor’s internet provider decides — through its own routing — which one the traffic lands on.

When the colo is close to both the visitor and the origin, the path is short:

Visitor (Pakistan) → Cloudflare colo (Pakistan) → Origin (Pakistan)

When the visitor’s provider sends traffic abroad, the same request looks like this:

Visitor (Pakistan) → Cloudflare colo (Oman) → Origin (Pakistan) → Cloudflare colo (Oman) → Visitor (Pakistan)

That is an international round trip for something that should never have left the country. Once is fine. But a modern page is not one request.

This portal’s homepage made about 140 requests — 18 MB, mostly unoptimised images and about 15 separate CSS files. Every small CSS or JS file took 300–600 ms through Cloudflare and about 30 ms direct. Multiply by 140 and the six seconds explain themselves.

This pattern is common where Cloudflare has weak local peering. In Pakistan, visitors on non-Enterprise plans are often served from Muscat, Dubai or Singapore. Cloudflare’s own documentation describes Pakistani traffic being routed to SIN, MCT and DXB, driven by local provider peering and submarine-cable damage.

Where you see it most:

Countries where the main providers do not peer well with Cloudflare locally.
Sites whose origin and audience are in the same country.
Heavy pages with many small, uncached files.

Why the Usual Check Misses It

There are three reasons nobody found it.

First, server monitoring cannot see it. The origin answered every request quickly. CPU, memory and Apache were all healthy, because they were.

Second, the colo is per visitor, not per site. There is no “site colo” in the dashboard. A visitor on one provider may land in Lahore, while a visitor on another lands in Muscat. The person testing from the office may get a different path from the people complaining.

Third, it changes over time. Cloudflare steers traffic for congestion, maintenance and capacity, and its documentation says it may route self-service plans to other data centres when peering is missing or load is high. A test from last month proves nothing about today.

Here’s the part that trips people up: the first instinct is “the cache is not working”. But direct-to-origin has no cache at all — and it was still six times faster. The cost was the route, not the cache.

How to Actually Fix This

Step 1: Read colo= and loc= — the two-line test

Every Cloudflare-proxied site answers on a special path. Open it in the browser of a real visitor, or run:

curl https://example.com/cdn-cgi/trace

Look at two lines:

colo=MCT
loc=PK

loc= is the visitor’s country. colo= is the Cloudflare data centre serving them. In this case: visitor in Pakistan, edge in Muscat, Oman.

If colo= is in the same country as loc= and your origin, the route is fine and the slowness is somewhere else. If it is in another country, keep going.

Plain takeaway: two lines tell you whether your traffic is leaving the country.

Step 2: Time one small file both ways

Pick a small static file, like a CSS file. Time it through Cloudflare:

curl -s -o /dev/null -w "connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://example.com/wp-includes/css/dist/block-library/style.min.css

Then time the same file directly from the origin. --resolve sends the request to the origin IP while keeping the hostname, so TLS and virtual hosts still work:

curl -s -o /dev/null -w "connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n" --resolve example.com:443:<ORIGIN_IP> https://example.com/wp-includes/css/dist/block-library/style.min.css

Add -k if the origin uses a Cloudflare Origin Certificate, because that certificate is only trusted by Cloudflare.

On this portal the numbers were roughly 500 ms per file through the edge against 30 ms direct. That difference, times 140 files, is the whole problem.

Plain takeaway: if one static file is ten times slower through the edge, the page will be too.

Step 3: Confirm with the full page

One file can lie. A full page cannot. Point your own machine at the origin with a hosts-file entry:

<ORIGIN_IP>  example.com

On Windows it lives in C:\Windows\System32\drivers\etc\hosts, on Linux and macOS in /etc/hosts. Load the page with DevTools open (Network tab, cache disabled) and note the total load time. Remove the line and load it again through Cloudflare.

This step is where most tutorials stop and where mine starts. Remember to delete the hosts entry afterwards — otherwise you will keep testing the origin and wonder why the “fix” worked only for you.

Our result: about 1 second direct, about 6 seconds through the domain.

Step 4: Log CF-Ray to see what real visitors get

The trace shows only your own colo. To see what your visitors get, log the CF-Ray header at the origin. Its value ends with the colo code, for example 8a1b2c3d4e5f6789-MCT.

Check it on one response:

curl -sI https://example.com | grep -i cf-ray

To log it for every visitor, add it to the access log format. In nginx the variable is $http_cf_ray; in Apache it is %{CF-Ray}i. After a day, count the codes at the end of each value. If most of your traffic ends in a foreign code, you have your answer from real users, not from one laptop.

Plain takeaway: there is no single site colo — measure it across real visitors.

Step 5: Choose the fix — and be honest about the trade-off

You cannot force the colo on a normal plan. Only the Enterprise plan can pin traffic to the nearest data centre. So the choices are these:

Option A — cache static files at the edge. This removes the colo → origin leg for cached files. It does not remove the visitor → colo leg, so a foreign colo is still slower than local direct traffic. Worth doing anyway.

Option B — make the page lighter. Combine the 15 CSS files, compress the 18 MB of images, cut the request count. Fewer round trips means less damage from each slow one. Worth doing anyway, too.

Option C — DNS-only (grey cloud). In the Cloudflare dashboard, go to DNS → Records, edit the record and switch Proxy status from Proxied to DNS only. Visitors then go straight to the origin over the local network.

This customer chose Option C for a domestic audience. It is the fastest, but it is a real trade:

Cloudflare’s DDoS protection and WAF no longer sit in front of the site.
The origin IP is now public in DNS.
The origin must already have a publicly trusted certificate. A Cloudflare Origin Certificate will give every visitor a browser error.

Check the certificate before you flip the switch:

openssl s_client -connect <ORIGIN_IP>:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

If the issuer is a public authority like Let’s Encrypt or Sectigo and the dates are valid, you are safe. If it says Cloudflare Origin, fix the certificate first.

Step 6: Verify the switch

After the change, the domain must resolve to the origin, not to Cloudflare:

nslookup example.com

You should see your origin IP. If you still see Cloudflare addresses, wait for the old DNS record to expire and test again.

Then the trace must disappear:

curl -I https://example.com/cdn-cgi/trace

A 404 here is good news. This error is not a bug. It is the verification. The path only exists on Cloudflare, so a 404 proves traffic no longer passes through it.

Finally, load the full page again from a normal visitor connection. Our portal went from about 6 seconds to about 1 second, with no browser certificate warnings.

Step 7: Re-protect the origin — the step people skip

Here is the reversal nobody warns you about. Many hardening guides tell you to lock port 443 so it only accepts Cloudflare’s IP ranges. That is correct when the site is proxied. After going DNS-only, that same rule blocks every real visitor, because they now arrive from their own IPs.

So the protection has to move to the origin: the server firewall, connection limits, rate limiting, and fail2ban or CSF for abuse. Plan that the same day you grey-cloud the record, not after the first attack.

The Bigger Lesson — A Short Checklist

Edge location — curl https://example.com/cdn-cgi/trace, compare colo= with loc=.
Edge vs direct, one file — the two curl -w timings above.
Edge vs direct, full page — hosts-file test with DevTools.
Real visitor colos — log CF-Ray and count the colo codes.
Page weight — DevTools Network tab: request count and total MB.
Origin certificate — the openssl s_client check before any grey-cloud.
Origin firewall after DNS-only — no Cloudflare-only rule left on 443.

What I Tell Every Customer Now

A CDN is a promise about distance. It only keeps that promise if the edge is close to the people using it.

So before anyone opens top on a “slow server” behind Cloudflare, I ask one question:

“Which colo are your visitors actually landing on?”

If the answer is a city in their own country, they’re in good shape, and we go back to the server. If the answer is “What’s a colo?”, we’re not done yet.

I write about the questions I ask in real customer rooms — the ones that change architectures and surface the problems no one else noticed. If you found this useful, drop your email below and I’ll send the next one when it’s ready.

FAQs

Why is my website slower with Cloudflare than without it?

The most common reason is the route. If your visitors are served by a Cloudflare data centre in another country while your server is in their own country, every uncached request makes an international round trip. Compare colo= and loc= at /cdn-cgi/trace to check.

What do colo and loc mean in Cloudflare’s cdn-cgi/trace?

colo is the three-letter airport code of the Cloudflare data centre that served your request, such as MCT for Muscat. loc is the country Cloudflare thinks you are in. If they are in different countries, your traffic is leaving the country before it reaches your site.

Can I choose which Cloudflare data centre serves my visitors?

Not on the Free, Pro or Business plans. Cloudflare uses Anycast, so the visitor’s internet provider decides which data centre their traffic reaches. Only the Enterprise plan can pin traffic to the closest data centre.

Will caching fix a slow Cloudflare colo?

Partly. Caching static files removes the trip from the colo to your origin, but the visitor still has to reach the distant colo. Caching and a lighter page reduce the damage; they do not make a foreign edge as fast as a local direct path.

Is it safe to switch a Cloudflare record to DNS only?

It is safe if you accept the trade-offs and prepare for them. You lose Cloudflare’s DDoS protection and WAF, your origin IP becomes public, and the origin needs a publicly trusted certificate. Also remove any firewall rule that only allows Cloudflare IPs, or real visitors will be blocked.

How do I see which Cloudflare colo my real visitors use?

Log the CF-Ray request header at your origin. Its value ends with the colo code. In nginx use $http_cf_ray, in Apache use %{CF-Ray}i, then count the codes across a day of traffic.

Download the PDF

Originally published at quabin.com.

My CDN Comparison: Cloudflare vs Fastly vs BunnyCDN for Business

Veduis — Tue, 20 Oct 2026 16:47:41 +0000

Content delivery networks have become key infrastructure for any business with a web presence. I've seen CDNs cache content at edge locations worldwide, reducing latency for global users and protecting origin servers from traffic spikes. The difference between a well-configured CDN and none can mean seconds of load time and significant conversion impact.

Choosing between CDN providers involves trade-offs between performance, features, ease of use, and cost. In this comparison, I examine three leading options that serve different segments of the market: Cloudflare's thorough platform, Fastly's developer-focused edge computing, and BunnyCDN's cost-effective simplicity.

How CDNs Improve Performance

Before comparing providers, I find that understanding CDN mechanics helps evaluate their differences meaningfully.

Edge caching - CDNs store copies of static assets at servers distributed globally. Users download files from nearby edge locations rather than distant origin servers.
Connection improvement - CDNs maintain improved connections to origins and use protocols like HTTP/3 to accelerate delivery.
Compression - Automatic compression of text assets reduces transfer sizes.
Image improvement - Many CDNs transform images on the fly, serving appropriate formats and sizes.
DDoS protection - Distributed infrastructure absorbs attack traffic before it reaches origins.
SSL/TLS termination - CDNs handle encryption at the edge, reducing origin server load.

The performance impact depends on visitor distribution and content characteristics. Sites with global audiences and substantial static content see the largest improvements.

Cloudflare: The Thorough Platform

I frequently recommend Cloudflare, which has evolved from a CDN into a thorough edge platform. The free tier makes it accessible to sites of any size, while enterprise features serve the largest properties.

Performance Characteristics

Cloudflare operates one of the largest networks with points of presence in over 300 cities. This density ensures most users connect to nearby edge servers.

Benchmark results (median values):

Time to first byte: 45ms (cached content)
Global latency variance: Low
Cache hit ratio: Depends on configuration
HTTP/3 support: Full

Cloudflare's Argo Smart Routing improves paths between edge and origin, improving performance for dynamic content that cannot be cached. This feature adds cost but delivers measurable latency reduction.

Key Features

Security suite:

Web Application Firewall with managed rulesets
DDoS protection included at all tiers
Bot management and rate limiting
Zero Trust access controls

Performance features:

Automatic image improvement (Polish, Mirage)
JavaScript and CSS minification
Rocket Loader for deferred JavaScript
Early Hints for faster page loads

Developer platform:

Workers for edge compute (JavaScript/WASM)
Workers KV for edge storage
Durable Objects for stateful edge applications
Pages for static site hosting

DNS:

Authoritative DNS included
Fast propagation globally
DNSSEC support

Pricing Structure

Cloudflare's pricing favors small to medium sites:

Tier	Monthly Cost	Notable Features
Free	$0	Basic CDN, DDoS, SSL
Pro	$20	WAF, image improvement, mobile improvement
Business	$200	Custom SSL, advanced analytics, 100% uptime SLA
Enterprise	Custom	Custom solutions, dedicated support

Bandwidth is unmetered on all plans, a significant advantage for high-traffic sites. Additional features like Argo, Workers, and Images carry usage-based charges.

Best Suited For

I recommend Cloudflare for:

Sites needing CDN plus security in one solution
Developers building edge applications with Workers
Organizations wanting thorough platform without multiple vendors
Budget-conscious sites benefiting from free tier

Considerations

Advanced features have learning curve
Some improvements require paid tiers
Enterprise features priced for larger budgets
Support quality varies by tier

Fastly: Developer-Focused Edge Computing

I also work frequently with Fastly, which positions itself as the edge cloud platform for developers. The focus on programmability and real-time capabilities attracts engineering-driven organizations.

Performance Characteristics

Fastly prioritizes performance consistency over network size. Fewer points of presence than Cloudflare, but each location offers substantial capacity.

Benchmark results (median values):

Time to first byte: 38ms (cached content)
Cache purge propagation: Under 150ms globally
Cache hit ratio: High with proper configuration
HTTP/3 support: Full

Fastly's instant purge capability stands out. Cache invalidation propagates globally in milliseconds rather than seconds or minutes, enabling aggressive caching strategies for dynamic content.

Key Features

Edge compute:

Compute@Edge running WebAssembly
VCL (Varnish Configuration Language) for cache logic
Real-time log streaming
Edge dictionaries for dynamic configuration

Performance:

Image Optimizer with on-demand transformation
Streaming media delivery
Origin Shield for reduced origin load
Request collapsing for efficiency

Security:

Next-Gen WAF with behavioral detection
DDoS protection
TLS at edge
Rate limiting and bot detection

Observability:

Real-time analytics
Log streaming to multiple destinations
Custom metrics and dashboards

Pricing Structure

Fastly uses consumption-based pricing:

Component	Rate
Bandwidth	$0.08–0.28/GB depending on region
Requests	$0.0075/10,000 requests
Compute@Edge	Based on execution time
Image Optimizer	Per transformation

No free tier exists, but the pay-as-you-go model works well for sites with moderate traffic. High-traffic sites negotiate custom rates.

Best Suited For

I recommend Fastly for:

Engineering teams wanting granular cache control
Media companies with streaming and instant invalidation needs
Organizations requiring real-time analytics
Applications with complex edge logic requirements

Considerations

No free tier increases barrier to entry
VCL has steep learning curve
Higher cost than alternatives for basic use cases
Smaller network than some competitors

BunnyCDN: Cost-Effective Simplicity

For budget-conscious clients, I often suggest BunnyCDN, which offers straightforward CDN services at aggressive pricing. The focus on simplicity and value attracts cost-conscious users.

Performance Characteristics

BunnyCDN operates a growing network with coverage across major regions. Performance competes with larger providers in most locations.

Benchmark results (median values):

Time to first byte: 52ms (cached content)
Global coverage: Good, some gaps in emerging markets
Cache hit ratio: High
HTTP/3 support: Full

Performance trails Cloudflare and Fastly slightly in some regions but remains competitive for most use cases.

Key Features

CDN Core:

Pull zones for standard CDN
Storage zones for origin hosting
Perma-Cache for permanent caching
Edge Rules for basic customization

Improvement:

Bunny Optimizer for image transformation
Automatic WebP/AVIF conversion
Lazy loading injection
Minification

Video:

Bunny Stream for video hosting
Adaptive bitrate streaming
Video transcoding
Player embedding

Security:

Basic DDoS protection
Token authentication
Hotlink protection
Geographic restrictions

Pricing Structure

BunnyCDN offers the lowest entry point:

Component	Rate
Bandwidth (Volume tier)	$0.01/GB and up
Bandwidth (Standard)	$0.03–0.06/GB by region
Storage	$0.01/GB/month
Bunny Stream	$0.005/minute encoded + bandwidth

Monthly minimum is just $1. The low cost makes experimentation and small sites economically viable.

Best Suited For

I recommend BunnyCDN for:

Cost-sensitive sites and projects
Simple CDN needs without complex edge logic
Video hosting and streaming applications
Developers wanting affordable testing environments

Considerations

Feature set less thorough than larger competitors
Security features more basic
Smaller support team
Less suitable for complex enterprise requirements

Head-to-Head Comparison

Here's how I compare these providers across key dimensions.

Performance Comparison

Metric	Cloudflare	Fastly	BunnyCDN
Network Size	300+ cities	90+ cities	100+ cities
Avg TTFB	45ms	38ms	52ms
Purge Speed	30 seconds	150ms	5 seconds
HTTP/3	Yes	Yes	Yes

Fastly leads on purge speed, critical for sites with frequently changing content. Cloudflare's massive network provides the best coverage. BunnyCDN offers competitive performance at lower cost.

Feature Comparison

Feature	Cloudflare	Fastly	BunnyCDN
Edge Compute	Workers (JS/WASM)	Compute@Edge (WASM)	Edge Rules (basic)
WAF	Included (Pro+)	Add-on	Basic
Image Improvement	Yes	Yes	Yes
Video Streaming	Stream product	Native support	Bunny Stream
DDoS Protection	Included	Included	Basic
Free Tier	Yes	No	No

Cloudflare and Fastly offer comparable feature depth. BunnyCDN provides key parts at lower cost but lacks advanced capabilities.

Cost Comparison (100TB/month bandwidth)

Provider	Estimated Monthly Cost
Cloudflare Pro	$20 (unmetered)
Cloudflare Business	$200 (unmetered)
Fastly	$2,000–5,000
BunnyCDN	$500–1,000

Cloudflare's unmetered pricing dramatically favors high-bandwidth sites. Fastly commands premium pricing for premium features. BunnyCDN offers middle ground value.

Ease of Use Comparison

Aspect	Cloudflare	Fastly	BunnyCDN
Setup Time	Minutes	Hours	Minutes
Learning Curve	Moderate	Steep	Low
Documentation	Extensive	Extensive	Good
Dashboard UX	Clean	Technical	Simple

BunnyCDN and Cloudflare excel at quick setup. Fastly requires more technical investment but rewards it with control.

My Implementation Recommendations

For Small Business Websites

My Recommendation: Cloudflare Free or Pro

The free tier provides substantial value with no financial risk. Upgrading to Pro adds image improvement and WAF for modest cost. Unmetered bandwidth eliminates surprise bills.

For E-Commerce Sites

My Recommendation: Cloudflare Business or Fastly

E-commerce requires reliability and security. Cloudflare Business provides SLA guarantees and advanced security. I suggest Fastly for sites needing instant cache purge for inventory and pricing updates.

For Media and Publishing

My Recommendation: Fastly or BunnyCDN

Media companies benefit from Fastly's streaming capabilities and real-time invalidation. I find budget-conscious publishers appreciate BunnyCDN's pricing for high-bandwidth content.

For Development and Testing

My Recommendation: BunnyCDN

Low minimums and simple pricing suit development environments. The cost of experimentation remains negligible.

For Enterprise Applications

My Recommendation: Cloudflare Enterprise or Fastly

Enterprise needs justify premium pricing for dedicated support, custom configurations, and SLA guarantees. Choice depends on whether edge compute or thorough platform matters more.

Migration Considerations

When I help clients switch CDN providers, planning is key:

DNS changes - Point records to new CDN endpoints. Plan for propagation time.
SSL certificates - Ensure certificates are configured on new provider before cutover.
Cache warming - New CDN caches start empty. Traffic initially hits origin servers harder.
Configuration parity - Recreate cache rules, security settings, and improvements on new platform.
Testing - Verify functionality with a portion of traffic before full migration.
Rollback plan - Maintain ability to revert if issues emerge.

In my experience, CDN selection significantly impacts web application performance, security, and operating costs. Each provider serves different needs effectively. I've found that matching provider strengths to specific requirements leads to better outcomes than chasing benchmark numbers or feature lists alone.

Benchmarking OpenWA: WhatsApp Gateway Throughput, Memory Overhead, and p99 Latency Under Load

Nathan Cross — Tue, 20 Oct 2026 13:34:11 +0000

Benchmarking OpenWA: WhatsApp Gateway Throughput, Memory Overhead, and p99 Latency Under Load

When evaluating self-hosted WhatsApp API gateways for production traffic, raw feature lists tell you nothing about operational cost or failure modes. I needed concrete numbers: how many concurrent sessions can a single OpenWA instance handle before memory balloons or latency spikes? What's the realistic message throughput before Node.js event loop stalls kick in?

Test Topology

I deployed rmyndharis/OpenWA on a 4-core, 8GB VM running Node.js 20.11. The harness:

Load generator: k6 ramping from 50 to 500 virtual users over 10 minutes
Message pattern: Each VU sends 1 text message per second via REST API (POST /message/text)
Session lifecycle: Persistent WhatsApp Web sessions (QR auth once, reused for duration)
Monitoring: Prometheus + Grafana tracking heap usage, event loop lag, and API response times

Key configuration in wrangler.jsonc for the Cloudflare Workers proxy layer:

{
  "name": "openwa-proxy",
  "main": "src/index.ts",
  "compatibility_date": "2024-01-15",
  "vars": {
    "OPENWA_ENDPOINT": "https://internal-openwa.example.com"
  },
  "kv_namespaces": [
    { "binding": "SESSION_CACHE", "id": "abc123" }
  ],
  "routes": [
    { "pattern": "api.example.com/whatsapp/*", "zone_name": "example.com" }
  ]
}

This Cloudflare Workers proxy caches session tokens in KV and routes validated requests to the internal OpenWA instance, keeping authentication logic at the edge.

Metric Comparison Table

Concurrency	Throughput (msg/s)	p95 Latency (ms)	p99 Latency (ms)	Heap Usage (MB)	Event Loop Lag (ms)
50 sessions	48.2	142	189	1,240	3.1
200 sessions	187.5	267	412	3,890	8.7
500 sessions	421.3	531	1,203	7,120	24.5

Failure threshold: At 550+ concurrent sessions, heap allocation errors started appearing (JavaScript heap out of memory). The Node.js process consumed 7.8GB before OOM kill.

Production Threshold Analysis

For environments handling under 300 concurrent WhatsApp sessions, a single OpenWA instance on 8GB RAM stays within safe operational boundaries (p99 < 500ms, heap < 50% of available memory). Beyond that, horizontal scaling becomes mandatory.

The edge proxy pattern with Cloudflare Workers adds negligible latency overhead (median +12ms for KV session lookups) while preventing direct exposure of the OpenWA instance. This architecture proved effective when integrating rmyndharis/OpenWA into a customer support automation pipeline serving 180 agents.

Implementation: Hono.js Validation Layer

The Workers proxy uses Hono.js to validate message payloads before forwarding to OpenWA:

import { Hono } from 'hono';
import { z } from 'zod';
import { zValidator } from '@hono/zod-validator';

const app = new Hono();

const messageSchema = z.object({
  to: z.string().regex(/^\d{10,15}$/),
  body: z.string().min(1).max(4096),
  session: z.string().uuid(),
});

app.post(
  '/whatsapp/message/text',
  zValidator('json', messageSchema),
  async (c) => {
    const { to, body, session } = c.req.valid('json');
    const sessionToken = await c.env.SESSION_CACHE.get(session);

    if (!sessionToken) {
      return c.json({ error: 'Invalid session' }, 401);
    }

    const response = await fetch(`${c.env.OPENWA_ENDPOINT}/message/text`, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${sessionToken}`,
      },
      body: JSON.stringify({ to, body }),
    });

    return c.json(await response.json(), response.status);
  }
);

export default app;

This validation layer blocked 14% of malformed requests during testing before they reached the OpenWA backend, reducing wasted processing cycles.

Memory Pressure Root Cause

The primary bottleneck at high concurrency is Puppeteer's Chrome instances. Each WhatsApp Web session spawns a headless browser context. At 500 sessions, the combined Chrome processes consumed 6.2GB. The Node.js heap itself stayed under 1.2GB.

Two mitigation strategies:

Session pooling: Reuse browser contexts across multiple logical sessions when message volume per session is low
Vertical pod autoscaling: Kubernetes HPA scaling based on aggregate Chrome RSS memory rather than CPU

When testing rmyndharis/OpenWA under sustained load, connection pool exhaustion to the upstream PostgreSQL session store caused cascading timeouts after 4 hours. Switching to a dedicated read replica for session lookups resolved the bottleneck.

Architectural Fit

OpenWA makes economic sense when:

You need persistent WhatsApp sessions (not ephemeral message bursts)
Your traffic patterns are under 400 concurrent sessions per node
You can tolerate p99 latencies in the 500-1200ms range under load
You require full message history access and advanced WhatsApp Business API features without vendor lock-in

For burst-heavy workloads (e.g., scheduled broadcast campaigns with 10k messages in 60 seconds), a different architecture optimized for ephemeral sessions performs better. But for steady-state conversational automation with persistent agent sessions, the benchmark numbers justify deployment.

How I built a 7,800-page nutrition site with Astro and Cloudflare Pages

Miyuru Lakshitha — Tue, 20 Oct 2026 13:16:12 +0000

A few weeks ago I wanted a simple answer: how much protein is in 100 g of cooked lentils? The top results were slow, covered in ads, or hid the numbers behind an app download. The data itself is public. The USDA publishes lab-measured nutrition values for thousands of foods for free.

So I built Nutrinfo: one fast page per food, generated straight from USDA data, plus a few calculators and an AI meal analyzer. This post covers how it is put together, with the real code.

The stack

Astro for static generation, with output: 'static'
Cloudflare Pages for hosting, with one Pages Function for the AI endpoint
GitHub Actions to build and deploy on every push to main
USDA FoodData Central, SR Legacy as the data source (7,793 foods, up to 150 nutrients each)

No database and no server. Every food page is plain HTML on Cloudflare's edge.

Step 1: turning a 200 MB JSON file into site data

USDA ships SR Legacy as one large JSON file. A Node script reads it once and writes two compact files:

src/data/foods.json with the nutrients Astro needs at build time
public/search-index.json, a tiny array-of-arrays index for client-side search

The interesting parts are the slugs and the serving sizes:

const slugify = (s) =>
  s.toLowerCase()
    .normalize('NFKD').replace(/[\u0300-\u036f]/g, '')
    .replace(/%/g, ' percent ')
    .replace(/&/g, ' and ')
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/^-+|-+$/g, '')
    .slice(0, 90)
    .replace(/-+$/, '');

// Duplicate names exist in USDA data, so fall back to the FDC ID.
let slug = slugify(name);
if (seen.has(slug)) slug = `${slug}-${f.fdcId}`;

USDA also publishes household measures ("1 cup, sliced", "1 medium") with gram weights, so each page gets a serving picker for free.

The search index stores each food as [slug, name, kcal, protein, carbs, fat, categoryIndex]. For 7,793 foods that is about 1 MB, small enough to fetch once and search in the browser with no backend.

Step 2: one Astro page per food

Astro's getStaticPaths does the heavy lifting:

---
import { foods } from '../../lib/data.mjs';

export function getStaticPaths() {
  return foods.map((food) => ({ params: { slug: food.slug }, props: { food } }));
}
const { food } = Astro.props;
---

Each page has a nutrition label, a calorie breakdown, the full nutrient tables with % Daily Value, a comparison against the category average, and links to similar foods. You can see one here: bananas, raw.

A full build produces about 7,860 pages and takes around five minutes. That is fine for a site where the data changes rarely.

Pages that are not thin

The risk with programmatic pages is that 7,800 near-identical templates get ignored by search engines. Every page computes things that are specific to that food:

a short summary sentence ("It is an excellent source of vitamin C (98% DV)...")
how it compares to its category average, in percent
an FAQ block answering calories, protein, carbs and micronutrients in 30 to 50 words, which is the format featured snippets and AI answer engines pick up
"alternatives" from the same category with more protein for similar calories, or fewer calories

There are also "foods high in X" ranking pages, like foods high in iron, which link down to the food pages. That gives the site a clear hub-and-spoke structure instead of 7,800 orphans.

Step 3: an AI meal analyzer on a Pages Function

Static pages are great for single foods, but people eat meals. The AI meal analyzer takes a text description or a photo and returns an estimate as structured JSON.

It runs as a Cloudflare Pages Function at functions/api/ai.js. Text goes to a model on Groq, photos go to Gemini, and Gemini also acts as the fallback. The system prompt asks for strict JSON matching a schema:

const MEAL_SCHEMA = `{
  "items": [{ "name": string, "portion": string, "grams": number, "kcal": number, "protein": number, "carbs": number, "fat": number }],
  "total": { "kcal": number, "protein": number, "carbs": number, "fat": number },
  "score": number,
  "summary": string,
  "tips": [string]
}`;

The part I am happiest with is rate limiting without any extra service. The Cache API is available in every Pages Function, so it doubles as a best-effort counter:

async function rateLimited(ip) {
  const cache = caches.default;
  const now = Date.now();
  const windows = [
    { key: `m/${Math.floor(now / 60_000)}`, max: 8, ttl: 60 },
    { key: `d/${Math.floor(now / 86_400_000)}`, max: 60, ttl: 86_400 },
  ];
  for (const w of windows) {
    const req = new Request(`https://rl.nutrinfo.internal/${encodeURIComponent(ip)}/${w.key}`);
    const hit = await cache.match(req);
    const count = hit ? parseInt(await hit.text(), 10) || 0 : 0;
    if (count >= w.max) return true;
    await cache.put(req, new Response(String(count + 1), { headers: { 'cache-control': `max-age=${w.ttl}` } }));
  }
  return false;
}

It is per data center, not global, so it is not exact. For keeping a free tool from being drained by one script, it is enough, and it needs no KV, D1 or Durable Object.

Step 4: deploying 270 MB of HTML

Uploading the whole dist/ folder from a home connection was slow, so the build moved to GitHub Actions:

- run: npm ci
- run: npm run build
- run: npx wrangler pages deploy dist --project-name nutrinfo --branch main --commit-hash ${{ github.sha }}
  env:
    CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

Wrangler only uploads files whose hash changed, so later deploys are much faster than the first one.

Step 5: the SEO plumbing

Getting 7,800 URLs discovered matters as much as building them.

Split sitemaps. @astrojs/sitemap supports chunks, so foods, list pages and everything else get separate sitemaps. Search Console then reports index coverage per section, which tells you quickly if the food pages are being skipped.

sitemap({
  chunks: {
    foods: (item) => (new URL(item.url).pathname.startsWith('/food/') ? item : undefined),
    lists: (item) => (/^\/(category|high-in)\//.test(new URL(item.url).pathname) ? item : undefined),
  },
}),

IndexNow. Bing, Yandex and others accept IndexNow pings. A small script reads the built sitemaps and posts URLs in batches of 10,000, and the deploy workflow has an optional input to run it for given path prefixes.

One gotcha cost me a run: triggering the workflow from Git Bash on Windows with -f indexnow=/methodology/ silently turned the input into C:/Program Files/Git/methodology/. The run succeeded and submitted zero URLs. MSYS_NO_PATHCONV=1 fixes it.

Structured data. Each food page has WebPage (with isBasedOn pointing at the USDA dataset), BreadcrumbList and FAQPage JSON-LD.

Step 6: performance fixes from an audit

An SEO audit flagged a few things I had missed:

Render-blocking fonts. Google Fonts CSS blocked the first paint. I self-hosted the latin subsets of Inter and Fraunces as variable woff2 files and preloaded them.
Render-blocking CSS. The whole stylesheet is about 6 KB, so build.inlineStylesheets: 'always' inlines it into every page. No stylesheet request at all.
Missing HSTS and favicon.ico. Both are a one-line fix in _headers and a generated icon set.

On real visits, Cloudflare Web Analytics shows 86% of page loads with a good Largest Contentful Paint.

Where it is now

The site is about a week old. Search engines are crawling it, a handful of real people visit each day, and most pages are still waiting to be indexed. I will write a follow-up with real numbers once Search Console has something to say.

What I would do differently: plan the internal linking and the "foods high in" pages from day one instead of adding them after launch. They are the pages people actually link to.

If you want to look around, it is at nutrinfo.net. Feedback on the data pages or the meal analyzer is very welcome, especially if a number looks wrong. Every page links to its USDA source, so it is easy to check.

Selling APIs to AI agents with x402: 69 endpoints, Cloudflare Workers, zero API keys

Mohamed Arafa — Tue, 20 Oct 2026 12:48:53 +0000

The pitch

An AI agent needs the EUR/EGP rate. It calls GET /v1/fx/EUR. The server answers 402 Payment Required with a price ($0.01) and a wallet. The agent signs a USDC transfer on Base, retries with an X-PAYMENT header, gets JSON. No signup, no API key, no invoice. That's x402.

I spent two nights building three services on top of it, all on Cloudflare Workers.

What's live

WorldData402 — 39 data endpoints: FX for 160+ currencies, historical rates, SEC company filings, EU public tenders, World Bank indicators, EU VAT validation, public holidays, geocoding, weather, air quality, earthquakes, Wikipedia, arXiv, Crossref, RDAP, DNS, npm/PyPI, barcodes. $0.01–$0.05 per call.

Inference402 — 15 endpoints on Cloudflare Workers AI: chat (small/large), structured JSON output, summarize, translate (plus an Arabic-tuned route that handles Egyptian dialect), extract, classify, sentiment, keywords, rewrite, embeddings, moderation, image description, Whisper transcription. $0.002–$0.02.

Briefs402 — 10 composite reports (company, country, market, tenders, domain due-diligence, location, research literature, product, package risk, long-document translation). It calls the other two internally and sells the finished brief for $0.10–$0.50.

Stack

Hono + @x402/hono for the paywall
PayAI facilitator (no account needed, 1,000 free settlements, then ~$0.002 each)
Cloudflare Workers AI for models (10k neurons/day free, then $0.011 per 1k)
One catalog.js per service generates routes, /.well-known/x402, /openapi.json and SKILL.md
Settlement happens only after a 2xx response, so failed calls are never charged

Things that bit me

x402.org/facilitator is testnet-only. For Base mainnet you need CDP (needs KYC) or PayAI/Mogami (no account).
x402scan needs /.well-known/x402 plus an OpenAPI with an input schema on every paid route, or it won't list the route.
Several US government APIs (Treasury, USAspending) refuse Cloudflare Workers egress IPs with TLS failures. GDELT rate-limits the whole Workers IP pool.
RapidAPI shows operationId as the endpoint name, not summary.

Distribution

x402scan: all three listed
Circle Agent Marketplace: submitted
RapidAPI (card payments, free tier): https://rapidapi.com/MohamedArafa/api/worlddata402 and https://rapidapi.com/MohamedArafa/api/inference402
MCP server for Claude Desktop / Claude Code / Cursor: npx -y worlddata402-mcp — all 69 endpoints as tools, paid from a small wallet via WALLET_PRIVATE_KEY

Honest status

48 hours live, ~2k requests (all mine), 0 paid calls. Supply is done. If you've sold to agents and found what drives discovery, I'd like to hear it.

HTTP 402 and x402: three places a payment breaks

Georgi Kalchev — Tue, 20 Oct 2026 07:01:08 +0000

Got an HTTP 402 and the x402 payment still fails? Three checks, one per hop: the seller's offer, the signed header, the receipt on Base. Real outputs inside.

If an HTTP 402 answer arrived and your x402 payment still fails, the fault sits in one of three places, in this order: the seller's offer (the 402 answer itself), the signed PAYMENT-SIGNATURE header your client sends back, or the receipt on Base after settlement. Each hop can fail without any error message, and a plain curl shows only the first one. Below, we take the hops one at a time, show what goes wrong silently, and show what our three small paid checks return for each. We ran all of them on 16 October 2026.

Read the full report on AISkills402: https://aiskills402.com/blog/http-402-x402-payment-checks?utm_source=devto&utm_medium=social

Cloudflare Launches Clairic, a Fast System One Extraction Model for Typed Values

TechPulse — Tue, 20 Oct 2026 03:36:44 +0000

Cloudflare on October 19, 2026, announced a preview of Clairic, its first System One extraction model, now available on Workers AI as @cf/cloudflare/clairic. Unlike conventional large language models that generate text token by token, Clairic processes inputs in a single forward pass and returns structured, typed values such as numbers, dates, lists, estimates and forecasts, each with confidence scores. The company says the approach delivers higher accuracy, lower latency and lower cost for extraction-heavy tasks, and it plans to release open weights later. [1] [2]

What Clairic does differently

System One models, inspired by Daniel Kahneman’s distinction between fast intuitive thinking and slow deliberate reasoning, prioritize speed and precision over open-ended generation. Clairic sits alongside Cloudflare’s earlier decision model Clef. Where Clef chooses among predefined options and returns probabilities, Clairic extracts or computes values that cannot be listed in advance—an invoice total, a delivery date, the number of days a shipment is late, or a repair-cost estimate. [1]

A request consists of a state (text, optionally plus up to four images) and a schema of typed fields. Supported types include text spans with character offsets, numbers (with decimal control), dates/times/datetimes, durations, lists, estimates (with median and 80% interval) and forecasts (up to 64 future steps). Every scalar answer includes a p_null probability that the input does not determine the value; when that probability is high the model returns null rather than guessing. Field count is effectively unlimited because the service splits large schemas across parallel passes. [2]

Pricing is $0.10 per million input tokens with no output-token charge, reflecting the single-pass design. Context window is 65,536 tokens and vision support is included. Cloudflare documents that one- and two-step arithmetic (totals, differences, date math) is reliable, while long chains of dependent calculations are better handled by extracting inputs with Clairic and finishing the math in code. [2]

Early results and cascade potential

In a 21-day TSA checkpoint travel-volume forecast that used the prior 90 days of data, Clairic’s median predictions showed an average absolute error of 3.3 percent; 17 of the 21 actual daily counts fell inside the model’s 80 percent prediction interval. The model recovered the weekly pattern (quieter Tuesdays and Saturdays, busier Thursdays–Sundays) without explicit calendar features. [1]

Cloudflare also published an internal damage-claim pipeline comparison. A cascade of Clairic (extraction) → Clef (decision) → GLM-5.3 (reply writing) finished in 19.3 seconds end-to-end versus 61.7 seconds when every step used GLM-5.3 alone—roughly 3.2× faster and 49 percent cheaper ($6,032 versus $11,740 per million claims). Extraction and decision together took under a second with the specialized models versus 38 seconds with the LLM. These figures are Cloudflare’s own measurements; independent third-party evaluations have not yet been published. [1] [2]

Practical implications

For developers building document-processing, claims, logistics or forecasting workflows, Clairic offers a way to replace expensive, high-latency LLM calls for the structured portion of the pipeline. Because answers are typed and carry explicit confidence and null probabilities, downstream code can route low-confidence results to human review without additional parsing. The ability to chain Clairic with Clef and a conventional LLM creates a clean extract-decide-write pattern that can be cheaper and more consistent run-to-run than an all-LLM stack. [1]

Limitations remain: multi-step arithmetic and complex aggregations are weak, forecasting is described as basic, and confidence intervals can be miscalibrated on data far from the training distribution. The model is still in preview and open weights are not yet available. Organizations evaluating it should therefore test on their own schemas and data distributions before relying on the published cascade numbers. [2]

Clairic illustrates a broader shift toward specialized, non-generative models for the high-volume structured tasks that currently dominate enterprise LLM spend. If the preview performance holds under independent scrutiny and open weights appear, it could accelerate the adoption of hybrid pipelines that reserve large language models for the open-ended reasoning and writing steps where they remain strongest.

Sources

[1] Cloudflare Blog: Introducing Clairic, a new System One class of extraction models
[2] Cloudflare Workers AI documentation: clairic

Anatomy of a Next.js 16 + Cloudflare Edge Outage: Eradicating RSC Flight Payload Cache Poisoning

Duong Phuc Khanh (Kido) — Tue, 20 Oct 2026 03:22:17 +0000

At 09:14 AM on a Monday morning, customer support channels lit up with urgent incident reports:

"The app won't open on iPhone! It's just a blank screen with weird text like :HL["/static/css/..."] and 1:I["$Sreact.fragment"...]."

Users opening the Progressive Web App (PWA) from their iOS Home Screen were greeting by a completely unrendered, raw stream of React Server Component (RSC) Flight protocol wire data. Desktop users performing a hard browser refresh saw the exact same raw JSON-like text instead of HTML.

Yet, our backend health checks showed 100% green. PostgreSQL CPU was resting at 4%, the Node.js process had zero unhandled exceptions, and API latency was under 8ms.

We had fallen victim to RSC Flight Payload Cache Poisoning at the Edge.

I'm Dương Phúc Khánh (known across the engineering community as khanhdp or Kido, @khanhduong22). As Senior AI-Native Lead & Systems Architect, I have documented critical production postmortems across 127 chapters of Kido Chronicles.

In this deep dive, we dissect the root cause of this modern Next.js App Router vulnerability, analyze why intermediate CDN caches collapse without strict header partitioning, and present the 3-Layer Defense Architecture we deployed to permanently eradicate it.

1. The Evolutionary Architecture of Next.js Navigation: HTML vs. Flight Wire Data

To understand how edge cache poisoning occurs, we must trace how Next.js App Router navigates between routes:

Request Type	Trigger	Client Headers	Server Response Format	MIME Content-Type
Full Page Load (Hard Refresh)	User types URL, hard reloads (`Cmd+Shift+R`), or opens PWA	`Accept: text/html,application/xhtml+xml`	Fully rendered HTML document	`text/html; charset=utf-8`
Soft Navigation (Link Transition)	User taps `<Link href="/dashboard">` inside React tree	`Accept: text/x-component` `RSC: 1` `Next-Router-State-Tree: ...`	Serialized React Virtual DOM Flight Stream	`text/x-component`

The Fatal Design Conflict

Notice the architectural reality: Both requests hit the exact same URI pathname (https://khanhdp.com/dashboard)!

When a user first opens /dashboard, Next.js renders the full HTML page with CSS and client script tags.
When an already hydrated user clicks a link to /dashboard, Next.js does not fetch HTML. Instead, its router client issues a background fetch to /dashboard with the HTTP header RSC: 1. Next.js responds with the binary/text Flight stream containing only the updated component tree payload.

The client-side React router receives this Flight stream, deserializes the Virtual DOM, and updates the view without a full page refresh.

2. Anatomy of the Poisoning Incident

Here is the exact step-by-step sequence of how our Cloudflare Edge Cache was poisoned:

sequenceDiagram
    autonumber
    actor MobileUser as User A (Navigating PWA)
    actor NewVisitor as User B (Hard Page Load)
    participant CF as Cloudflare Edge CDN (Cache Key: URI)
    participant NextServer as Next.js 16 Origin Server

    Note over MobileUser,NextServer: Step 1: Soft Navigation triggers RSC Fetch
    MobileUser->>CF: GET /profile (Header: RSC: 1)
    Note over CF: Cache Miss for URI '/profile'
    CF->>NextServer: GET /profile (Forwarding RSC: 1)
    NextServer-->>CF: 200 OK (Content-Type: text/x-component) [Flight Payload]
    Note over CF: Cloudflare caches body under key: 'khanhdp.com/profile' (TTL 4h)!
    CF-->>MobileUser: Returns Flight Payload (React navigates smoothly)

    Note over NewVisitor,CF: Step 2: New Visitor opens URL directly (Fatal Poison!)
    NewVisitor->>CF: GET /profile (Accept: text/html, No RSC header)
    Note over CF: Cache HIT on URI 'khanhdp.com/profile'!
    CF-->>NewVisitor: Returns CACHED Flight Stream (:HL[...]) with Content-Type: text/x-component!
    Note over NewVisitor: Browser cannot render HTML! Displays raw text / Blank Screen!

Why Cloudflare Edge Caches Poisoned the Key

By default, Cloudflare Edge Cache (and most reverse proxies like standard Nginx or Varnish setups) constructs its internal cache key using only:
$$\text{Cache Key} = \text{Scheme} + \text{Host} + \text{URI Path} + \text{Query String}$$

Crucially, request headers like RSC are not part of the default cache key.

When User A clicked a <Link href="/profile">, the edge cache was empty. The request arrived with RSC: 1. The origin Next.js server correctly replied with Content-Type: text/x-component and the Flight stream.

Because our caching rules instructed Cloudflare to cache HTML/document responses for high performance (Cache-Control: public, max-age=3600, s-maxage=14400), Cloudflare stored this Flight stream under the cache key https://khanhdp.com/profile.

Seconds later, User B opened Safari and loaded https://khanhdp.com/profile. Cloudflare detected a cache hit, bypassed the Next.js origin completely, and returned the cached Flight stream!

Because the browser expected HTML but received text/x-component, it either rendered raw unformatted text or choked completely, producing a white screen of death.

3. Why `Vary: RSC` Is Not Enough

Many developers assume adding an HTTP Vary header solves this:

Vary: RSC, Next-Router-State-Tree, Accept

In theory, RFC 7234 dictates that CDNs must partition cached variants when Vary headers differ.

However, in real-world production:

Cloudflare Tier Limitations: Cloudflare's standard caching engine deliberately ignores most Vary headers (except Accept-Encoding) on Free and Pro tiers to prevent cache fragmentation and resource exhaustion.
CDN Normalization: Intermediate proxy layers frequently strip or collapse unknown Vary values.
PWA Service Worker Traps: Even if the CDN respects Vary, local browser Service Workers using Cache.match(request) without { ignoreVary: false } often serve stale variants from disk cache.

Relying solely on Vary is a textbook trap. A multi-layered, defense-in-depth architecture is mandatory.

4. The 3-Layer Defense-in-Depth Architecture

To permanently immunize our infrastructure, Dương Phúc Khánh (khanhdp · Kido) engineered a 3-Layer Defense Architecture:

┌──────────────────────────────────────────────────────────────────┐
│ LAYER 1: Cloudflare Edge Wirefilter (Cache Bypass & Header Key)   │
│ - Bypasses edge cache if `rsc: 1` header is present               │
│ - Partitions custom cache keys by `http.request.headers["rsc"]`   │
├──────────────────────────────────────────────────────────────────┤
│ LAYER 2: Next.js Origin Guard (Middleware & Strict Cache-Control)│
│ - Forces `Cache-Control: private, no-store` on all RSC payloads   │
│ - Restricts public edge caching strictly to HTML documents        │
├──────────────────────────────────────────────────────────────────┤
│ LAYER 3: Client PWA Service Worker Self-Healing Immune System    │
│ - Verifies `Content-Type: text/html` on document navigations     │
│ - Automatically detects and purges poisoned edge responses       │
└──────────────────────────────────────────────────────────────────┘

Layer 1: Cloudflare Edge Wirefilter & Cache Rules

In Cloudflare Dashboard (or via Terraform / Cloudflare API), we deploy two deterministic rules:

Rule 1: Bypass Edge Cache for All RSC Flight Requests

Under Caching > Cache Rules:

Expression: (http.request.headers["rsc"][0] eq "1") or (http.request.uri.path contains "_next/data")
Action: Bypass Cache (Eligible for Dynamic routing only).

Rule 2: Custom Cache Key for Enterprise / Pro Tiers

If you wish to cache RSC payloads separately for extreme speed, configure a Custom Cache Key:

# Terraform configuration for Cloudflare Cache Rule
resource "cloudflare_cache_rule" "partition_rsc_cache" {
  zone_id     = var.cloudflare_zone_id
  name        = "Partition RSC Cache Key"
  description = "Ensures RSC wire payloads never collide with SSR HTML documents"
  expression  = "(http.host eq \"khanhdp.com\")"

  action = "set_cache_settings"
  action_parameters {
    cache = true
    edge_ttl {
      mode    = "respect_origin"
      default = 3600
    }
    custom_cache_key {
      headers {
        include = ["rsc", "next-router-state-tree"]
      }
    }
  }
}

Layer 2: Next.js Origin Middleware Guard

At the origin server level, we enforce a strict policy in middleware.ts: Never allow intermediate CDNs to cache an RSC Flight stream under a public shared directive.

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const isRSC = request.headers.get('rsc') === '1';
  const response = NextResponse.next();

  if (isRSC) {
    // Flight stream: strictly private or non-cacheable at intermediate proxies
    response.headers.set(
      'Cache-Control',
      'private, no-cache, no-store, must-revalidate, max-age=0'
    );
    response.headers.set('X-Content-Type-Options', 'nosniff');
  } else {
    // Standard HTML document: safe for public CDN edge caching
    response.headers.set(
      'Cache-Control',
      'public, max-age=0, s-maxage=3600, stale-while-revalidate=86400'
    );
    response.headers.set('Vary', 'RSC, Next-Router-State-Tree, Accept');
  }

  return response;
}

export const config = {
  matcher: [
    /*
     * Match all request paths except:
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico, sitemap.xml, robots.txt
     */
    '/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)',
  ],
};

Layer 3: Client PWA Service Worker Self-Healing Gate

What if a misconfigured CDN edge or proxy still serves a poisoned payload to an iOS user?

We implement a client-side Self-Healing Immune Gate inside our PWA Service Worker (sw.js). When the browser requests a mode: 'navigate' document, the Service Worker inspects the response headers before committing it to the screen:

// sw.js - Service Worker Immune Gate
self.addEventListener('fetch', (event) => {
  const request = event.request;

  // Intercept navigation requests (user opening the app or clicking links)
  if (request.mode === 'navigate') {
    event.respondWith(
      fetch(request)
        .then((response) => {
          const contentType = response.headers.get('Content-Type') || '';

          // Verify that a document navigation receives genuine HTML
          if (!contentType.includes('text/html')) {
            console.error(
              '[SW Gate] POISONED CACHE DETECTED! Expected text/html, received:',
              contentType
            );

            // 1. Purge all local caches immediately
            caches.keys().then((keys) => {
              keys.forEach((key) => caches.delete(key));
            });

            // 2. Bypass CDN cache with a unique anti-poison query param
            const bypassUrl = new URL(request.url);
            bypassUrl.searchParams.set('__sw_bypass', Date.now().toString());

            return fetch(bypassUrl.toString(), {
              headers: { Accept: 'text/html' },
              cache: 'reload',
            });
          }

          return response;
        })
        .catch((error) => {
          // Offline fallback logic
          return caches.match('/offline.html');
        })
    );
  }
});

If Cloudflare ever returns a text/x-component payload for an HTML navigation request, the Service Worker intercepts it, logs the violation, purges client caches, and refetches with a cache-busting token—restoring the user interface in under 200ms without manual intervention.

5. Production Telemetry & Outage Postmortem Metrics

Since deploying this 3-Layer Defense across Dương Phúc Khánh's production platforms:

Telemetry Metric	During Incident (Pre-Fix)	Post-Implementation	Improvement
White Screen / Poisoned Page Reports	42 incidents / morning	0 incidents	100% Resolved
Edge Cache Hit Ratio (HTML)	`64.2%` (Unstable)	`98.4%`	+34.2% stability
p95 Time To First Byte (TTFB)	`480ms` (Erratic revalidation)	`24ms`	20x faster
Mean Time to Recovery (MTTR)	~45 minutes	`<200ms` (Automated SW recovery)	Instant Self-Healing

6. Key Takeaways for Senior Architects

Never Assume CDNs Differentiate by URI Alone: Modern fullstack frameworks (Next.js, Remix, SvelteKit) multiplex different data protocols over identical URLs. Your edge cache keys must explicitly partition by protocol headers (RSC: 1).
Vary Headers Are a Hint, Not a Guarantee: Cloudflare and intermediate cellular proxies often strip Vary. Always back up HTTP headers with explicit edge cache rules.
Build Client-Side Immune Systems: The client Service Worker is your last line of defense. By verifying Content-Type: text/html on document navigations, you make white-screen crashes mathematically impossible.

About the Author (Tiểu sử tác giả): Dương Phúc Khánh (canonical handle: khanhdp, moniker: Kido) là Kỹ sư Kiến trúc Hệ thống (Senior AI-Native Lead & Systems Architect) tại Đà Nẵng, Việt Nam; cựu Tech Lead 6 năm tại FPT Software (SBI Lab), Quán quân Startup Runway 2018 (ĐH Kinh tế - ĐH Đà Nẵng), tác giả của Winter Arc, Agent Harness Kit và Kido Chronicles. Xem đầy đủ tại Tiểu sử Dương Phúc Khánh & Wikidata Q141718572.

About the Author & Engineering Research

🌐 Official Architecture Hub: Dương Phúc Khánh (khanhdp)
🏛️ Biography & Engineering Timeline: Dương Phúc Khánh (khanhdp · Kido) (Tiểu sử)
🔥 Kido Chronicles (127 Real Production Postmortems): https://truyen.khanhdp.com
💻 Open-Source Multi-Agent Framework: github.com/khanhduong22/agent-harness-kit

5 Cloudflare Free-Tier Tricks I Use to Run My Side Projects

Jianfang Peng — Tue, 20 Oct 2026 02:57:25 +0000

Cloudflare's free tier is, pound for pound, the best deal in web infrastructure. Not "free trial" free — actually free, no card, no gotchas. Here are five things I genuinely run on it for my side projects.

1. Unlimited email addresses on my own domain (Email Routing)

This is the trick most people sleep on. Buy a domain for ~$10/year, add Cloudflare Email Routing, and suddenly shop@mydomain.com, support@mydomain.com, whatever-i-want@mydomain.com all work — forwarded to one real inbox. No mailboxes to pay for, no "5 free aliases" limits.

The setup takes about 10 minutes: verify the domain, add two DNS records (MX + SPF), write routing rules. I use one rule that catches everything not matching a specific address and forwards it to my main Gmail. Services that need a unique address per signup get a unique address. One inbox to rule them all.

2. DNS that isn't a footgun

Registrars ship DNS that's "fine" until it isn't — slow propagation, cryptic errors, no API worth using. Cloudflare DNS is free, fast, and has a real API with tokens you can scope per-zone. Everything lives in one dashboard with an audit log, so when something breaks at 2 AM you can see exactly who changed what.

3. Workers for the glue nobody wants to maintain

Need a tiny JSON API, a redirect service, or a webhook relay? A Cloudflare Worker is a few dozen lines of JavaScript and deploys in seconds. The free tier gives you 100,000 requests/day — more than any side project will touch. No server to patch, no container to restart, no bill.

4. Tunnel: expose localhost without exposing yourself

Developing a webhook integration and need a public URL for localhost:3000? cloudflared tunnel gives you a real HTTPS URL with zero port-forwarding, zero firewall rules, and zero "your home IP is now public" anxiety. It's the cleanest way to demo work-in-progress to a client.

5. Cache everything aggressively (then purge when you must)

The free CDN caches your static assets at 300+ edge locations. The part beginners miss: set real cache rules for images, CSS, and JS, then use "Purge Cache" (or the API) when you deploy. Most side-project slowness is just every request round-tripping to a cheap VPS — the free CDN deletes that problem.

The honest caveat

Free doesn't mean unlimited-everything. Email Routing is forwarding-only (no sending from those addresses without extra setup), Workers has CPU-time limits per request, and the free tier won't hide a genuinely terrible origin server. But for a side project doing normal side-project things, this stack covers DNS, email, glue code, demos, and caching for roughly the price of the domain alone.

Comparing Edge and Serverless: What I Learned Building SaaS

seller-mind — Tue, 20 Oct 2026 02:21:44 +0000

When I first started building SaaS tools, I relied heavily on traditional serverless functions. Everything was fine until I tried to build a real-time SEO analyzer. Fetching external pages, parsing HTML, and returning results from a single central region meant my users in Europe and Asia were staring at loading spinners for several seconds. I tried optimizing the code, minifying the payloads, and tweaking the database queries, but the network latency was the real bottleneck. I realized that if I wanted to build fast, global SaaS tools, I needed to rethink my architecture entirely. So I decided to build something.

The Hidden Cost of Latency in SaaS

In the SaaS world, performance isn't just a nice-to-have; it's a core feature. When you're building tools that interact with external APIs or fetch live data, every millisecond counts. The problem with traditional serverless setups is that they often route all traffic through a single primary region. If your function needs to fetch a webpage to check its meta tags, that fetch travels from the user, to the serverless region, to the target website, and back.

Ignoring this architectural reality means a poor user experience, higher egress costs, and frustrated users. For billing integrations, slow webhook processing can even lead to missed payment events if timeouts occur. I needed an approach that processed data closer to the user, without sacrificing the rich ecosystem I was used to.

Comparing the Approaches: Edge vs. Serverless

This led me to deeply compare edge computing (specifically Cloudflare Workers) against traditional serverless platforms like Vercel or AWS Lambda. The trade-offs between the two are significant, and neither is a silver bullet.

Serverless is fantastic for heavy compute tasks, complex database operations, and has a incredibly mature ecosystem. However, edge computing shines for I/O-bound tasks like fetching web pages, handling lightweight API requests, and serving global users with low latency.

For the SEO checking tool in my SaaS starter kit, I moved the HTML fetching and parsing to the edge. Instead of a central server doing the work, the request hits the nearest edge node. Here is what the edge worker looks like in practice:

// Cloudflare Worker for edge SEO analysis
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname !== '/api/analyze') {
      return new Response('Not found', { status: 404 });
    }

    const targetUrl = url.searchParams.get('url');
    if (!targetUrl) {
      return new Response(JSON.stringify({ error: 'Missing url' }), {
        status: 400,
        headers: { 'Content-Type': 'application/json' },
      });
    }

    // Fetch target page at the edge (low latency worldwide)
    const response = await fetch(targetUrl, {
      cf: { cacheTtl: 300, cacheEverything: true },
    });
    const html = await response.text();

    // Run SEO checks (regex-based, no DOM needed)
    const title = html.match(/<title[^>]*>([^<]*)<\/title>/i)?.[1] || '';
    const desc = html.match(/<meta[^>]*name=["']description["'][^>]*content=["']([^"']*)["']/i)?.[1] || '';
    const h1Count = (html.match(/<h1[ >]/gi) || []).length;

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

The magic here is in the fetch configuration. By passing Cloudflare-specific cf options, we can cache the target page right at the edge for a few minutes. This drastically reduces the load on the target website and speeds up subsequent checks. Furthermore, because we are at the edge, we can't use heavy Node.js libraries like JSDOM. Instead, I used simple regex to extract the title, description, and H1 count. This keeps the worker incredibly lightweight and fast.

But edge computing isn't perfect. You have smaller memory limits and can't use heavy Node.js modules. That's why I adopted a hybrid approach. I kept the heavy Stripe subscription billing logic and NextAuth.js authentication on Next.js 14+ App Router API routes (running on serverless infrastructure), while pushing the I/O-heavy SEO checks to Cloudflare Workers.

Setting up the Stripe checkout in the Next.js serverless environment looks like this:

// Next.js API route for Stripe checkout (App Router)
import { NextResponse } from 'next/server';
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const { priceId, userId } = await req.json();

  const session = await stripe.checkout.sessions.create({
    mode: 'subscription',
    payment_method_types: ['card'],
    line_items: [{ price: priceId, quantity: 1 }],
    success_url: `${process.env.APP_URL}/dashboard?success=true`,
    cancel_url: `${process.env.APP_URL}/pricing?cancelled=true`,
    client_reference_id: userId,
  });

  return NextResponse.json({ url: session.url });
}

By splitting the workload, I get the best of both worlds: robust, ecosystem-rich serverless functions for complex business logic, and blazing-fast edge functions for global, I/O-heavy tasks.

Practical Results and Takeaways

Moving the SEO analysis to the edge drastically reduced the time-to-first-byte for global users. What surprised me was how much simpler the deployment became. By using Cloudflare Workers for the edge APIs and Next.js for the frontend and Stripe webhooks, I could deploy the whole TypeScript-first stack with a single click to either Vercel or Cloudflare Pages.

If I were to change one thing, I'd spend more time upfront designing the caching strategy. Initially, I cached everything aggressively, which meant users sometimes saw stale SEO data when checking a page they had just updated. Tuning the cacheTtl to just a few minutes struck the right balance between performance and data freshness.

Another lesson learned was the importance of full type safety across the boundary. Sharing TypeScript interfaces between the Next.js frontend and the Cloudflare Worker API prevented a lot of integration bugs that usually pop up when mixing different runtime environments.

Try It Yourself

If you're curious about how edge caching and HTML parsing perform in the real world, I put together a free SEO checker using this exact architecture. You can drop in any URL and see the edge-analyzed results instantly, experiencing the low latency firsthand.

You can try the free SEO checker here: https://saaslaunch.dev/free-tools/seo-checker

Full disclosure: I'm the developer of SaaSLaunch. I built this because I needed it myself.

DEV Community: cloudflare

How to Automatically Start a Cloudflare Tunnel When You Sign In to Windows

The problem

Step 1: Create a startup script

Step 2: Configure Windows Task Scheduler

Step 3: Test it

What about running the tunnel before login?

Where this basic approach gets complicated

A ready-made alternative

Urdu voice notes to text on a free tier: Whisper pinned to Urdu, Roman Urdu without drift, and an honest error rate

1. Whisper on Workers AI, language pinned to Urdu

2. A hard daily cap, enforced before the model runs

3. Roman Urdu: transliterate, do not translate

4. Long recordings: cut at silence, in the browser

5. Share target: one tap from WhatsApp

How accurate is it?

Try it

Your Cloudflare Edge Is in the Wrong Country — colo= vs loc= and a 6-Second Page That Became 1 Second

The Trap — The Edge You Never Look At

What a Cloudflare “colo” Actually Is

Why the Usual Check Misses It

How to Actually Fix This

Step 1: Read colo= and loc= — the two-line test

Step 2: Time one small file both ways

Step 3: Confirm with the full page

Step 4: Log CF-Ray to see what real visitors get

Step 5: Choose the fix — and be honest about the trade-off

Step 6: Verify the switch

Step 7: Re-protect the origin — the step people skip

The Bigger Lesson — A Short Checklist

What I Tell Every Customer Now

FAQs

Why is my website slower with Cloudflare than without it?

What do colo and loc mean in Cloudflare’s cdn-cgi/trace?

Can I choose which Cloudflare data centre serves my visitors?

Will caching fix a slow Cloudflare colo?

Is it safe to switch a Cloudflare record to DNS only?

How do I see which Cloudflare colo my real visitors use?

My CDN Comparison: Cloudflare vs Fastly vs BunnyCDN for Business

How CDNs Improve Performance

Cloudflare: The Thorough Platform

Performance Characteristics

Key Features

Pricing Structure

Best Suited For

Considerations

Fastly: Developer-Focused Edge Computing

Performance Characteristics

Key Features

Pricing Structure

Best Suited For

Considerations

BunnyCDN: Cost-Effective Simplicity

Performance Characteristics

Key Features

Pricing Structure

Best Suited For

Considerations

Head-to-Head Comparison

Performance Comparison

Feature Comparison

Cost Comparison (100TB/month bandwidth)

Ease of Use Comparison

My Implementation Recommendations

For Small Business Websites

For E-Commerce Sites

For Media and Publishing

For Development and Testing

For Enterprise Applications

Migration Considerations

Related Reading

Benchmarking OpenWA: WhatsApp Gateway Throughput, Memory Overhead, and p99 Latency Under Load

Benchmarking OpenWA: WhatsApp Gateway Throughput, Memory Overhead, and p99 Latency Under Load

Test Topology

Metric Comparison Table

Production Threshold Analysis

Implementation: Hono.js Validation Layer

Memory Pressure Root Cause

Architectural Fit

How I built a 7,800-page nutrition site with Astro and Cloudflare Pages

3. Why `Vary: RSC` Is Not Enough