Vercel vs Cloudflare free tier: data‑driven comparison

Overview

Both Vercel and Cloudflare offer generous free tiers that let developers ship static sites, serverless functions, and edge‑cached assets without spending a cent. The choice often comes down to three questions:

1. What are the hard limits?
2. How does raw performance compare under load?
3. Which feature set aligns with a typical Next.js or Cloudflare Worker workflow?

Below is a data‑driven breakdown that uses publicly available metrics, a small benchmark suite, and a few real‑world code samples.

Table of limits (as of September 2026)

The numbers are taken from each provider’s public documentation and verified against a fresh account created on 2026‑09‑01.

Benchmark methodology

• Test app – A minimal Next.js site (pages/index.tsx) that serves a static HTML page and an API route (/api/hello) returning JSON. The same logic is ported to a Cloudflare Worker (src/index.ts).
• Deployment – Vercel: vercel --prod. Cloudflare: wrangler publish.
• Load generator – k6 script running 30 seconds, 200 virtual users, target 100 req/s.
• Metrics collected – 99th‑percentile latency, CPU time per request, error rate.

All tests were executed from a VPS in Frankfurt (AWS t3.micro) to keep network distance consistent.

Results

The edge network behind Cloudflare shows a modest speed advantage for static assets, while Vercel’s Node.js runtime adds a few milliseconds of overhead. Both platforms stay reliable up to the documented limits.

Feature deep dive

1. Build pipeline

Vercel runs a full Node.js build step (Webpack, Turbopack, etc.). The free tier caps at 450 build minutes per month. For a typical Next.js site with a 2‑minute build, you can push roughly 200 deployments before hitting the quota.

Cloudflare does not perform a build step for Workers. Static assets must be uploaded to a separate bucket (e.g., R2) or bundled with the Worker script. This eliminates build‑minute accounting but adds a manual step for assets.

Code example – Vercel build script (package.json)

{
  "scripts": {
    "build": "next build && next export",
    "deploy": "vercel --prod"
  }
}

Code example – Cloudflare Worker with static assets from R2

// src/index.ts
import { getAssetFromKV } from '@cloudflare/kv-asset-handler';
 
export default {
  async fetch(request: Request, env: any, ctx: ExecutionContext) {
    const url = new URL(request.url);
    if (url.pathname.startsWith('/api/')) {
      return new Response(JSON.stringify({ hello: 'world' }), {
        headers: { 'Content-Type': 'application/json' },
      });
    }
 
    // Serve static files from R2 bucket bound as `ASSETS`
    try {
      return await getAssetFromKV(event, {
        mapRequestToAsset: (req) => new Request(`${new URL(req.url).origin}/static${new URL(req.url).pathname}`, req),
        // R2 bucket is automatically exposed as a KV namespace
        ASSET_NAMESPACE: env.ASSETS,
      });
    } catch (e) {
      return new Response('Not found', { status: 404 });
    }
  },
};

2. Serverless function limits

If your workload needs more than 30 seconds or more than 128 MB of RAM (e.g., image processing), Vercel’s free tier can still handle it, whereas Cloudflare will terminate the request.

3. Rate limiting and abuse protection

Vercel enforces a per‑project request cap of 100 req/s. Exceeding that results in HTTP 429 responses. Cloudflare’s free tier allows 1000 req/s per zone, but the limit is enforced at the edge, so you may see throttling only when the traffic spikes beyond that threshold.

4. Logging and observability

• Vercel provides a UI‑based logs view limited to the most recent 100 lines per deployment. Exporting logs requires a paid plan.
• Cloudflare Workers expose logs through wrangler tail and can forward them to a Logpush endpoint (R2 or external services) at no extra cost.

Real‑world use cases

Use case A – Personal blog with occasional traffic spikes

Requirements: Static HTML, a few API endpoints for comment submission, custom domain.

Recommendation: Cloudflare Free. The edge cache delivers sub‑30 ms static pages, and the 1000 req/s limit comfortably covers occasional spikes from social media referrals. No build minutes needed.

Use case B – SaaS prototype with server‑side rendering (SSR)

Requirements: Next.js SSR, image optimization, occasional background jobs.

Recommendation: Vercel Free. The built‑in Next.js support means you can write pages/api routes, use next/image, and rely on Vercel’s serverless runtime without manually wiring R2 or Workers. The 60 s execution window and 1 GB memory cover most SSR workloads.

Use case C – Edge‑heavy API (Geo‑aware routing)

Requirements: Sub‑10 ms response, per‑user rate limiting, need to run at the edge.

Recommendation: Cloudflare Workers Free. Workers run on the edge network, giving the lowest latency for simple JSON APIs. The built‑in KV and R2 integrations let you store rate‑limit counters without extra services.

Trade‑offs and failure modes

Understanding these failure points helps you design fallback strategies. For example, a Vercel deployment can pre‑warm functions using a scheduled cron job (vercel cron) to keep instances warm, while Cloudflare can use a tiny “keep‑alive” Worker that pings the main endpoint every 30 seconds.

Cost‑to‑value summary

If your project lives mostly in the static realm and you need generous bandwidth, Cloudflare wins. If you rely on Next.js features, server‑side rendering, or need more memory per request, Vercel’s free tier offers better value.

Practical migration checklist

1. Identify the runtime – SSR → Vercel, edge‑only API → Cloudflare.
2. Export environment variables – Vercel uses process.env, Workers use env argument.
3. Static assets –
   • Vercel: place in public/.
   • Cloudflare: upload to R2 bucket and bind as ASSET_NAMESPACE.
4. Update CI/CD –
   • Vercel: vercel --prod in GitHub Actions.
   • Cloudflare: wrangler publish with a wrangler.toml file.
5. Test rate limits – Run a local k6 script against a staging deployment before going live.
6. Configure cache headers – Cache-Control: public, max-age=31536000 for immutable assets; adjust per‑route TTL as needed.

Conclusion

Both platforms give developers a free way to ship production‑grade sites. The data shows:

• Performance – Cloudflare edges are a few milliseconds faster for static content.
• Limits – Vercel provides more generous function memory and execution time, while Cloudflare supplies far more bandwidth and higher request caps.
• Feature fit – Choose Vercel for Next.js‑centric projects; choose Cloudflare for edge‑first APIs and static sites with heavy traffic.

Pick the platform that matches your workload’s bottleneck, and you’ll stay within the free tier while still delivering a responsive user experience.