Vercel Is Great for Frontend Teams

Let me start with the part that is true without qualification: Vercel is great for frontend teams.

If you are a team of frontend engineers shipping a Next.js application, and nobody on the team wants to learn IAM, Vercel is the correct choice. It will be correct for a long time. Everything below the fold of this post is about a different team.

What Vercel gets right #

The developer experience is the product. Push a commit to any branch and you get a preview deployment with a branch-specific URL and a commit-specific URL, posted to the pull request. Zero configuration for Next.js. Instant rollback. Custom environments. None of it requires a line of infrastructure code, and that matters enormously for a team whose job is the interface, not the platform.

Next.js is first-party. Vercel is “made by the creators of Next.js”, and it shows. The Next.js deployment docs describe a concept of verified adapters—platforms that run the full Next.js test suite—and Vercel is among them. Performance features like Partial Prerendering served from the CDN edge, ISR propagating globally in under a second, and skew protection land on Vercel first.

The engineering underneath is real. Vercel runs 126 points of presence and 20 compute regions. It built a Rust function runtime with in-function concurrency to get streaming and many-to-one invocation out of a substrate that did not natively offer it, and it reports that Fluid compute cuts compute cost by up to 85% for idle-heavy workloads. That is not marketing; that is hard distributed-systems work, done well.

If that is the whole story for your team, stop reading and go ship.

Now the other team #

Here is the team this post is actually for: an organization with a platform or backend group that already writes AWS CDK or Terraform, already runs Lambda and CloudFront, already has an AWS account structure with IAM boundaries and CloudWatch dashboards and a WAF. For that team, Vercel’s premium buys much less than it looks like, and costs more than the invoice shows.

You are paying a markup on your own primitives #

Vercel’s region table maps iad1 to us-east-1, pdx1 to us-west-2, fra1 to eu-central-1. All twenty regions are AWS regions. Vercel has said plainly that Vercel Functions run on AWS Lambda — “we’ve turned lambda into an edge-first compute layer” — reached through a TCP tunnel Vercel built between its infrastructure and Lambda.

Compare the list prices, as of this writing.

Three times the request price, roughly 1.8 times the egress price, twice the CDN request price. That is the cost of the renaming layer. If your team cannot write the CDK to put a Lambda behind CloudFront, the markup is a bargain. If it can, the markup is paying for something you already own.

And then there are seats. Vercel Pro is $20 per developer per month. That number scales with headcount, not traffic. A platform team of twelve pays $240 a month before a single request is served. CloudFront, Lambda, Amplify Hosting, and an SST deployment have no seat price at all.

The controls you want are behind the Enterprise wall #

Look at what the Enterprise plan gates: SSO/SAML login, directory sync, audit logs, log drains, tracing support, Datadog and New Relic integrations, SLAs, automatic failover regions, and Secure Compute. Pricing is “Custom.”

Secure Compute is the one that matters most to the AWS team. It is how your Vercel functions reach a private RDS instance or an internal service. It is “available as an Enterprise feature,” it works by VPC peering from a Vercel-owned network into your AWS VPC, it does not support the Edge runtime or middleware, and private data transfer that leaves the network is billed at $0.15 per GB.

On AWS the Lambda is already in your account. Put it in the VPC. Attach the security group. Write the IAM policy scoped to the one queue it needs. Ship logs to the CloudWatch group your platform team already alerts on. Trace it with X-Ray. Every one of those is a few lines of CDK, none of them requires a sales call, and the data never leaves your account. SST’s migration guide says it in one sentence: “Your data will never leave your AWS account.”

Spend controls lag, and you do not own the throttle #

In June 2024 the art platform Cara grew from 40,000 to 650,000 users in a week, peaked at 56 million function invocations a day, and received a $96,280 bill from Vercel for serverless function execution (Silicon Republic). The founder’s own account: “I was hit with a $100k bill from one of our service providers for 1 week of traffic.”

