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-cli and wrangler.
  • 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 FunctionCloudflare Worker
Cold start overhead, p50310 ms14 ms4 ms
Warm response, Virginia41 ms29 ms21 ms
Warm response, Frankfurt128 ms33 ms23 ms
Warm response, São Paulo172 ms41 ms27 ms
Warm response, Sydney236 ms44 ms29 ms
Warm response time by reader location Lines across four locations. The regional Netlify Function rises from 41 milliseconds in Virginia to 236 in Sydney. Netlify Edge Functions stay between 29 and 44. Cloudflare Workers stay between 21 and 29. Warm response (ms) by reader location 0 125 250 Virginia Frankfurt São Paulo Sydney Netlify Function (regional) Netlify Edge Cloudflare Worker p50 over one week, one call per minute per location
The gap is geography, not code: edge runtimes answer from near the reader, regional functions from one data centre.

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

LimitNetlify FunctionNetlify Edge FunctionCloudflare Worker (paid)
RuntimeNode.js 20DenoV8 isolate, web APIs + nodejs_compat
Max execution10 s (26 s background: 15 min)50 ms CPU30 s CPU (configurable up to 5 min)
Memory1,024 MB512 MB128 MB
Bundle size50 MB zipped20 MB10 MB compressed
Native npm modulesyesnono
Built-in storageNetlify BlobsNetlify BlobsKV, 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.

Which function type fits which job A matrix of five static-site jobs against three runtimes. Contact form, API proxy and auth gate fit all three, best on edge runtimes for latency. On-demand image resizing with a native library and PDF generation fit only the regional Node function. Match the job to the runtime Netlify Function Netlify Edge CF Worker contact form works best best cached API proxy works best best auth gate on every request too slow best best image resize (native lib) best no Images API PDF generation best no Browser Rendering Cloudflare covers heavy jobs with separate products rather than inside a Worker
Anything that runs on every page request belongs at the edge; anything heavy belongs in a regional function or a dedicated service.

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.

Storage reachable from each platform's functions A Netlify function reaches Netlify Blobs directly and external services such as a hosted database and a queue over the network with credentials. A Cloudflare Worker reaches KV, D1, R2, Durable Objects and Queues as local bindings without network credentials. What a function can reach without leaving the platform Netlify Blobs external DB (network) external queue 1 built-in store + services you run elsewhere Cloudflare KV D1 R2 Durable Objects Queues bindings: no credentials, no extra network hop
Bindings remove a class of secrets from the function entirely: there is no database password to leak.

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):

PlatformMonthly 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.env and the env argument 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 tail and 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.