From Infrastructure as Code to Framework-Defined Infrastructure
Infrastructure as code (IaC) has become the standard way to provision servers, networks and other compute resources reliably and repeatably. IaC treats infrastructure as version-controlled configuration files that, when executed, create a described system state — whether that means network setups, application servers, databases or message queues.
Framework-defined infrastructure (FdI) takes that concept a step further. Instead of developers writing infrastructure configuration directly, a build-time process analyzes source code written against a framework, understands the developer's intent, and automatically generates the necessary IaC configuration. The cloud primitives — servers, serverless functions, queues — become implementation details hidden behind the framework's abstractions.
This approach yields several practical benefits:
- Portability between different infrastructure providers
- No manual configuration needed to run an application in production
- More development time spent on product code rather than system management
- Unchanged use of the framework's native local development tools
- Standardization on pre-reviewed, secure services
The concept builds on the "Hollywood principle" — "Don't call us, we call you" — that defines how frameworks invert control. Because the framework manages the high-level application flow and the developer writes code only within its hooks, the framework's structure is predictable enough to be mapped onto infrastructure automatically. Examples below use Vercel's Platform as a Service offering, but the underlying idea can apply to more traditional infrastructure deployments as well.
How Frameworks Map to Infrastructure
Next.js provides a useful illustration. The framework uses a file-based router: a file at pages/blog/index.ts creates a route at /blog. Framework-defined infrastructure elevates this route table from an implementation detail of the framework to something the infrastructure itself understands. In Vercel's case, the generated route table gets deployed to a gateway service that knows how to invoke the correct infrastructure primitive for any given request.
Consider a page component that exports a getServerSideProps function:
export default function BlogPosts({ posts }) {
return posts.map(post => <BlogPost key={post.id} post={post} />)
}
export async function getServerSideProps() {
const posts = await getBlogPosts();
return {
props: { posts }
}
}
Because getServerSideProps means the page must be rendered dynamically on every view, production needs a compute resource — an application server or serverless function — to perform the data fetching and rendering. With framework-defined infrastructure, this requirement is inferred directly from the code. Vercel automatically creates a serverless function (based on AWS Lambda) with the necessary rendering code, and updates the routing table accordingly.
Now change getServerSideProps to getStaticProps:
export default function BlogPosts({ posts }) {
return posts.map(post => <BlogPost key={post.id} post={post} />)
}
export async function getStaticProps() {
const posts = await getBlogPosts();
return {
props: {posts}
}
}
In Next.js, getStaticProps means the page can be rendered once at build time into static HTML. The infrastructure inference changes accordingly: no serverless function gets deployed for this page. Instead, the build-time artifacts are served from lower-cost static web-serving infrastructure, and the routing table points there.
The same principle extends to other framework features:
- Gatsby's Deferred Static Generation deploys a serverless function that generates a page on first request, stores the output in AWS S3, and pushes it globally to the edge — so subsequent requests skip the function invocation entirely.
- SvelteKit form actions and Remix routes automatically trigger creation of serverless functions to perform the requested actions.
- Next.js middleware causes automatic provisioning of edge computing resources to execute the middleware code during request processing.
- Next.js's image optimization component automatically sets up a high-performance image optimization system that tailors images to the requesting device.
Underneath, these framework primitives are compiled to Vercel's Build Output API — a declarative IaC configuration consumed by the platform to provision production infrastructure.
The Serverless Local Development Problem
Serverless architecture removes the burden of managing physical or virtual servers, but developers still must define and deploy serverless primitives explicitly. With AWS Lambda, for example, creating a function requires the same kind of resource declaration as a traditional serverful service. In HashiCorp Terraform, a Lambda function is just another resource block:
resource "aws_lambda_function" "my_lambda" {
filename = "lambda_function_payload.zip"
function_name = "lambda_function_name"
role = aws_iam_role.iam_for_lambda.arn
handler = "index.test"
source_code_hash = filebase64sha256("lambda_function_payload.zip")
runtime = "nodejs16.x"
environment {
variables = {
foo = "bar"
}
}
}
Serverless systems also introduce a local development problem. The production stacks that run serverless code are often complex and proprietary. Developers either test against the production environment via slow deploys, or they must construct a local simulation of the serverless stack that stays continually in sync with production.
Framework-defined infrastructure sidesteps this entirely. Since the framework dictates production behavior, local development uses the framework's own native tooling. Production infrastructure is then automatically configured as a scaled, optimized version of the same behavior the developer exercised locally. No local stack emulation required.
Version Control and Immutable Infrastructure
Application code has long lived in version control, and infrastructure-as-code typically shares that repository or a sibling one. Yet the running production environment itself usually represents only a few snapshots of that history — "production," "staging," and little else. That model breaks down when infrastructure definitions are generated from framework code that must correspond, exactly and at all times, to a specific commit.
Immutable deployments close that gap. Rather than reusing a small set of environments, each deployment creates a brand-new infrastructure from scratch and never modifies it afterward. The result is a one-to-one mapping between a commit and its running infrastructure, rather than a many-to-one relationship where multiple versions of code share an environment.
Doing this physically was never realistic when infrastructure meant fixed hardware that would be exhausted as deployments multiplied. Serverless changes the calculus: idle infrastructure can shrink to zero, so the only cost of retaining an old deployment is the storage needed for its contents. Vercel demonstrates this pattern by generating an immutable deployment for every git hash pushed to a repository, each mapped onto its own virtual serverless infrastructure.
Framework Knowledge as the Interface
Framework-defined infrastructure is an extension of infrastructure-as-code — one that leans on the framework to translate application patterns into the primitives a scalable system needs. This keeps local development simple while still producing production-grade infrastructure definitions.
The approach would be impractical without the abstractions IaC and orchestration layers already provide. It leans on systems like Kubernetes to fill in the gaps between what framework code reveals and what a running system actually requires. The model is likewise well suited to platform-as-a-service targets, from the original Google AppEngine onward.
No Primitives Required
With immutable, serverless-backed deployments, production environments mirror the exact version of the code they run. Scaling is handled by the platform, and costs stay near zero when traffic drops. At Vercel, this framework-defined approach is being built to make DevOps more predictable, cheaper, and less risky — and for the developer, effectively infrastructure-free.
