Vercel Production Deployment Checklist for Next.js Apps

Before releasing a Next.js application on Vercel, check production configuration, caching, domain behavior, monitoring, and the recovery plan. Verify the deployed application as well as the preview.

Environment Configuration

• Separate environment variable scopes. Vercel's project settings distinguish between Development, Preview, and Production environments. Confirm that production secrets — database URLs, API keys, third-party credentials — are scoped to Production only and not leaking into Preview deployments where they could be exposed to broader team access.

• Audit every NEXT_PUBLIC_ variable. These are embedded in client-side JavaScript bundles and visible to anyone who inspects your site. They should contain only non-sensitive configuration: public API endpoints, analytics IDs, feature flag keys. Never put secrets in NEXT_PUBLIC_ variables.

• Verify environment variables are set before deploying. A missing variable can fail the build or a runtime request, depending on where it is read. After setting variables, trigger a fresh deployment and confirm the build log and function logs show no missing variable warnings.

• Review shared configuration. If several projects share configuration, record which projects and environments receive each value and review changes across those consumers.

Domain and DNS

• Add your custom domain before announcing the deployment. DNS propagation can take up to 48 hours for initial setup, though it typically completes in under an hour. Do not schedule launches for immediately after DNS changes.

• Verify SSL certificate provisioning. Vercel provisions Let's Encrypt certificates automatically, but this requires your DNS to point to Vercel's edge network first. Check that the certificate shows as valid in the Vercel dashboard before sending traffic.

• Set up www to apex redirects (or vice versa). Decide on your canonical domain and configure the other variant to redirect. Split traffic between www and apex fragments your SEO equity.

• Check redirect rules in vercel.json. If you have existing redirect or rewrite rules, verify they behave correctly in production. Redirect rules that worked in preview against a non-production base URL may produce unexpected behavior with your actual domain.

Caching and Headers

• Review Cache-Control headers for API routes. By default, Next.js API routes are not cached. If your API routes return data that is safe to cache (public, not user-specific), add appropriate Cache-Control headers. If they return user-specific data, confirm caching is disabled.

• Audit Next.js fetch caching behavior. Check the behavior for your Next.js version and route configuration. Current App Router documentation describes the default as auto no cache, with build-time prerendering and request-time behavior affecting when data is fetched. Use explicit settings where required and test the rendered route. Next.js fetch reference.

• Set correct revalidation periods for ISR pages. Incremental Static Regeneration pages serve stale content until the revalidation period expires. Confirm that your revalidate values match how frequently the underlying data actually changes.

• Test CDN cache behavior before launch. Use curl -I against your production URL and check x-vercel-cache headers. HIT means the response was served from cache; MISS or BYPASS means it was not. Confirm the caching behavior matches your intent for each route type.

Performance

• Run Lighthouse on your production URL, not localhost. Lighthouse scores against localhost miss network latency, server response time, and CDN behavior. Run it against the actual production domain after DNS is live.

• Verify image optimization is working. Next.js Image component should serve optimized, correctly-sized images. Check the Network tab in DevTools — images should be served as WebP where the browser supports it and at dimensions appropriate for the display size.

• Check bundle size. Run next build and review the output. Pages with unexpectedly large JavaScript bundles may indicate an import that belongs in a dynamic import or a server component rather than a client component.

• Test on a slow connection. Chrome DevTools Network throttling to "Slow 4G" reveals loading experience issues that fast office internet conceals.

Observability and Monitoring

• Enable performance measurement. Vercel Speed Insights reports field performance and Core Web Vitals; Web Analytics serves visitor analytics. Use the appropriate tool for each purpose. Speed Insights documentation.

• Enable Vercel Log Drain to your preferred logging destination. Vercel's built-in function logs are retained for a limited period. If your application logs are critical for debugging production issues, drain them to a persistent destination (Datadog, Logtail, Axiom, or similar).

• Set up uptime monitoring on your primary endpoints. An external monitor (Checkly, BetterUptime, or AWS CloudWatch Synthetics) provides confirmation that your site is reachable from outside Vercel's infrastructure. Internal health checks alone do not catch DNS or CDN issues.

• Create a Slack or PagerDuty alert for 5xx spikes. Vercel allows webhook-based deployment notifications. Pair that with your logging destination's alerting to create a signal when error rates exceed a threshold.

Rollback Readiness

• Know your rollback procedure before you need it. Vercel keeps a deployment history. Confirm which prior deployment can be restored and measure the recovery time for your application. Walk through this procedure before your first significant launch so it is not a learning exercise during an incident.

• Use Preview deployments for final verification. Preview and Production can use different environment variables, data, protection settings, and integrations. Verify the preview, document those differences, and smoke-test the production deployment.

• Notify stakeholders before and after deployment. Production deployments should not be silent events. A brief message in a shared channel before and after the deployment gives your team context if something goes wrong in the following hour.

After Launch

• Set a post-deployment observation window. Choose its length based on traffic and the changed workflows. Stay available and watch function logs and uptime monitoring.

• Confirm analytics and tracking are firing correctly. Check that your analytics events, conversion tracking, and any A/B testing tools are capturing data as expected in production. Preview environments often have different behavior for third-party tracking scripts.

• Document anything that required a manual step. If you had to manually set a header, modify a configuration, or contact support to resolve an issue, document it. The next deployment should have that step in the checklist.

Discuss Next.js deployment checks with LinkIT.