Why I Moved My SaaS API Routes to Cloudflare Workers

When I first started building SaaS products, I spent the first two weeks just wiring up the boring stuff. You know the drill: configuring authentication, setting up Stripe webhooks, and building the database schema. By the time I actually got to write the core feature, I was exhausted.

But the real frustration hit me later. I’d launch the product, and users in Europe or Asia would complain about sluggish API responses. I was using standard serverless functions, which were great for quick setup but routed all my traffic through a single US region. I was spending more time tweaking caching headers and regional routing than actually improving the product.

So I decided to build something. I wanted a boilerplate that didn't just give me the standard auth and billing setup, but also baked in edge computing from day one.

The Hidden Cost of Regional Serverless

When you're building a global SaaS, latency is a silent killer. If your API routes are hosted in us-east-1, a user in Tokyo is adding roughly 150-200ms of network latency to every single request before your code even executes.

For a standard CRUD app, this might be fine. But if you're building tools that require fetching external data, parsing HTML, or running heavy computations, that latency compounds. The cost of ignoring it isn't just a slightly slower app; it's user churn. People expect instant feedback. If your tool takes three seconds to return a result because of network hops, they'll assume it's broken and bounce.

I realized that to build a truly global SaaS, the compute needed to be as close to the user as the CDN.

A Hybrid Edge Architecture

My approach was to build a hybrid architecture. I didn't want to abandon the Next.js ecosystem, because the App Router in Next.js 14+ is fantastic for UI and standard data fetching. But I needed to offload latency-sensitive tasks to the edge.

I built SaaSLaunch as a TypeScript-first boilerplate that combines Next.js for the frontend and standard API routes, with Cloudflare Workers handling the heavy, global edge tasks.

For authentication, I stuck with NextAuth.js. It handles OAuth providers cleanly and integrates well with the App Router. For billing, I kept the Stripe checkout session creation in a standard Next.js API route, because it requires secure, stateful backend logic that benefits from the standard Node.js environment.

Here is what that Stripe integration looks like in the App Router:

// Next.js API route for Stripe checkout (App Router)
import { NextResponse } from 'next/server';
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const { priceId, userId } = await req.json();

  const session = await stripe.checkout.sessions.create({
    mode: 'subscription',
    payment_method_types: ['card'],
    line_items: [{ price: priceId, quantity: 1 }],
    success_url: `${process.env.APP_URL}/dashboard?success=true`,
    cancel_url: `${process.env.APP_URL}/pricing?cancelled=true`,
    client_reference_id: userId,
  });

  return NextResponse.json({ url: session.url });
}

But for things like the built-in SEO checker and landing page analyzer, I moved the logic entirely to Cloudflare Workers.

The challenge with edge computing is that you don't have access to the full Node.js API. You can't just npm install a heavy DOM parser like jsdom and expect it to run efficiently on the edge. You have to write lean, edge-compatible code.

Here is how I built the edge SEO analyzer using a Cloudflare Worker. Instead of parsing the DOM, I fetch the raw HTML and use regex to extract the critical SEO tags. This keeps the worker incredibly lightweight and fast.

// Cloudflare Worker for edge SEO analysis
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname !== '/api/analyze') {
      return new Response('Not found', { status: 404 });
    }

    const targetUrl = url.searchParams.get('url');
    if (!targetUrl) {
      return new Response(JSON.stringify({ error: 'Missing url' }), {
        status: 400,
        headers: { 'Content-Type': 'application/json' },
      });
    }

    // Fetch target page at the edge (low latency worldwide)
    const response = await fetch(targetUrl, {
      cf: { cacheTtl: 300, cacheEverything: true },
    });
    const html = await response.text();

    // Run SEO checks (regex-based, no DOM needed)
    const title = html.match(/<title[^>]*>([^<]*)<\/title>/i)?.[1] || '';
    const desc = html.match(/<meta[^>]*name=["']description["'][^>]*content=["']([^"']*)["']/i)?.[1] || '';
    const h1Count = (html.match(/<h1[ >]/gi) || []).length;

    return new Response(JSON.stringify({ title, desc, h1Count }), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

By using the cf cache properties in the fetch request, the worker can cache the target page's HTML at the edge for 5 minutes. This means if multiple users check the same URL, subsequent requests are practically instant.

Practical Results and Lessons Learned

Moving to this hybrid model changed how I build. The TypeScript-first setup across both Next.js and the Workers meant I caught type errors before they ever reached production.

What worked really well was the deployment. Having one-click deployment to both Vercel (for the Next.js frontend) and Cloudflare Pages/Workers (for the edge API) removed a massive amount of DevOps overhead. I could just push to main and let the CI handle it.

What surprised me was how much faster the SEO tools felt. Because the Cloudflare Worker runs in over 300 locations globally, the time-to-first-byte for the analysis dropped significantly for international users.

If I could change one thing, it would be my initial temptation to put everything in Workers. I originally tried to move the Stripe webhook handling to the edge. It was a mistake. Debugging edge environments without full Node.js modules was frustrating, and webhooks require specific retry logic that is easier to handle in a standard serverless function. I pulled it back to a standard Next.js route, and it was much more stable. The lesson I learned is that the edge is powerful, but it's a tool, not a silver bullet. Use it where latency matters most.

Try the Edge SEO Analyzer

If you want to see this edge architecture in action, I've deployed the SEO checker as a free tool. You can paste any URL, and it will run the analysis using the exact Cloudflare Worker setup I described above, giving you instant feedback on your title tags, meta descriptions, and H1 counts.

You can try the free SEO Checker here: https://saaslaunch.dev/free-tools/seo-checker

---

Full disclosure: I'm the developer of SaaSLaunch. I built this because I needed it myself.