Beyond Lock-in: Vercel's Framework-Defined Infrastructure for Portable Cloud Development

5 min read

Nov 10, 2025

Vendor lock-in is a critical consideration when selecting a cloud platform. Many cloud platforms create dependencies by requiring developers to build applications using their specific proprietary primitives. Vercel, however, adopts a different philosophy: you write code for your chosen framework, not specifically for Vercel.

Traditional cloud providers illustrate this: on AWS, you configure services like Lambda functions, NAT Gateways, and DynamoDB tables. Cloudflare mandates using Workers, KV stores, Durable Objects, and binding services with Worker Service Bindings. These primitives are unique to each vendor, meaning that migrating your application to another platform typically necessitates a complete rewrite of your architectural setup.

All too often, cloud platforms dictate these choices, introducing proprietary primitives, APIs, and services that deeply embed your code into their ecosystem, making departure prohibitively difficult.

At Vercel, we champion the opposite approach, believing it fosters superior software and a healthier web. Our goal is for developers to remain on our platform by choice, not by obligation. This commitment drives us to build open tools, embrace industry standards, and guarantee your code's portability, regardless of its execution environment.

Vercel's operational model is unique. It interprets your framework code and automatically provisions the necessary infrastructure. Your application remains unaware that it's running on Vercel; there's no need to import Vercel-specific modules or call Vercel APIs. This concept is what we call framework-defined infrastructure.

What Vendor Lock-in Actually Means

Vendor lock-in occurs when a platform develops features that diverge from open standards, accessed within your application code via proprietary APIs. If your application relies on these specific features, migration to an alternative platform becomes impossible without extensive code modification.

When you develop against vendor primitives, such as AWS Step Functions or Cloudflare Durable Objects, these dependencies become integral to your application code. Your core business logic becomes intertwined with platform-specific APIs, implying that any move would require re-architecting that logic to function with different primitives.

In contrast, framework conventions—like the Next.js App Router, Remix loaders, SvelteKit endpoints, or Nitro storage adapters—operate differently. You build against the framework itself, not the underlying platform. This distinction allows multiple platforms to execute the same framework code, ensuring your application remains portable across any infrastructure that supports your chosen framework.

Framework-defined Infrastructure empowers developers to define their infrastructure through their framework, sidestepping vendor-specific code or logic.

Framework-Defined Infrastructure Means Portable Code

This inherent portability is made possible by Framework-Defined Infrastructure (FDI). FDI dictates that the platform intelligently analyzes your code to ascertain and provision the necessary infrastructure. You simply adhere to your framework's established patterns, and Vercel autonomously manages the underlying infrastructure.

Remarkably, complex production applications can run on Vercel without a single mention of vercel anywhere in their codebase. These applications rigorously follow conventions set by Next.js (or Remix, SvelteKit, Nuxt, or any of the 40+ supported frameworks). Vercel then meticulously analyzes the build output and consequently provisions middleware, functions, static assets, and caching mechanisms.

Local Development Requires No Vercel Tooling

Platforms built upon vendor-specific primitives often necessitate intricate simulators for local development. Cloudflare, for instance, offers Wrangler to simulate Workers locally. AWS developers utilize tools like LocalStack or SAM CLI to mock Lambda and other services. While these tools attempt to approximate production behavior, they rarely achieve an exact match.

With FDI, your local development experience is streamlined: you simply run your framework's standard development server. For Next.js, this means executing next dev. For Remix, it's remix dev. The code you write behaves identically in both your local environment and in production. There's no Vercel CLI to install, and no simulation layer to introduce environmental discrepancies.

This deliberate architectural choice directly enhances portability. By developing against framework standards rather than platform-specific primitives, your code can be deployed elsewhere without any modifications.

Most Next.js Apps Already Run Outside of Vercel

Given that Next.js is the most widely deployed framework on Vercel, some might erroneously conclude that this leads to lock-in. However, empirical data clearly indicates otherwise.

According to Next.js telemetry, which tracks distinct projects, approximately 70% of Next.js applications operate outside of the Vercel ecosystem. This figure likely undercounts non-Vercel deployments, as Vercel deployments rarely disable telemetry, whereas self-hosted deployments frequently opt out, thus remaining unrecorded in the data.

Numerous prominent companies currently self-host Next.js on their proprietary infrastructure, unequivocally demonstrating its real-world portability. Walmart.com serves millions of daily shoppers on self-hosted Next.js; Nike.com maintains global scale operations on its own systems; and Claude.ai also constructed its application using Next.js on its independent infrastructure. These examples represent large-scale production applications managing substantial traffic on infrastructure fully controlled by these organizations.

Furthermore, every major cloud vendor now offers Next.js deployment options. Netlify, Cloudflare, AWS Amplify, Google Cloud, and Azure all provide native support for Next.js. For bespoke infrastructure setups, open-source projects like OpenNext enable Next.js to run on serverless architectures akin to Vercel's.

Next.js Adapters Formalize the Framework-Platform Contract

Platform providers conveyed that integration was more complex than it needed to be. In response, the Next.js team developed Build Adapters as explicit, versioned APIs to formalize the contract between the framework and the platform. Adapters meticulously define what Next.js outputs, the specific infrastructure features each route requires, and how platforms should effectively manage them.

Every Next.js 16 application deployed on Vercel utilizes the identical adapter API that is openly available to other platforms. Vercel possesses no special access or distinct integration points. The comprehensive test suite Vercel employs to validate features is also accessible to all platform providers.

This initiative forms a cornerstone of our broader Open SDK strategy: our commitment to building frameworks, SDKs, and tools that are inherently open, portable, and universally usable across any platform.

Standards First, Portable Always

We prioritize standard protocols whenever feasible. Databases offered via the Vercel Marketplace leverage standard protocols such as Postgres and Redis. These are facilitated through marketplace partners like Neon, Supabase, and Upstash, or you have the flexibility to connect to any instance you personally operate. AWS serves as our preferred cloud provider, ensuring low-latency connectivity when you link to databases hosted within the same AWS region as your application.

This identical philosophy extends to our AI infrastructure. The AI Gateway supports the OpenAI API format, which has become a de-facto industry standard adopted by OpenAI, Anthropic, and most other leading model providers. Switching between direct OpenAI calls and routing through the AI Gateway merely requires changing the API endpoint URL in your configuration, with no code modifications necessary.

Certain services currently necessitate proprietary APIs due to the absence of an existing industry standard. Vercel Sandbox provides secure execution for untrusted code. Edge Config delivers ultra-low latency reads via a straightforward get(key) interface for distributed configuration. Migrating to alternatives for these services would require updating your code to utilize their specific APIs. However, a crucial distinction is that these services can be invoked from any infrastructure, including EC2 instances or your own servers, without obligating you to use Vercel for hosting. As industry-standard APIs emerge for these particular use cases, we are committed to implementing them.

Why We Build This Way

Building portable, open-source software is a fundamental value at Vercel. We develop open-source solutions to cultivate an enduring business that, in turn, allows us to continue creating exceptional open-source software. Our ultimate objective is to elevate the default quality of software for everyone, everywhere, irrespective of whether they are Vercel customers.

When developers invest their time learning Next.js, Nuxt, or the AI SDK, they need assurance that this investment will not trap them on a single platform. This trust fuels broader adoption. Broader adoption, in turn, cultivates a larger ecosystem. A larger, more vibrant ecosystem ultimately enhances every platform, including Vercel.

We aspire for you to remain with Vercel by choice, not by necessity. The most effective way to earn that choice is to engineer tools that operate seamlessly everywhere and construct a platform that continually enhances those tools.