How Vercel runs modern frameworks, and when to choose it over AWS or Azure

Hosting a business web application used to mean choosing servers. Today you can choose a platform that works out the infrastructure from your code, or a cloud that hands you each building block. Disclosure: Kastling's own website runs on Vercel, and Kastling's cloud service covers AWS and Azure. Everything below about Vercel comes from its public documentation, read in October 2026.

How does Vercel turn a framework into infrastructure?

Vercel calls its approach framework-defined infrastructure. Its 2023 engineering post describes it as an evolution of infrastructure as code, where the deployment environment automatically provisions what the application needs. Infrastructure as code means writing the servers and networks down in configuration files; here the platform reads your application instead.

The mechanism is the build output. When you deploy, Vercel's build step produces static assets and bundled functions, and the platform routes each request to the right one. Static pages become files on the content delivery network (CDN), a set of servers around the world that cache and serve content near users. A page that needs server rendering becomes a function. Vercel's docs describe the Build Output API as a file-based specification that framework authors implement to use Functions, routing and caching.

For a small team, this means a developer pushes code and no one writes load balancer or scaling rules. The tradeoff is that the platform decides the shape of the infrastructure.

Vercel vs AWS vs Azure: how do they compare?

The table compares Vercel with the AWS and Azure services most often used for the same job. It is a summary of the documentation each vendor publishes, so confirm plan details before you commit.

What are Fluid compute and active CPU pricing?

Traditional serverless starts a new instance for each concurrent request. Vercel's compute documentation explains that in the traditional model one instance processes one request at a time, so a traffic spike starts many instances that mostly wait on I/O (input and output, such as a database call). Fluid compute starts a new instance only when no running instance has spare capacity, and one instance serves many requests concurrently. Vercel calls this optimized concurrency and says it is available on the Node.js and Python runtimes. Per the docs, Fluid compute has been the default for new projects created on or after April 23, 2025.

Billing follows the same logic. Vercel's pricing page says it bills active CPU only while your code runs, pausing during I/O, while provisioned memory bills for the life of the instance. Its example: a function that spends 100 ms processing and 400 ms waiting on a database is billed 100 ms of CPU. Invocations are billed per request.

This suits workloads that spend most of their time waiting, such as calls to AI models. AWS now describes a similar model for some Lambda functions: its pricing page says web functions are billed for requests, the CPU time code actively uses, and memory, while event functions are billed on duration from start to return. Check which type you would use before comparing prices.

How do caching, streaming and previews work?

Incremental Static Regeneration (ISR) serves a cached page and rebuilds it in the background. Vercel's documentation says it follows a stale-while-revalidate pattern: visitors get the cached copy while the page regenerates on a timer or when you call an API. If regeneration fails, Vercel keeps serving the stale page and retries in 30 seconds. It suits catalogs and content that change on a schedule of minutes to hours, not in real time.

Streaming sends a response in pieces as it is produced, which makes AI answers appear sooner. The streaming documentation covers Node.js and Python functions, and the runtimes page notes that a function has a maximum duration, so it cannot stream indefinitely.

A preview deployment is a temporary copy of the application for a branch or pull request. By default Vercel creates one when you push to a non-production branch or open a pull request, with a branch URL and a per-commit URL. Reviewers click a link instead of running code locally. AWS Amplify Hosting offers pull request previews too, and Azure Static Web Apps provides staging environments.

Can Vercel run Python and other backends?

Yes, within its function model. The runtimes page lists Node.js, Bun, Python, Rust, Go, Ruby, Wasm, Edge and a container runtime. The Python runtime runs ASGI and WSGI applications such as FastAPI, Flask and Django as functions, on Python 3.12 by default with 3.13 and 3.14 available. The backend documentation adds zero-configuration deployment for Express, Hono, NestJS and others, and WebSocket support when Fluid compute is on.

Background work needs a different shape. Vercel documents Celery and Dramatiq workers running as queue-triggered functions, and Vercel Workflows for tasks that must pause and resume over minutes to months. Those are Vercel-specific services to learn, so weigh them against a plain queue and worker on AWS or Azure.

What are Vercel's limits?

The following limits come from Vercel's documentation as of October 2026. Several depend on plan.

• Body size. The maximum request or response body for a function is 4.5 MB, and larger payloads return a 413 error. Large uploads need to go direct to storage.
• Size and resources. A function bundle can be 250 MB uncompressed (500 MB for Python), and memory tops out at 4 GB and 2 vCPU on Pro and Enterprise. The page lists CPU and memory sizes and no GPU option.
• Duration. The default is 300 seconds, the Pro and Enterprise maximum is 800 seconds, and 1,800 seconds is in beta.
• Regions. Vercel runs 19 compute regions, with functions defaulting to Washington, D.C. Pro teams can set up to five function regions, and Enterprise teams can use all of them. Its compliance page says customers choose where code runs, but Vercel may also transfer data to the United States and elsewhere under its data processing addendum, so check that against any residency rule.
• Networking. Deployments use dynamic IP addresses by default. Static IPs cover outbound traffic on Pro and Enterprise, and Secure Compute, with private networks, VPC peering and VPN, is an Enterprise feature.
• Cost at sustained scale. Vercel's own guide says servers work well for highly predictable workloads, with stable costs under steady traffic. A service that runs hot all day pays for CPU and memory all day, so price it against reserved capacity.

Vercel does document ways around some of these. Bring Your Own Cloud runs functions as AWS Lambda functions in your own AWS account, on the Enterprise plan with Node.js and Python only.

When should you choose AWS or Azure instead?

Choose AWS or Azure when one of these applies.

1. Private networking is a requirement. Databases and ERPs that sit in a private network are simpler to reach from inside the same cloud, and Fargate tasks each get their own elastic network interface.
2. A compliance posture is specified. If a contract or regulator names a cloud, region or isolation model, host there. Vercel's own BYOC guide notes that the option does not currently satisfy FedRAMP.
3. The work is long-running or needs GPUs. Azure Container Apps bills GPU-seconds as a meter alongside vCPU and memory.
4. You already run an estate. Existing identity, logging and networking carry over. Azure App Service highlights savings plans and reserved instances for predictable workloads.

Illustrative example: Consider a 60-person company with a marketing site and a customer portal built in Next.js. The portal reads from a database in a private AWS network. The team hosts the web front end on Vercel, and puts a small authenticated API in AWS next to the database, which the front end calls over HTTPS. The alternatives are Secure Compute on Enterprise or, for an AWS-hosted database, AWS PrivateLink or an IP allowlist through Static IPs, each with its own plan requirements. The split keeps previews and caching on Vercel and the data inside the network the security team already controls.

What is the verdict?

Choose Vercel when the work is a web front end or a framework application, a small team owns it, and the data it touches can be reached over authenticated HTTPS. You get previews, caching and scaling without building them.

Choose AWS or Azure when the work needs private networking, a specific compliance posture, long-running or GPU workloads, or fit with an existing estate. Many setups use both. Put the data and heavy work where your controls are, and the front end where your developers are fastest. Price a realistic month before committing, because billing models differ more than list prices suggest.

How Kastling approaches this

Kastling would start from the application, the data it touches and who will run it, then compare hosting options against the constraints above. Kastling's cloud service covers AWS and Azure, and its own website runs on Vercel, so the comparison is made on fit. The team would connect to existing systems, agree how success is measured and keep a named person in control of consequential decisions. See AI & Cloud Infrastructure for the service. For provider choice, read AWS or Azure for AI, and for production operations, running AI in production on AWS and Azure.