What Vercel deploys

Vercel takes your source code, builds it, and gives you back a deployment: a frozen copy of that build with its own URL. Then it points traffic at the deployment you choose. That is the whole idea, and most of this course is about doing it without surprises.

Vercel maintains Next.js, so the integration with it is the deepest one. But it’s not a Next.js-only host. It builds Astro, SvelteKit, Nuxt, plain Vite sites, and JavaScript or TypeScript backends too. And a Next.js app can run somewhere else. My advice is to keep the application code portable, and to know exactly which features depend on Vercel before you lean on them.

Three things to keep separate

I want you to hold three concepts apart, because the rest of the course depends on it.

A project is the container. It stores settings, environment variables, connected integrations, and the list of domains.

A deployment is one immutable build. Every deployment gets a unique URL that looks like field-notes-9k2m1x7de-flavio.vercel.app. That URL never changes what it serves.

A production domain is an alias. field-notes.vercel.app, or your own notes.flaviocopes.com, points at exactly one deployment. When you promote a new release or roll back to an old one, Vercel moves the alias. Neither deployment is touched.

Here is what that looks like from the terminal. The unique URL keeps serving the same build forever:

curl -sI https://field-notes-9k2m1x7de-flavio.vercel.app | head -1
# HTTP/2 200

If you run that a month from now, after ten more releases, you still get the same page.

Where immutability stops

Deployments are frozen. Everything around them is not.

Your Postgres database keeps changing. So do object storage, queues, the email provider, and every third-party API you call. A deployment from two weeks ago is unchanged, but the data it expects may be gone.

This is why “just roll back” is not always safe. The old code might assume a column you dropped, or a credential you rotated. Write down which external systems your app depends on, and in which environment each one lives.

Try this on your own project: list every piece of the Field Notes app, split into static assets, server-rendered routes, functions, scheduled work, storage, and external services. That list tells you what Vercel deploys and what it doesn’t.