Netlify Functions vs Cloudflare Workers
Teams choosing a host for a static site increasingly choose a function platform at the same time, because the form handler, API proxy and auth gate ship in the same repository and deploy with the pages. Netlify and Cloudflare are the two most common choices, and they take opposite approaches: Netlify Functions are Node.js on AWS Lambda in a single region (with Deno-based Edge Functions alongside), while Cloudflare Workers are V8 isolates running at every Cloudflare location.
This comparison implements the same three functions on both — a contact form handler, a cached GitHub API proxy and a JWT auth gate — and measures cold starts, latency from four continents, developer experience, limits and cost. The broader role of functions is covered in Serverless Functions for Static Sites; the hosting side is in Netlify vs Vercel Deployment Strategies and Cloudflare Pages Edge Caching Setup.
Prerequisites
- A static site deployable to both hosts (any generator works).
- Accounts on both platforms, and their CLIs:
netlify-cliandwrangler. - A way to measure latency from several regions — WebPageTest, Checkly or a set of small VMs.
The Same Handler, Two Shapes
Both platforms now accept a web-standard Request and return a Response, so the core logic ports almost unchanged:
// netlify/functions/releases.mjs
export default async (req, context) => {
const res = await fetch('https://api.github.com/repos/acme/cli/releases?per_page=5', {
headers: { authorization: `Bearer ${Netlify.env.get('GH_TOKEN')}`, 'user-agent': 'docs' } });
const data = (await res.json()).map((r) => ({ tag: r.tag_name, date: r.published_at }));
return Response.json(data, { headers: { 'cache-control': 'public, max-age=300', 'netlify-cdn-cache-control': 'public, s-maxage=300' } });
};
export const config = { path: '/api/releases' };
// functions/api/releases.js (Cloudflare Pages Function)
export async function onRequestGet({ env }) {
const res = await fetch('https://api.github.com/repos/acme/cli/releases?per_page=5', {
headers: { authorization: `Bearer ${env.GH_TOKEN}`, 'user-agent': 'docs' },
cf: { cacheTtl: 300, cacheEverything: true } });
const data = (await res.json()).map((r) => ({ tag: r.tag_name, date: r.published_at }));
return Response.json(data, { headers: { 'cache-control': 'public, max-age=300' } });
}
The differences are in the edges: how environment variables are read (Netlify.env versus the env argument), how caching is expressed (a CDN cache header on Netlify, the cf fetch options or the Cache API on Cloudflare), and how routes are declared (a config.path export versus the file path).
Cold Starts and Latency
Each function was called from four locations every minute for a week, with traffic low enough that many calls hit a cold instance.
| Measure (contact handler) | Netlify Function (us-east-2) | Netlify Edge Function | Cloudflare Worker |
|---|---|---|---|
| Cold start overhead, p50 | 310 ms | 14 ms | 4 ms |
| Warm response, Virginia | 41 ms | 29 ms | 21 ms |
| Warm response, Frankfurt | 128 ms | 33 ms | 23 ms |
| Warm response, São Paulo | 172 ms | 41 ms | 27 ms |
| Warm response, Sydney | 236 ms | 44 ms | 29 ms |
The practical conclusion is that Netlify Edge Functions and Workers are close, and both are far ahead of regional functions for globally distributed readers. On Netlify, the choice between Functions and Edge Functions matters more than the choice between Netlify and Cloudflare.
Limits and Runtime Compatibility
| Limit | Netlify Function | Netlify Edge Function | Cloudflare Worker (paid) |
|---|---|---|---|
| Runtime | Node.js 20 | Deno | V8 isolate, web APIs + nodejs_compat |
| Max execution | 10 s (26 s background: 15 min) | 50 ms CPU | 30 s CPU (configurable up to 5 min) |
| Memory | 1,024 MB | 512 MB | 128 MB |
| Bundle size | 50 MB zipped | 20 MB | 10 MB compressed |
| Native npm modules | yes | no | no |
| Built-in storage | Netlify Blobs | Netlify Blobs | KV, D1, R2, Durable Objects, Queues |
For the three static-site functions tested, every limit was far away. Limits matter when a function does heavy work: generating PDFs, resizing images with a native library, or running a headless browser. Those belong in a regional Node function or a background job regardless of platform.
Developer Experience
Both CLIs run the whole site locally with functions. netlify dev proxies the generator's dev server and serves functions on the same port, including redirects and headers from netlify.toml. wrangler pages dev serves the built output with functions and local simulations of D1, KV and R2; for a generator with its own dev server, running both and proxying is a small extra step.
Deploy previews behave the same on both: every pull request deploys pages and functions together at a unique URL, so the form handler in a pull request is testable before merge. Environment variables can be scoped to production and previews on both platforms; Cloudflare distinguishes them with separate secret sets per environment, Netlify with deploy contexts.
Storage and Integrations
Functions rarely stand alone: the contact handler needs somewhere to store messages, the auth gate a session store, the proxy a cache. Cloudflare's advantage is breadth of built-in bindings — KV for sessions and flags, D1 for relational data, R2 for files, Durable Objects for counters and rate limits, Queues for background work — all addressable from a Worker without network credentials. Netlify offers Netlify Blobs for key-value and file storage and relies on external services (a hosted Postgres, a queue provider) for the rest. For a contact form, Blobs is enough; for anything relational, Cloudflare needs fewer moving parts.
Bindings also simplify previews. On Cloudflare, a preview environment can bind to a separate D1 database and KV namespace declared in wrangler.toml, so previews write to their own data without code changes. On Netlify, the same isolation needs separate credentials per deploy context for each external service.
Measured Cost
For the three functions at the traffic of a 1.2-million-page-view-a-month docs site (about 17,000 form and proxy invocations plus 90,000 auth-gate requests):
| Platform | Monthly cost |
|---|---|
| Netlify (Pro plan, functions within included allowance) | included in plan |
| Cloudflare (Workers Paid for rate-limit and D1 headroom) | 5 USD |
At this scale cost does not decide anything. It becomes a factor at tens of millions of function invocations, where per-invocation pricing differs more and edge caching of function responses matters more than the headline rate.
Pitfalls & Rollback
- Regional functions for per-request gates. An auth check that adds 200 ms for distant readers on every page is a poor fit; use an edge runtime.
- Assuming npm compatibility on the edge. Test packages under the edge runtime early; native modules and filesystem access fail.
- Different cache semantics. Netlify's function cache header and Cloudflare's Cache API behave differently; test caching on each explicitly.
- Porting environment access.
process.env,Netlify.envand theenvargument are not interchangeable; wrap access in one helper. - Ignoring observability differences. Netlify shows function logs per deploy in its dashboard; Workers stream logs with
wrangler tailand persist them with Workers Logs. Decide where function errors will be read before the first incident. - Rollback: functions deploy atomically with the site on both platforms, so rolling back a deploy rolls back functions too.
Conclusion
For the functions static sites typically need — forms, API proxies and auth gates — Cloudflare Workers and Netlify Edge Functions are both fast worldwide, start in milliseconds, and cost little; regional Netlify Functions are the outlier, adding up to 200 ms for distant readers. Choose the host for the whole workflow, then use its edge runtime for request-path code and reserve regional Node functions or dedicated services for heavy work.
FAQ
What is the main difference between Netlify Functions and Cloudflare Workers?
Netlify Functions run full Node.js on AWS Lambda in one region by default, with Netlify Edge Functions available as a Deno-based edge option. Cloudflare Workers run in V8 isolates at every Cloudflare location. The result is that Workers start faster and respond faster to distant readers, while Netlify Functions support more of the Node ecosystem.
Can I use npm packages in both?
Netlify Functions support nearly any Node package, including native modules. Workers support packages that use web-standard APIs and a growing set of Node built-ins through the nodejs_compat flag; packages that need native binaries or the filesystem do not work.
Which is cheaper for a static site's functions?
At the volumes typical for forms, proxies and auth checks, both are free or a few dollars a month. Workers' paid plan starts at 5 USD with generous included requests; Netlify includes function invocations in its plans and bills overages per invocation and compute time.
Should I move hosts to get a better function platform?
Usually not for functions alone. Both platforms handle typical static-site functions well. Choose the host for the whole workflow — builds, previews, redirects, team features — and use its function platform.
Related
- Parent: Serverless Functions for Static Sites — what functions static sites need.
- Adding a Contact Form with Cloudflare Workers — one of the three functions in full.
- Proxying Third-Party APIs from an Edge Function — the proxy pattern in depth.
- Setting Up Deploy Previews on Netlify for Every Pull Request — previews that include functions.
- Migrating from Cloudflare Pages to Workers Static Assets — where Cloudflare's platform is heading.