Execute identify and avoid Vercel anti-patterns and common integration mistakes.
Use when reviewing Vercel code for issues, onboarding new developers,
or auditing existing Vercel integrations for best practices violations.
Trigger with phrases like "vercel mistakes", "vercel anti-patterns",
"vercel pitfalls", "vercel what not to do", "vercel code review".
Catalog of the most common Vercel anti-patterns with severity ratings, detection methods, and fixes. Organized by category: secret exposure, serverless function mistakes, edge runtime violations, configuration errors, and cost traps.
Prerequisites
Access to Vercel codebase for review
Understanding of Vercel's deployment model
Familiarity with vercel-common-errors for error codes
Instructions
Category 1: Secret Exposure (Critical)
P1: Secrets in NEXT_PUBLIC_ variables
// BAD — exposed in client JavaScript bundle, visible to anyone
const apiKey = process.env.NEXT_PUBLIC_API_SECRET;
// This value is inlined at build time into the browser bundle
// GOOD — server-only access
const apiKey = process.env.API_SECRET;
// Only accessible in serverless functions and server components
Fix: Move to environment variables, add pre-commit hook
P3: Secrets in vercel.json
// BAD — vercel.json is committed to git
{
"env": { "API_KEY": "sk_live_abc123" }
}
// GOOD — use Vercel dashboard or CLI
// vercel env add API_KEY production
Category 2: Serverless Function Mistakes (High)
P4: Heavy initialization at module level
// BAD — runs on every cold start, adds 500ms+
import { PrismaClient } from '@prisma/client';
const prisma = new PrismaClient(); // Connects on import
const cache = await loadLargeDataset(); // Blocks cold start
// GOOD — lazy initialization
let prisma: PrismaClient | null = null;
function getDb() {
if (!prisma) prisma = new PrismaClient();
return prisma;
}
export default async function handler(req, res) {
const db = getDb(); // Only connects on first request
// ...
}
P5: Not returning responses from all code paths
// BAD — some paths don't return, causing NO_RESPONSE_FROM_FUNCTION
export default function handler(req, res) {
if (req.method === 'GET') {
res.json({ data: 'ok' });
}
// POST, PUT, DELETE — no response returned!
}
// GOOD
export default function handler(req, res) {
if (req.method === 'GET') {
return res.json({ data: 'ok' });
}
return res.status(405).json({ error: 'Method not allowed' });
}
P6: Ignoring function timeout limits
// BAD — no timeout awareness, function silently killed
export default async function handler(req, res) {
const results = await processMillionRecords(); // Takes 5 minutes
res.json(results);
}
// GOOD — chunk work, respect timeout
export default async function handler(req, res) {
const batch = req.query.batch ?? 0;
const results = await processBatch(batch, 100); // Process 100 at a time
res.json({
results,
nextBatch: batch + 1,
done: results.length < 100,
});
}
P7: Connection pool exhaustion
// BAD — each function instance creates its own connection pool
// With 100 concurrent functions × 10 pool connections = 1000 DB connections
const pool = new Pool({ max: 10 });
// GOOD — use a connection pooler
// Use Prisma Accelerate, PgBouncer, or Supabase connection pooler
// Configure pool size to 1-2 per function instance
const pool = new Pool({ max: 2 });
Category 3: Edge Runtime Violations (High)
P8: Node.js APIs in edge functions
// BAD — these crash silently in Edge Runtime
export const config = { runtime: 'edge' };
import fs from 'fs'; // Not available
import path from 'path'; // Not available
import crypto from 'crypto'; // Use crypto.subtle instead
import { Buffer } from 'buffer'; // Use Uint8Array instead
// GOOD — Web Standard APIs
const hash = await crypto.subtle.digest('SHA-256', data);
const encoded = btoa(String.fromCharCode(...new Uint8Array(hash)));
// BAD — throws "Dynamic Code Evaluation not allowed"
export const config = { runtime: 'edge' };
const fn = new Function('return 42'); // Not allowed
eval('console.log("hi")'); // Not allowed
// GOOD — use static code only
const fn = () => 42;
Category 4: Configuration Errors (Medium)
P10: Missing environment variable scoping
# BAD — variable only in Production, preview deployments break
vercel env add DATABASE_URL production
# GOOD — add to all environments that need it
vercel env add DATABASE_URL production preview development
// BAD — middleware runs on every request including static files
export function middleware(request) { /* auth check */ }
// GOOD — exclude static assets
export const config = {
matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};
Category 5: Cost Traps (Medium)
P13: Uncached high-traffic endpoints
// BAD — every request invokes a function
export default function handler(req, res) {
res.json({ config: getConfig() }); // No cache headers
}
// GOOD — cache at the edge, save function invocations
export default function handler(req, res) {
res.setHeader('Cache-Control', 's-maxage=3600, stale-while-revalidate=86400');
res.json({ config: getConfig() });
}
P14: Over-allocated function memory
// BAD — 3GB for a simple JSON response
{
"functions": { "api/config.ts": { "memory": 3008 } }
}
// GOOD — right-size per endpoint
{
"functions": {
"api/config.ts": { "memory": 128 },
"api/image-process.ts": { "memory": 1024 }
}
}
P15: Middleware doing heavy work
// BAD — database query on every request
export async function middleware(request) {
const user = await db.user.findUnique({ where: { id: token.sub } });
// Runs on EVERY matched request, expensive at scale
}
// GOOD — validate JWT locally, no DB call
export function middleware(request) {
const token = request.cookies.get('session')?.value;
// Verify JWT signature locally (cheap, no external call)
}
