Deploy a Next.js Template to Vercel (2026)

Deploy a Next.js Template to Vercel in 2026

Vercel is the path of least resistance for Next.js. The setup is fast, the developer experience is excellent, the free tier is enough for a meaningful early-stage product, and the platform handles the infrastructure decisions that would otherwise cost weeks. Most teams should default to Vercel and revisit the decision only at scale.

This guide walks the full deployment: GitHub setup, environment variables, custom domains, cron jobs, ISR (incremental static regeneration), edge config, and the gotchas that have cost real teams a launch day.

---

Get a kit pre-configured for Vercel: $499 for all

Every thefrontkit kit is configured for Vercel out of the box. Push to GitHub, connect the repo, set env vars, deploy. All Access unlocks every kit on thefrontkit for $499 one-time.

---

Why Vercel for Next.js in 2026

The alternatives:

• Self-host on Coolify, Railway, or Render — cheaper at scale, more operational work
• Cloudflare Pages — works for Next.js with Workers, gets you better global edge performance, more setup
• AWS Amplify — solid but the DX is worse than Vercel
• Bare metal (Hetzner, OVH) — cheapest, requires Kubernetes or Docker Compose

Vercel wins for most teams because:

• Built by the Next.js team, so framework features ship with first-class platform support
• Zero-config preview deploys for every PR
• Automatic image optimization
• Built-in edge runtime, ISR, and cron
• The free tier covers most pre-revenue products

The cost is roughly $20/month per developer at the Pro tier, which most teams cross within 3-6 months of being serious about a product.

Step 1: Push the Template to GitHub

If you cloned a template locally:

git init
git add .
git commit -m "Initial commit"
gh repo create my-product --private --source=. --remote=origin --push

Or use the GitHub UI: create a new repo, push your local code.

Public vs private is a personal choice. Most paid templates require keeping the source private per the license. Always check the license before pushing publicly.

Step 2: Import the Project to Vercel

1. Go to vercel.com/new
2. Import your GitHub repository (you'll be prompted to grant Vercel access)
3. Vercel auto-detects the framework (Next.js)
4. Click Deploy

The first deploy runs without any env vars set, which usually fails. That's expected — set them in Step 4 and redeploy.

Step 3: Configure the Build

Vercel auto-detects most Next.js configs, but verify:

• Framework Preset: Next.js
• Build Command: next build (or whatever your package.json says)
• Output Directory: .next (Vercel auto-handles this)
• Install Command: npm install (or pnpm install, yarn install)
• Root Directory: the path to your Next.js app if it's in a subfolder

For monorepos (e.g., Turborepo), set the Root Directory to the Next.js app's path (apps/web or similar).

Step 4: Set Environment Variables

This is where most first deploys fail. The .env.local you use locally is not uploaded to Vercel. You set them in the dashboard.

Project > Settings > Environment Variables. Add every variable from your .env.local:

NEXT_PUBLIC_SUPABASE_URL=https://...
NEXT_PUBLIC_SUPABASE_ANON_KEY=...
SUPABASE_SERVICE_ROLE_KEY=...
DATABASE_URL=...
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=...
CLERK_SECRET_KEY=...
STRIPE_SECRET_KEY=...
STRIPE_WEBHOOK_SECRET=...

For each variable, pick the environments: Production, Preview, Development. Most secrets should be in all three, with the test/sandbox values for Preview and Development and the live values for Production.

Mistake to avoid: putting production Stripe keys in Preview. That means every preview deploy can charge real cards. Always use test keys in Preview.

Step 5: Add a Custom Domain

1. Project > Settings > Domains
2. Add your domain (e.g., mysaas.com)
3. Vercel gives you DNS records to add to your registrar (usually A and CNAME)
4. Add them at your registrar (Cloudflare, Namecheap, Porkbun, etc.)
5. Wait for DNS propagation (usually under an hour, sometimes up to 48)

Once verified, your domain serves the production deployment. Vercel provisions an SSL certificate automatically.

For www redirect: add both mysaas.com and www.mysaas.com, mark one as primary, and Vercel handles the redirect.

Step 6: Wire Up Preview Deployments

Vercel automatically creates a preview deploy for every PR. This is free magic.

For each PR, Vercel:

• Builds the branch
• Deploys it to a unique URL (my-product-git-feature-abc.vercel.app)
• Posts the URL as a comment on the PR
• Updates the deploy when you push new commits

For these to work correctly with auth, payments, etc., make sure your Preview env vars use test/sandbox credentials. Otherwise every PR preview hits production data.

Step 7: Set Up Cron Jobs

Many SaaS apps need scheduled jobs (publish scheduled posts, send digest emails, sync usage data). Vercel Cron handles this.

In your project root, create vercel.json:

{
  "crons": [
    {
      "path": "/api/cron/publish-scheduled-posts",
      "schedule": "* * * * *"
    },
    {
      "path": "/api/cron/send-digest",
      "schedule": "0 9 * * *"
    },
    {
      "path": "/api/cron/sync-usage",
      "schedule": "0 */6 * * *"
    }
  ]
}

Each cron hits a GET endpoint on the schedule (standard cron syntax). Secure each endpoint:

// app/api/cron/publish-scheduled-posts/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function GET(req: NextRequest) {
  const authHeader = req.headers.get('authorization');
  if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
    return new NextResponse('Unauthorized', { status: 401 });
  }

  // Do the scheduled work
  const posts = await db.post.findMany({
    where: { status: 'scheduled', publishAt: { lte: new Date() } },
  });

  for (const post of posts) {
    await db.post.update({ where: { id: post.id }, data: { status: 'published' } });
  }

  return new NextResponse('OK');
}

