A Platform That Reads Your Framework, Not Your Vendor API
Choosing a cloud platform often means accepting its proprietary building blocks. On AWS, you wire together Lambda functions, NAT Gateways, and DynamoDB tables. On Cloudflare, you write Workers, use KV stores, and bind services with Worker Service Bindings. These primitives exist only with that vendor, so moving to another platform forces a rewrite of your application architecture.
Vercel takes a different route. Instead of requiring you to build against Vercel-specific APIs, the platform interprets your framework code and provisions the necessary infrastructure automatically. Your application never needs to import Vercel modules or call Vercel functions. This is what Vercel calls framework-defined infrastructure (FDI): you follow your framework's conventions, and the platform handles the underlying resources.
The Real Cost of Lock-In
Vendor lock-in occurs when a platform's features deviate from open standards and are accessed through proprietary APIs in your application code. Dependencies on AWS Step Functions or Cloudflare Durable Objects live directly in your business logic, tying it to that platform. Migrating requires rewriting that logic to fit different primitives.
Framework conventions—Next.js App Router, Remix loaders, SvelteKit endpoints, Nitro storage adapters—work differently. You build against the framework, not the platform. Any infrastructure that supports the framework can run the same code, keeping your application portable.
This portability is possible because FDI lets the platform read your code and determine what infrastructure you need. Complex production applications run on Vercel without vercel appearing anywhere in the codebase. The platform analyzes the build output and provisions middleware, functions, static assets, and caching accordingly. Vercel supports 40+ frameworks, not just Next.js.
Local Development Without a Simulator Layer
Platforms built on vendor primitives need complex simulators for local development. Cloudflare offers Wrangler to emulate Workers locally. AWS developers rely on LocalStack or SAM CLI to mock Lambda and other services. These tools approximate production behavior but never match it exactly.
With FDI, you run your framework's standard development server: next dev for Next.js, remix dev for Remix. The code you write behaves the same locally and in production. There is no Vercel CLI to install and no simulation layer introducing discrepancies between environments. When you write against framework standards instead of platform primitives, your code can run elsewhere unchanged.
Portability in Practice
Next.js is the most widely deployed framework on Vercel, which might suggest lock-in. The data suggests otherwise. Based on Next.js telemetry tracking distinct projects, roughly 70% of Next.js applications run outside of Vercel. This likely undercounts non-Vercel deployments, since self-hosted projects often disable telemetry while Vercel deployments rarely do.
Large-scale production deployments confirm this portability. Walmart.com runs self-hosted Next.js for millions of daily shoppers. Nike.com operates on its own systems at global scale. Claude.ai built its application with Next.js on its own infrastructure. Netlify, Cloudflare, AWS Amplify, Google Cloud, and Azure all offer Next.js deployment options, and open source projects like OpenNext enable serverless architectures similar to Vercel on custom infrastructure.
A Formal Contract Between Framework and Platform
Platform providers told Vercel that integration was harder than it should be. That led the Next.js team to build Build Adapters as explicit, versioned APIs that formalize the contract between framework and platform. Adapters define what Next.js outputs, which infrastructure features each route needs, and how platforms should handle them.
Every Next.js 16 application deployed on Vercel uses the same adapter API available to other platforms. Vercel has no special access or different integration points. The test suite Vercel uses to validate features is open to all platform providers. This is part of Vercel's broader Open SDK strategy: frameworks, SDKs, and tools that are open, portable, and usable anywhere.
Standards Where Standards Exist
Vercel prioritizes standard protocols whenever possible. Databases available through the Vercel Marketplace use standard protocols like Postgres and Redis, offered by partners like Neon, Supabase, and Upstash—or you can connect to any instance you operate. Since AWS is Vercel's preferred cloud provider, connecting to databases in the same AWS region gives you low-latency connectivity.
The same philosophy extends to AI infrastructure. AI Gateway supports the OpenAI API format, which OpenAI, Anthropic, and most other model providers have adopted as a de-facto standard. Switching between calling OpenAI directly or routing through AI Gateway only requires changing the API endpoint URL in your configuration—no code changes needed.
Some services require proprietary APIs because no industry standard exists yet. Vercel Sandbox provides secure execution of untrusted code. Edge Config offers ultra-low latency reads with a simple get(key) interface for distributed configuration. Migrating to alternatives would require updating your code to use their APIs. However, these services can be called from any infrastructure, including EC2 or your own servers, without requiring Vercel for hosting. When industry-standard APIs emerge for these use cases, Vercel says it will implement them.
Why Open Source Matters
Building portable, open source software is a core value at Vercel. The company's stated goal is to improve the default quality of software for everyone, whether they are Vercel customers or not. When developers learn Next.js, Nuxt, or the AI SDK, they need confidence that investment won't trap them on a single platform. That trust drives broader adoption, which creates a larger ecosystem, which makes every platform—including Vercel—better.
Vercel's position is straightforward: it wants developers to stay because they choose to, not because they have to. The way to earn that choice is to build tools that work everywhere and a platform that makes those tools better.
