# TanStack Start on Vercel vs Cloudflare **Author:** Ben Sabic --- 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](https://vercel.com/docs/functions) with [Fluid compute](https://vercel.com/docs/fluid-compute) through the [Nitro Vite plugin](https://vercel.com/kb/guide/nitro-vite-plugin). On Cloudflare, it runs as a Worker in the V8-isolate-based `workerd` runtime through the [Cloudflare Vite plugin](https://developers.cloudflare.com/workers/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 ## How TanStack Start runs on each platform Both Vercel and Cloudflare officially support TanStack Start through a [Vite](https://vite.dev/) plugin, and both build the same framework code. The differences start at the server runtime and flow through to configuration, scaling, and pricing. | Area | Vercel | Cloudflare | | ---------------------- | --------------------------------------------------------------------------- | -------------------------------------------------- | | Framework support | Official, via the Nitro Vite plugin | Official, via the Cloudflare Vite plugin | | Build setup | Vite with `nitro/vite` | Vite with `@cloudflare/vite-plugin` | | Server runtime | Vercel Functions on AWS Lambda, full Node.js | Workers in `workerd` (V8 isolates) | | Compute model | Fluid compute, enabled by default | Workers, V8 isolates | | Execution location | Regional (one region on Hobby, up to three on Pro, unlimited on Enterprise) | Global, across Cloudflare's network in 300+ cities | | Memory | Configurable up to 4GB per function | 128 MB per isolate | | Platform config | `vercel.json` (optional) and `nitro.config.ts` | `wrangler.jsonc` or `wrangler.toml` | | Reading config in code | `process.env` | `env` from `cloudflare:workers` (bindings) | | Deploy | Git push or the `vercel` CLI | Git push or the `wrangler` CLI | ## How the runtimes differ 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 4GB 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. ## Where your code runs 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. ## Configuring and deploying TanStack Start 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`. ## Mapping storage and data services The clearest code-level difference is how each platform exposes storage. On Cloudflare, you [access first-party services through bindings](https://developers.cloudflare.com/workers/runtime-apis/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](https://vercel.com/docs/marketplace-storage), Vercel adds the connection string and credentials as environment variables for you. The table below maps common Cloudflare storage options to their Vercel counterparts: | Need | Cloudflare | Vercel | | ---------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | Object storage | R2 | [Vercel Blob](https://vercel.com/docs/vercel-blob) | | Key-value and caching | Workers KV | [Redis from the Marketplace](https://vercel.com/marketplace?search=Redis), or [Edge Config](https://vercel.com/docs/edge-config) for read-heavy config | | SQL database | D1 | [Postgres from the Marketplace](https://vercel.com/marketplace?search=postgres) | | Coordinated, single-instance state | Durable Objects | No direct equivalent; use a database or Redis | | AI inference | Workers AI | [AI Gateway](https://vercel.com/ai-gateway) with the [AI SDK](https://ai-sdk.dev/) | ## Mapping scheduled tasks, queues, and workflows 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. | Need | Cloudflare | Vercel | | ----------------------------- | ------------- | ----------------------------------------------------- | | Scheduled jobs | Cron Triggers | [Vercel Cron Jobs](https://vercel.com/docs/cron-jobs) | | Message queues | Queues | [Vercel Queues](https://vercel.com/docs/queues) | | Durable, multi-step processes | Workflows | [Vercel Workflows](https://vercel.com/workflows) | 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. ## How each platform prices computing 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](https://vercel.com/docs/functions/usage-and-pricing#active-cpu). 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. | Limit | Vercel | Cloudflare | | ------------------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Compute time per request | Wall-clock duration up to 300s (Hobby) and 800s (Pro and Enterprise) | CPU time up to 5 min (default 30s) | | Memory | Configurable up to 4GB | 128 MB per isolate | | Beyond the limit | Vercel Workflows for minutes-to-months processes | 15 min CPU for Cron Triggers and Queue consumers; Workflows for longer processes | 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. ## Comparing developer experience 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](https://vercel.com/products/observability) for tracing requests and monitoring function usage, and the [Vercel Firewall](https://vercel.com/security/web-application-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. ## When to choose Vercel or Cloudflare 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. | If your project... | Consider | Why | | --------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------- | | Depends on npm packages that need full Node.js APIs | Vercel | Runs in a full Node.js runtime with no compatibility flags | | Is I/O-bound or AI-heavy, with LLM calls, agents, or MCP servers | Vercel | Fluid compute, and Active CPU pricing avoid billing CPU during waits, and Workflows handle long jobs | | Needs more than 128 MB of memory per request | Vercel | Function memory is configurable up to 3009 MB | | Integrates Postgres or Redis from a marketplace, Blob storage, and AI Gateway | Vercel | Native Marketplace integrations wire credentials into environment variables | | Serves short, compute-light responses with the lowest latency to users everywhere | Cloudflare | Workers execute at the edge across 300+ cities | | Is request-heavy and compute-light on a tight budget | Cloudflare | CPU-time pricing, no egress fees, and a free tier of 100,000 requests per day suit short requests | | Relies on a single coordinating instance per key, like Durable Objects | Cloudflare | Durable Objects have no direct Vercel equivalent | | Wants previews, observability, and traffic protection in one platform | Vercel | These are built-in alongside the deploy workflow | | Deploys the same app close to its data in specific regions | Either | Vercel runs functions regionally; Cloudflare runs globally by default | 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. ## Next steps - [TanStack Start on Vercel](https://vercel.com/docs/frameworks/full-stack/tanstack-start) - [Vercel Functions](https://vercel.com/docs/functions) and [Fluid compute](https://vercel.com/docs/fluid-compute) - [Storage on the Vercel Marketplace](https://vercel.com/docs/marketplace-storage) and [Vercel Blob](https://vercel.com/docs/vercel-blob) - [Deploy Nitro to Vercel](https://v3.nitro.build/deploy/providers/vercel) - [TanStack Start documentation](https://tanstack.com/start/latest/docs/framework/react/overview) - Read [Migrate a TanStack Start app from Cloudflare to Vercel](https://vercel.com/kb/guide/migrate-a-tanstack-start-app-from-cloudflare-to-vercel) for the step-by-step migration --- [View full KB sitemap](/kb/sitemap.md)