TanStack Start on Vercel vs Cloudflare

TanStack Start is a full-stack framework for React and Solid, built on TanStack Router, with full-document SSR, streaming, and server functions. Because it builds on Vite, it deploys anywhere JavaScript runs, including both Vercel Functions and Cloudflare Workers. Your framework code stays the same on either platform. What changes is the runtime your server code executes in, how you configure and deploy the project, and which storage and background-processing services you connect to.

On Vercel, TanStack Start runs on Vercel Functions with Fluid compute through the Nitro Vite plugin. On Cloudflare, it runs as a Worker in the V8-isolate-based workerd runtime through the Cloudflare Vite plugin. Those runtimes lead to different tradeoffs in package compatibility, where your code executes, how it scales, and how you pay for compute. This guide breaks down how the two platforms differ so you can decide which one fits your project.

In this comparison guide, you'll learn:

• How TanStack Start deploys and runs on Vercel and Cloudflare
• How the Vercel Functions and Cloudflare Workers runtimes differ in compatibility and execution
• How storage, scheduled tasks, queues, and workflows map across the two platforms
• How each platform prices computing
• When to choose Vercel or Cloudflare for your project

Both Vercel and Cloudflare officially support TanStack Start through a Vite plugin, and both build the same framework code. The differences start at the server runtime and flow through to configuration, scaling, and pricing.

The most consequential difference is the server runtime. Vercel runs TanStack Start in a full Node.js runtime on Vercel Functions, while Cloudflare runs it in workerd, a runtime built on V8 isolates.

This determines which packages run without extra work. On Vercel, npm packages that depend on Node.js built-in modules work without configuration. On Cloudflare, you enable the nodejs_compat flag to use Node.js APIs, and some native or filesystem-dependent modules aren't supported in the isolate model.

Memory differs, too. Vercel Functions let you configure up to 3009 MB of memory per function, which helps with heavier in-memory work. Cloudflare Workers run with a fixed 128 MB limit per isolate, and a single isolate can handle multiple requests concurrently, so you design around a smaller, shared memory budget.

Vercel Functions run in a region you choose, with a default to one close to your deployment. You can place them near your database to reduce data access latency, and Pro and Enterprise plans can run functions across multiple regions. Cloudflare Workers run across Cloudflare's global network, close to the user making the request.

The tradeoff is between proximity to the user and proximity to your data. Global edge execution lowers network latency for short, compute-light responses served near users. Regional execution keeps your function close to its database or APIs, which often matters more for data-heavy server functions that make multiple round-trip requests per request.

On Vercel, install Nitro and add the nitro() plugin to your Vite config. Vercel detects TanStack Start on import and sets the build command and output directory for you, so a basic deployment needs no platform-specific configuration. Use nitro.config.ts for advanced settings such as per-route function resources, scheduled tasks, and queues, plus an optional vercel.json for project configuration.

import { tanstackStart } from '@tanstack/react-start/plugin/vite';
import { defineConfig } from 'vite';
import viteReact from '@vitejs/plugin-react';
import { nitro } from 'nitro/vite';

export default defineConfig({
  plugins: [tanstackStart(), nitro(), viteReact()],
});

On Cloudflare, install @cloudflare/vite-plugin and wrangler, then add the cloudflare() plugin to your Vite config. You configure the Worker in wrangler.jsonc or wrangler.toml, including the entry point, bindings to Cloudflare services, and a compatibility_date.

import { defineConfig } from 'vite';
import { tanstackStart } from '@tanstack/react-start/plugin/vite';
import { cloudflare } from '@cloudflare/vite-plugin';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [
    cloudflare({ viteEnvironment: { name: 'ssr' } }),
    tanstackStart(),
    react(),
  ],
});

Both platforms deploy from Git, with automatic deploys on push and a preview URL for each pull request. Both connect to GitHub and GitLab. Vercel also connects directly to Bitbucket, whereas Bitbucket on Cloudflare uses an external CI provider via the Wrangler CLI. You can also deploy from the command line with vercel or wrangler.

