Ship at the edge, measure at the user.
Vercel is where we host Next.js when speed, preview environments and a small operations surface matter more than owning the cluster. Edge functions, ISR and Core Web Vitals budgets, done properly.
- Vercel
- Next.js
- TypeScript
- Payload CMS
- PostgreSQL
- Redis
Built by the team behind Next.js.
Vercel is the platform built by the team behind Next.js, and it shows: server components, incremental static regeneration, image optimisation, edge middleware and preview deployments all work without configuration. For a product team, that means every pull request gets its own URL, every route can be cached exactly as long as the content allows, and the first byte arrives from a location near the user rather than from one region.
We use it for the surfaces where those properties are the product — marketing and commerce sites, customer portals, content-heavy applications built on Next.js and Payload. The performance budgets we set in our web application work are easier to hold when the platform is doing the caching and the CDN well by default.
When we don’t: the edge is a thin layer, not a place to run your business logic. Heavy back-ends, long-running jobs, stateful services and anything with strict data-residency rules run on Kubernetes in AWS, Azure or Google Cloud. Vercel sits in front of them; it does not replace them.
Six things we ship on Vercel.
Next.js front ends with ISR
Static where possible, regenerated on demand when content changes, server-rendered where it must be — per route, decided on purpose, documented in the repo.
Edge middleware
Geo-routing, locale detection, A/B allocation, bot filtering and auth checks that run before the request reaches an origin.
Preview environments per pull request
Every change gets a URL that product, design and QA can open — with a database branch behind it where the stack supports one, so previews are not sharing production data.
Commerce and campaign surfaces
High-traffic launch pages, retail campaign microsites and loyalty programme portals that must hold their Core Web Vitals under a spike.
AI-backed streaming interfaces
Assistant and search experiences that stream model responses through edge or serverless functions, with the models from our LLM practice behind a rate-limited API.
Front-door for a private back-end
Vercel serving the UI, with server actions and route handlers calling a private API in your cloud over a secure connection — a pattern suited to enterprise portals.
When to choose it.
Choose Vercel when the application is Next.js and the value is in the front end; when the team is small and does not want to operate a CDN, a build farm and a preview system themselves; when global latency matters and a single-region origin is the bottleneck; and when the per-request pricing is cheaper than the platform engineers it replaces. It suits marketing sites, portals, storefronts, dashboards and content products.
Look elsewhere when data-residency or regulatory rules require every byte to stay inside a named region or your own network — a common constraint in banking and public sector, where we host the whole stack on your cloud. Look elsewhere too for heavy compute, long-running or stateful workloads, and for applications with very high sustained traffic where a self-managed CDN and Kubernetes become the cheaper bill. We model the cost both ways before recommending.
Edge middleware for locale and a feature flag.
import { geolocation, ipAddress } from '@vercel/functions'
export const config = { matcher: ['/((?!_next|api|assets).*)'] }
export function middleware(req: NextRequest) {
const country = geolocation(req).country ?? 'TR'
const locale = req.cookies.get('locale')?.value ?? (country === 'TR' ? 'tr' : 'en')
// Rewrite, don’t redirect — the URL the user sees stays clean
const url = req.nextUrl.clone()
url.pathname = `/${locale}${url.pathname}`
const res = NextResponse.rewrite(url)
+ res.headers.set('x-variant', bucket(ipAddress(req) ?? '', 'checkout-v2', 0.1))
res.headers.set('Cache-Control', 'public, s-maxage=60, stale-while-revalidate=300')
return res
}Vercel in front of a private back-end.
What the Vercel deployments we hand over have.
- Core Web Vitals budgets per route — LCP, CLS and INP — checked with Lighthouse CI on every preview and by real-user monitoring after launch. A regression fails the build.
- A written caching strategy. Each route states whether it is static, ISR with a revalidation window, or dynamic, and why. Nothing is cached by accident.
- Edge functions kept thin. No database calls, no secrets beyond what the check needs, a stated latency budget and a test that proves it.
- Environment discipline: production, preview and development variables separated, secrets kept out of the repo, and preview deployments protected from public crawling.
- Security headers and CSP set in
next.config, verified in CI, with a report-only period before enforcement. - Playwright end-to-end tests run against the preview URL of every pull request, not against localhost.
- Cost visibility: function invocations, bandwidth and image transforms tracked regularly, at a rhythm agreed with you, with alerts before an unexpected bill.
- An exit path documented. The Next.js application also builds as a standard container, so moving to your own cloud does not have to mean a rewrite.
What usually ships alongside the code.
- Next.js application with a route-by-route rendering and caching map
- Vercel project configuration, domains, environments and access controls as code where possible
- Edge middleware with tests and a stated latency budget
- Lighthouse CI budgets and a real-user monitoring dashboard
- Preview workflow: branch → preview URL → Playwright suite → promotion
- Runbook covering rollback, cache purge, incident response and regular cost reviews, at a rhythm agreed with you
Frequently asked questions
Neighbouring stacks and the services that use them.
The front end fast, the back end where it belongs.
Tell us what you are shipping and who has to see it first. An engineer reads it and replies in writing with how we would approach it.