Cloudflare Workers: SSL Termination for Vercel Custom Domains
Learn how to implement custom domain SSL termination using Cloudflare Workers to enhance Vercel security and maintain centralized edge control.
When you're scaling an application on Vercel, you eventually hit a wall: the need for more granular control over how your traffic is decrypted and inspected before it hits your origin. While Vercel handles SSL automatically, some enterprise requirements demand that you manage your own certificates or intercept traffic at the edge for custom security logic.
We recently moved a high-traffic client from a standard Vercel setup to a hybrid model using Cloudflare Workers. It gave us the edge-side control we were missing, allowing us to implement custom SSL termination and request filtering without moving the actual application code.
Why move SSL termination to the edge?
Vercel's default SSL management is excellent for 99% of use cases. However, if you need to perform mTLS (mutual TLS), inject specific security headers that require dynamic evaluation, or simply want to centralize your security posture across multiple providers, you need a custom layer.
We initially tried to handle this with standard Vercel Middleware, but it proved too restrictive for complex header manipulation at the TLS handshake level. Switching to Cloudflare Workers allowed us to handle the logic before the request even reached Vercel's ingress.
Implementing the logic
By placing a Cloudflare Worker in front of your Vercel custom domain, you can effectively "terminate" the connection at the edge. You maintain your own custom SSL certificates within Cloudflare, and the Worker acts as the bridge.
Here is a simplified pattern for intercepting and forwarding requests:
TYPESCRIPT// src/index.ts export default { async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> { const url = new URL(request.url); // Custom logic: Add security headers or perform auth const newRequest = new Request(request); newRequest.headers.set("X-Custom-Security-Header", "enabled"); // Forward to Vercel origin return fetch(CE9178">`https://your-vercel-deployment.vercel.app${url.pathname}`, newRequest); } };
This approach works seamlessly with the new Workers Cache, which lets you define caching behavior directly in your code. You can effectively offload repetitive tasks—like validating tokens or serving static assets—to the cache, saving you CPU time and reducing latency.
Handling Security and Compliance
If you're operating in a regulated environment, you might be interested to know that Cloudflare recently joined the UK government's Cyber Resilience Pledge. Leveraging their infrastructure for SSL termination means you're inheriting a hardened edge that already handles an average of 234 billion threats daily.
Beyond basic termination, you can extend your security by integrating custom WAF rules, as we've explored in our guide on Vercel Security: Implementing Custom WAF Rules with Cloudflare Workers. It’s a powerful way to ensure that only legitimate traffic reaches your Vercel environment.
Comparison: Vercel Native vs. Cloudflare Edge
| Feature | Vercel Native | Cloudflare Workers |
|---|---|---|
| SSL Management | Automated | Custom/Managed |
| Edge Logic | Middleware (Limited) | Full Worker Runtime |
| WAF Control | Basic | Granular/Custom |
| Deployment | Integrated | Independent |
Key Takeaways
Don't over-engineer this if you don't have to. If Vercel's standard SSL meets your compliance needs, stick with it. But if you find yourself needing to perform complex edge-side routing or custom authentication—check out our deep dive on Cloudflare Workers Authentication: Securing Vercel Edge Middleware—the trade-off is worth the effort.
Next time, I’d probably spend more time testing the latency impact of multiple redirects. While the overhead is usually around 20-50ms, it adds up if your architecture isn't optimized for cold starts. We're still monitoring the long-term impact on our Vercel ingress costs, but the visibility we've gained at the edge has been invaluable.
Frequently Asked Questions
Does this replace Vercel's built-in SSL? No, it sits in front of it. You keep your Vercel domain active, but you point your DNS to Cloudflare and use the Worker to proxy the traffic to your Vercel origin.
Can I still use Vercel's edge functions? Yes. The Cloudflare Worker handles the initial request, then forwards it to Vercel. Your Vercel edge functions will still execute as usual once the request reaches the Vercel network.
Is this expensive? Cloudflare Workers have a generous free tier. Unless you're dealing with massive, hyper-volumetric traffic spikes, the base cost is usually negligible compared to the security benefits.