Vercel & Netlify

01What they actually do

Think of these platforms as a build server, a CDN and a serverless runtime glued together by Git. When you push, the platform clones the repo, detects the framework, runs the build command, and splits the output. Static files (HTML, CSS, JS, images) go to a global CDN with long caching. Server code (API routes, server-rendered pages, server actions) is packaged into functions that run on demand in one or more regions. Middleware or edge functions run before the cache on a lightweight runtime close to the user. Every deployment is immutable and has its own URL; "production" is just an alias that points at one of them. That is why rollback is instant: you move the alias back to an older deployment, nothing is rebuilt. Compared with a VPS, you no longer think about servers, but you do think about function duration, regions, caching headers and the bill.

• Static assets → CDN. Server code → functions. Middleware → edge.
• Every deploy is immutable; production is an alias.
• Preview deployments per branch or pull request.

02Setting up a project step by step

Create an account, import the repository from GitHub, GitLab or Bitbucket, and accept the detected framework settings. The first deploy usually works without changes. Then do the real setup. Add environment variables per environment (Production, Preview, Development) in the dashboard, and never let preview builds use production secrets or the production database. Add your custom domain: point an apex domain with an A record or ALIAS, and a www subdomain with a CNAME, as the platform instructs; certificates are issued automatically. Protect previews with the platform's deployment protection if they show unreleased work. Set the function region to the same region as your database. Finally, connect the CLI for local work: it pulls environment variables and can reproduce the platform's build locally.

1# Vercel
2npm i -g vercel
3vercel link              # connect this folder to a project
4vercel env pull .env.local
5vercel                   # preview deploy
6vercel --prod            # production deploy
7 
8# Netlify
9npm i -g netlify-cli
10netlify link
11netlify dev              # local server with functions and redirects
12netlify deploy --prod

03Rendering and caching: static, ISR, SSR, edge

Where your page is rendered decides speed and cost. Static pages are built once and served from the CDN: fastest and nearly free. Incremental Static Regeneration (ISR) serves a cached page and regenerates it in the background after a revalidate period, or on demand when your CMS calls a revalidation endpoint, so you get static speed with fresh content. Server-side rendering runs a function on every request: needed for personalised pages, but each request costs function time. Middleware runs before the cache on every matching request, so keep it tiny: redirects, rewrites, auth cookie checks, A/B bucketing. Both platforms honour standard Cache-Control headers, and Vercel also reads CDN-Cache-Control and Vercel-CDN-Cache-Control for CDN-only rules. Netlify uses Netlify-CDN-Cache-Control and supports cache tags for targeted purges. A good rule: render static by default, ISR for content, SSR only where the response truly depends on the request.

1// app/blog/[slug]/page.tsx (Next.js App Router)
2export const revalidate = 3600; // regenerate at most once per hour
3 
4export async function generateStaticParams() {
5  const posts = await fetch("https://cms.example.com/posts").then((r) => r.json());
6  return posts.map((p: { slug: string }) => ({ slug: p.slug }));
7}
8 
9export default async function Post({ params }: { params: Promise<{ slug: string }> }) {
10  const { slug } = await params;
11  const post = await fetch("https://cms.example.com/posts/" + slug, {
12    next: { tags: ["post-" + slug] },
13  }).then((r) => r.json());
14  return <article><h1>{post.title}</h1></article>;
15}

04Functions: limits and how billing works

Both platforms run your server code as functions, mostly on Node.js. On Vercel, functions use Fluid compute by default: one instance can serve many concurrent requests, which reduces cold starts and cost for I/O-heavy work such as calling a database or an AI API. Billing is by active CPU time, provisioned memory and invocations, so time spent waiting on network costs much less than raw duration. Edge Functions and middleware run on a lighter V8 runtime; Vercel now recommends the Node.js runtime for most functions. Netlify Functions run on AWS Lambda under the hood, and Netlify Edge Functions run on Deno at the edge. Netlify uses a credit-based plan model: deploys, compute, bandwidth and requests each consume credits from a monthly allowance. Both have maximum durations, request body size limits and memory limits per plan, so long jobs belong in a queue or a background worker elsewhere.

05Plans and pricing traps

Vercel's Hobby plan is free but for personal, non-commercial use only; client and company projects need Pro, which is priced per seat with a monthly usage credit, then pay-as-you-go. New Pro teams get a default spend budget with alerts and an option to pause projects at the limit: keep that on. Netlify has Free, Personal and Pro plans with a monthly credit allowance; when credits run out, sites can be paused unless you buy more or enable auto recharge. The traps are similar on both: a viral page that is server-rendered on every request, large unoptimised images or video served as bandwidth, bots hitting dynamic routes, image optimisation on thousands of source images, and preview builds triggered by every commit in a busy monorepo. Check prices on the official pricing pages before a client decision; both companies change their models regularly.

• Hobby on Vercel is non-commercial: client work needs Pro.
• Turn on spend limits or budget alerts on day one.
• Cache aggressively; uncached SSR is where bills grow.

06How the request path works: routing, cache and functions

A request reaches the nearest edge location. First, platform routing rules run: redirects, rewrites and headers from your framework or config files. Then middleware runs if it matches. Next the CDN cache is checked using the URL and any cache keys or Vary headers. A cache hit returns immediately and costs only a CDN request and bandwidth. A miss invokes the function in its configured region, which may be far from the edge, so every miss pays the edge-to-region trip plus your database round trips. Stale-while-revalidate lets the CDN serve stale content while refreshing in the background. Cookies are the hidden enemy of caching: a response that depends on a session cookie must not be shared, so split pages into a cached shell and small personalised parts loaded on the client or streamed.

1// next.config.ts: long cache for a public API route, revalidated in the background
2import type { NextConfig } from "next";
3 
4const config: NextConfig = {
5  async headers() {
6    return [
7      {
8        source: "/api/public/:path*",
9        headers: [{ key: "Cache-Control", value: "public, s-maxage=300, stale-while-revalidate=86400" }],
10      },
11    ];
12  },
13};
14 
15export default config;

07Connections to databases from serverless functions

Functions scale out by creating more instances, and each instance that opens its own TCP connections to Postgres can exhaust the database's connection limit under load. Three tools solve this. First, put a pooler in front of the database: PgBouncer, the pooled endpoint of a managed provider, or Prisma Accelerate, and use transaction mode. Second, prefer drivers designed for serverless, such as HTTP or WebSocket drivers from serverless Postgres providers, for edge and short-lived functions. Third, with Vercel Fluid compute an instance serves many requests, so a small module-level pool is reused efficiently; use the waitUntil or attachDatabasePool helpers so idle connections are closed before the instance is suspended. Always put the function region next to the database: one region hop per query, multiplied by ten queries per page, is the difference between 50 and 500 milliseconds.

08Security: secrets, previews and the edge

Environment variables are encrypted at rest, but anything prefixed for the client (NEXT_PUBLIC_, PUBLIC_, VITE_) is inlined into the browser bundle: treat those as public. Scope sensitive variables to Production only, and mark them sensitive so they cannot be read back from the dashboard. Previews are a real attack surface: a pull request from a fork could run code at build time with your secrets, which is why the platforms do not expose secrets to fork builds by default; keep it that way. Use deployment protection (password, SSO or Vercel Authentication) for previews of unreleased work, and add an X-Robots-Tag noindex header so they are never indexed. Turn on the firewall and bot protection features for login and API routes, and add rate limiting for expensive endpoints, since every abusive request is billed function time.