Vercel responded with Spend Management, which is better than nothing and worse than you would hope. From the docs: “Setting a spend amount does not automatically stop usage.” Pausing is opt-in, pauses all production projects with a 503 DEPLOYMENT_PAUSED, and “because these checks are not continuous, notifications, webhooks, and project pausing can trigger several minutes after you cross your spend amount.” Seats and add-ons are excluded.

Usage-based billing without a hard cap is a property of cloud generally, not Vercel specifically — Yan Cui made that point at the time, fairly. The difference is who owns the throttles. On AWS, the team that writes the CDK sets reserved concurrency on the function, puts a rate-based rule on the WAF in front of CloudFront, and can choose CloudFront’s flat-rate plans with no overage charges. Those knobs exist on Vercel only to the extent Vercel exposes them.

The bill is hard to model #

Vercel has repriced its compute three times in about fifteen months: metered SKUs in April 2024, Fluid compute in February 2025 promising up to 85% savings, and Active CPU pricing in June 2025 promising up to 90% for idle-heavy workloads. Each was framed as a cut. Each changed the unit you are billed on — from GB-hours to Active CPU hours plus provisioned memory plus invocations plus edge requests plus origin transfer.

Lambda’s GB-second model has not changed in years. A platform team can forecast it on a napkin. That stability is a feature for anyone whose job includes a budget.

Self-hosting Next.js caught up #

The strongest historical argument for Vercel was that Next.js outside Vercel was a degraded experience. That argument has expired.

The Next.js team’s own platform guide now says: “To run Next.js, your platform needs a Node.js server. That’s it.” A single next start “handles every Next.js feature correctly: Server Components, ISR, PPR, Cache Components, Server Actions, Proxy, and after().” And: “There are no private framework hooks or integration paths: Vercel’s adapter uses the same public API as every other adapter.”

OpenNext, whose AWS adapter is maintained by the SST community, covers App and Pages Router, SSR, SSG, ISR, middleware, image optimization, and use cache. SST wraps the roughly seventy AWS resources that make up a Next.js deployment into one component: new sst.aws.Nextjs("MyWeb", { link: [bucket] }), deployed to Lambda, CloudFront, and S3 in your account. Amplify Hosting supports Next.js 15 “without the need for an adapter,” with pull-request previews and atomic deployments, at $0.30 per million SSR requests and no seat fee.

If you would rather own it yourself, the pieces are a CloudFront distribution, an S3 bucket for static assets, a Lambda function URL for the server, and a cache handler. A team with CDK fluency has built that before, for something else, and has the constructs lying around.

Honest counterpoints #

Engineering time is not free. SST’s “around seventy low-level AWS resources” is the honest count. Self-hosting means you own multi-instance cache coordination, the Server Actions encryption key, deploymentId for skew protection, and the fact that an ALB with Lambda integration may buffer streaming responses. These are solved problems, but they are your problems now.

Parity is functional, not always performance. The Next.js docs distinguish functional fidelity from performance fidelity. PPR’s static shell at CDN latency and sub-second ISR propagation are what Vercel tunes. OpenNext’s page still says “some features are work in progress,” and Amplify is “not verified by the Next.js team.”

Idle-heavy workloads can genuinely be cheaper on Active CPU billing. If your functions spend most of their wall-clock waiting on a model API, paying only for active CPU is a real advantage over provisioned compute. Lambda bills wall-clock. For that specific shape, run the numbers both ways.

The decision #

The question is not “is Vercel good.” It is. The question is whether your organization already has the specialization Vercel is charging you not to need.

A frontend team without it: use Vercel. You will ship faster and the premium is cheap against the alternative of learning AWS under deadline.

A team with CDK or Terraform depth: the markup buys a renaming layer over Lambda and CloudFront, the controls you care about are behind an Enterprise contract, the spend cap is a notification, and the framework now runs everywhere on the same public API. Put the Next.js app in your own account, next to the rest of your infrastructure, governed by the same IAM, observed by the same dashboards, and paid for at list price.

You already did the hard part. Do not pay someone else for it twice.