For Next.js applications Vercel is the path of least friction: connect the repository, push, live. For a single project that is enough. Running several products, processing customer data and wanting releases without surprises takes a few more deliberate decisions. We run our products and this website on Vercel; this article describes the patterns that have held up.
One project per product
Each product gets its own Vercel project with its own domain, environment variables and release rhythm. Shared building blocks — components, utilities, configuration — live in shared packages, not copies. That keeps a fault in one product confined to it and lets access rights be granted per product. Commercial products belong in a team on a paid plan; the free Hobby plan is not intended for commercial use.
Three environments, separate data
Vercel distinguishes Production, Preview and Development, and environment variables can be set per environment. The most important pattern is separating data: previews connect to their own database or Supabase project, never to production. Otherwise a pull request tests with real customer data, and a faulty migration step in a preview hits production. Keys with elevated privileges are used only server-side and never carry the prefix that exposes them in the browser.
Set the function region deliberately
On Vercel, server functions run in a US region unless configured otherwise. For products with data in the EU or Switzerland, the region should be close to the database, for example in Frankfurt. That is both a data protection and a performance question: every database query from the wrong region costs latency, and processing in the US is a disclosure abroad that needs justification. Static pages from the CDN are unaffected, which is why static generation pays off twice. More on location in our decision guide Swiss hosting or EU hosting.
Previews as the test bench
Every push and pull request creates a preview with its own URL. It is the best place to check changes before they go live. Two things belong with it: previews with real or realistic data should be protected with Vercel’s access protection, and previews should not end up in search engines. Vercel marks preview URLs as non-indexable for search engines by default; access protection still makes sense when content should not be public.
Checks before release
A green build is not the same as a correct release. For our websites, an automated check of the built output runs before every release: every sitemap URL must exist, have a correct canonical and valid structured data, and be linked internally. For applications, tests, type checking and an automated tenant-isolation test belong to it. These steps run in the CI/CD pipeline or before upload, not after release.
Rollbacks and migrations
Vercel lets you switch back to an earlier deployment with one click. That is a strong safety net for code, but not for data: a database migration shipped with the new code is not undone by a rollback. What works is designing migrations to be backward compatible — add columns first, switch code, remove old columns later — and putting risky features behind feature flags that can be turned off without a deployment.
Making operations visible
Logs, errors and performance belong in an overview you do not have to search for. Vercel provides logs and load-time metrics; for longer retention and alerts, connecting your own monitoring pays off. What matters is that errors report themselves rather than being found — more under observability. Field data on Core Web Vitals is covered in our article Core Web Vitals on Next.js and Vercel.
The most common mistakes
- Previews with access to the production database.
- Server functions in a different region from the database.
- Secret keys carrying the public-variable prefix.
- Rollback without a plan for migrations already executed.
- Commercial products on a personal plan.
The architecture behind this is described in our article on the Next.js App Router in production. For new products we set up this configuration from the start in our SaaS launch package.