The clearest code-level difference is how each platform exposes storage. On Cloudflare, you access first-party services through bindings, calling them on the env object you import from cloudflare:workers. On Vercel, you read connection details from process.env and talk to each store through its SDK or client. When you provision storage from the Vercel Marketplace, Vercel adds the connection string and credentials as environment variables for you.

The table below maps common Cloudflare storage options to their Vercel counterparts:

Background work maps across the two platforms feature-for-feature, with one gap. On Vercel, Nitro converts framework-level scheduled tasks and queue topics into Vercel features at build time, so you configure them in nitro.config.ts rather than writing a platform configuration by hand.

Cloudflare Cron Triggers and Queue consumers can use up to 15 minutes of CPU time per invocation. On Vercel, Vercel Workflows run durable steps that can pause, resume, and retain state for minutes to months, supporting long-running processes beyond a single function's duration limit. Durable Objects are the only Cloudflare primitive without a direct Vercel equivalent, so apps that rely on a single coordinating instance per key move that state into a database or Redis.

Both platforms bill compute based on active CPU time rather than wall-clock time, so neither charges full compute rates while your code waits on I/O such as database queries or model responses. The mechanics differ.

Vercel Functions on Fluid compute uses Active CPU pricing. You pay for Active CPU at $0.128 per hour, Provisioned Memory at $0.0106 per GB-hour, and per invocation. CPU is billed only while your code runs, memory is billed while a request is in flight, and nothing is billed between requests. In-function concurrency allows a single instance to handle multiple requests, and predictive scaling keeps instances warm to reduce cold starts. Each plan includes a monthly allotment of these resources.

Cloudflare Workers use Standard pricing based on requests and CPU time. The Workers Paid plan starts at $5 per month. It includes 10 million requests per month, with additional requests at $0.30 per million, and 30 million CPU milliseconds, with additional CPU billed at $0.02 per million. Duration, the wall-clock time a request takes, isn't charged, and there are no separate egress or bandwidth fees. The free plan covers 100,000 requests per day with 10 ms of CPU time per invocation.

Because the two platforms meter different resources, Vercel through active CPU plus provisioned memory, and Cloudflare through requests plus CPU time with fixed memory, your actual cost depends on your traffic volume, how much CPU each request uses, and how much memory your app needs.

The execution limits also measure different things, which matters when you compare them.

Vercel's limit is wall-clock duration, the total time a function can take to respond, including time spent waiting on I/O. Cloudflare's limit is CPU time, which excludes time spent waiting on network requests. A request that mostly waits on a database can run well within Cloudflare's CPU limit while still counting against Vercel's duration limit.

Both platforms offer Git-based deployments, automatic preview URLs per pull request, and framework auto-detection, so the day-to-day deploy workflow is similar. The differences are in what each platform bundles around that flow.

Vercel includes built-in observability for tracing requests and monitoring function usage, and the Vercel Firewall for traffic protection, alongside its preview-deployment workflow. Cloudflare's Vite plugin runs your server code in the same workerd runtime locally as in production and provides local emulation of bindings, so local development closely matches the deployed environment, and static assets are served from Cloudflare's global network.

The framework is identical on both platforms, so the decision comes down to runtime compatibility, where your code needs to run, and how your workload uses compute.

Many teams successfully run TanStack Start on either platform.

Choose Vercel when you want full Node.js compatibility, efficient pricing for I/O-bound and AI workloads, and integrated previews and observability. Choose Cloudflare when low-latency edge execution, a generous free tier, or an existing investment in Cloudflare's storage services are your priorities.

• TanStack Start on Vercel
• Vercel Functions and Fluid compute
• Storage on the Vercel Marketplace and Vercel Blob
• Deploy Nitro to Vercel
• TanStack Start documentation
• Read Migrate a TanStack Start app from Cloudflare to Vercel for the step-by-step migration