Set CRON_SECRET in env vars. Vercel automatically sends it in the Authorization header.

Free tier includes basic cron; high-frequency cron (every minute) requires Pro.

Step 8: Configure ISR (Incremental Static Regeneration)

For pages that should be cached but occasionally update (blog posts, product pages, marketing pages), use ISR.

export const revalidate = 60; // re-generate this page every 60 seconds

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await db.post.findUnique({ where: { slug: params.slug } });
  return <article>{post.content}</article>;
}

The first request after revalidate seconds gets the new content (or the regen happens in the background). Other requests get the cached version.

For on-demand revalidation (e.g., after publishing a post), call:

import { revalidatePath } from 'next/cache';
revalidatePath(`/blog/${slug}`);

This invalidates the cache for that path immediately. Combine with the publish flow so new posts appear instantly.

Step 9: Edge Config (for Feature Flags)

For values that change frequently but should be globally available (feature flags, A/B test cohorts, kill switches), use Edge Config:

import { get } from '@vercel/edge-config';

export async function MyComponent() {
  const isFeatureEnabled = await get('newDashboard');
  return isFeatureEnabled ? <NewDashboard /> : <OldDashboard />;
}

Edge Config reads are <1ms globally. Writes are slow but rare. Perfect for kill switches and flags.

Not necessary for v1 of most products. Add when you need it.

Step 10: Monitor Performance

Vercel Analytics tracks Core Web Vitals out of the box. Project > Analytics. Free tier includes basic stats; Pro tier has detailed segmentation.

Pair with:

• Sentry for errors (in both frontend and API routes)
• PostHog for product analytics
• Better Stack for uptime alerting

These are not Vercel features; they're third-party but Vercel has first-class integrations.

Common Gotchas

Forgetting environment variables. The first deploy fails because env vars from .env.local are not on Vercel. Add them in Settings > Environment Variables.

Production keys in Preview. Every PR preview charges real cards or hits production data. Use test/sandbox creds in Preview.

Image optimization not working. Make sure next/image is used and external image hosts are listed in next.config.js:

module.exports = { images: { remotePatterns: [{ protocol: 'https', hostname: '**' }] } };

Webhook URLs pointing to localhost. Production webhooks (Stripe, Razorpay, Clerk) need your Vercel domain. Update the URLs in each provider's dashboard when you deploy.

Cron not firing. Check the schedule syntax. * * * * * is every minute; 0 9 * * * is 9 AM daily. Cron times are UTC. Verify in the Vercel dashboard under Crons.

API routes timing out. Vercel free tier has a 10-second timeout on serverless functions. Pro raises it to 60 seconds. For longer jobs, use background queues (Inngest, Trigger.dev) not API routes.

Massive serverless function size. If you import too much in an API route, the function bundle exceeds Vercel's limit (50 MB unzipped). Symptoms: deploy fails with size error. Fix: move heavy imports into separate files or use route segment config.

Cold starts on infrequent endpoints. Serverless functions cold-start on first hit after idle. For latency-critical paths, use Edge functions or schedule a warmup cron.

DNS propagation delays. New domains can take up to 48 hours to fully propagate. Don't promise a launch time that depends on instant DNS.

Confusing Production and Preview. Every push to main goes to Production. Every push to a feature branch goes to Preview. Don't push to main without verifying.

Adjacent Reads

• How to Build a SaaS in Next.js — broader build path
• Connect Supabase to a Next.js Template — pair with database
• Add Stripe Payments to a Next.js Template — pair with payments
• Add Clerk Auth to a Next.js Template — pair with auth

FAQ

Is Vercel free for production use? Yes, with limits. Free tier: 100 GB bandwidth, 1,000 serverless function invocations per day per region, basic Cron, basic Analytics. For pre-revenue or low-traffic products, free is enough. Above that, $20/month per developer covers most teams up to several million pageviews.

Should I self-host Next.js instead of using Vercel? For most teams, no. Vercel's pricing is reasonable, the platform handles infrastructure decisions you'd otherwise need to make, and the integration with Next.js features is tight. Self-host when: you have a dedicated infrastructure engineer, you have specific compliance requirements that Vercel doesn't meet, or you're at large scale (millions of MAU) where the cost math flips.

Can I deploy a Next.js Template to Cloudflare Pages? Yes, with caveats. Cloudflare Pages supports Next.js via the OpenNext adapter, which compiles Next.js to Cloudflare Workers. Most features work; some (like the Image component's automatic optimization and middleware) require specific configuration. Cloudflare wins on global edge latency and pricing at scale. Vercel wins on DX and feature support.

How do I roll back a bad deploy? Vercel keeps every deploy. In the dashboard: Deployments > pick the last good one > Promote to Production. Instant rollback. For automated rollbacks based on error rate, use Vercel's deployment protection or your monitoring tool (Sentry, Better Stack).

Do I need a CDN in front of Vercel? No. Vercel's network is already a CDN with edge caching globally. Adding Cloudflare in front of Vercel usually hurts more than it helps because the two caches can fight. The exception: if you need Cloudflare's specific features (WAF, bot protection, custom workers), you can put Cloudflare in CDN-only mode in front of Vercel.

How do I handle env vars for multiple environments? Vercel has Production, Preview, and Development environments. Set different values per environment in the dashboard. For local dev, use .env.local (gitignored). For local testing of production-like behavior, use vercel env pull to download env vars to .env.local.production.