Engineering a Serverless Email Adapter for Next.js and Vercel

Most email SDKs were built for long-running Node.js servers. They maintain connection pools, use global state, and assume they'll live for hours or days. Serverless functions are the opposite: they spin up in milliseconds, handle a single request, and die. Building an email SDK that works correctly in both environments required rethinking several assumptions.

The connection problem

Traditional SMTP clients maintain a persistent TCP connection to the mail server. In a serverless environment, there's no such thing as a persistent connection — each function invocation is a fresh process. Our adapter uses Sendbound's HTTP API rather than SMTP, which maps naturally to the stateless request/response model of serverless functions. No connection warming, no pool management, no timeouts from idle connections.

Edge runtime compatibility

Vercel Edge Functions and Cloudflare Workers run in a limited JavaScript environment that doesn't include Node.js APIs — no fs, no net, no crypto module. Our adapter is built on the Web Fetch API and the Web Crypto API, which are available in all edge runtimes. The bundle size is 4.2kb gzipped, small enough to deploy to edge without impacting cold start times.

Usage in Next.js

The Next.js adapter exports a sendEmail function that works identically in API routes, Server Actions, and Route Handlers. It detects the runtime environment automatically and uses the appropriate transport. In development, it optionally routes to a local preview that renders your email in the browser instead of sending it, saving you from cluttering your test inbox during development.