Migrating a live SaaS from Vercel + Supabase to a single Cloudflare Worker

A developer migrated the live SaaS ReddTrends from Next.js on Vercel with Supabase to a single Cloudflare Worker, using TanStack Start and D1. The migration preserved user passwords by overriding Better Auth's verification to support legacy bcrypt hashes, and used an idempotent import process to move data from Postgres to SQLite. The weekly AI pipeline and daily emails now run via Worker Cron Triggers.

I run ReddTrends https://reddtrends.com . It reads Reddit every week and scores what founders are complaining about into niche opportunities, with GO / WATCH / AVOID verdicts. A few hundred users, a weekly AI pipeline, a daily email job. Last Tuesday I moved it off Next.js on Vercel + Supabase and onto one Cloudflare Worker. Same domain, Creem subscriptions live the whole time. Four things were worth writing down: the password hashes, the D1 import, the weekly pipeline, and one payment row I deleted by accident. | Before | After | | |---|---|---| | App | Next.js on Vercel | TanStack Start + React 19 on Cloudflare Workers | | DB | Supabase Postgres | Cloudflare D1 SQLite | | Auth | Supabase Auth GoTrue | Better Auth | | Weekly AI pipeline | GitHub Actions cron → one long HTTP endpoint | Worker Cron Trigger → Cloudflare Workflows | | Daily emails | GitHub Actions cron | Worker Cron Trigger | | Inbound mail | Zoho | Cloudflare Email Routing | | Outbound mail | Resend | Resend unchanged | | Files / cache | — | R2 + Workers KV | Row 3 is the one I cared about. The rest came along for the ride. I didn't port the Next.js app. OpenNext runs Next.js on Workers and is the lower-risk path if you have a large app to move. Mine was small, and I rebuilt on a TanStack Start boilerplate that already targeted Workers natively, so there was no adapter layer to keep working. Leaving Supabase Auth means inheriting 938 bcrypt hashes from GoTrue. Better Auth hashes with scrypt. I could have forced a password reset on everyone, which is a good way to lose the users who were only half committed. You can just override the verify function: python import bcrypt from 'bcryptjs'; import { verifyPassword as verifyScryptPassword } from 'better-auth/crypto'; // GoTrue emits $2a$; bcryptjs emits $2b$; $2y$ is the PHP variant. const BCRYPT HASH = /^\$2 aby \$/; export async function verifyPasswordCompat { hash, password } { if BCRYPT HASH.test hash { return bcrypt.compare password, hash ; } return verifyScryptPassword { hash, password } ; } betterAuth { emailAndPassword: { password: { verify: verifyPasswordCompat }, // verify only, never hash }, } ; This works on Workers because bcrypt compare pulls the salt out of the stored hash, so it needs no RNG and runs fine on workerd. bcrypt hashing needs a PRNG, and that's where people usually hit the wall. We never call it. New passwords go through the default scrypt hasher, and migrated users verify against their old hash indefinitely. It costs 100-250ms of CPU per login for those users. For something that happens once a session I decided I didn't care. D1 is SQLite. No booleans, no native timestamp type, no jsonb. I ended up with four scripts: 01-export Supabase → NDJSON 02-transform pure, offline, no network 03-import NDJSON → D1 REST API idempotent 04-verify per-table counts + money sums, old vs new Inside the transform, per table I declare which columns are timestamps, date text, JSON or booleans, then coerce: if ts.has k out k = toMs v ; // Date → epoch millis else if dateText.has k out k = toDateText v ; // 'YYYY-MM-DD' else if json.has k out k = toJsonText v ; // jsonb → TEXT else if bool.has k out k = boolTo01 v ; // true → 1 Two D1 limits I hit while writing the importer. Maximum SQL statement length is 100,000 bytes, and some of my report rows carry large JSON blobs, so inlining them as SQL text blows past it immediately. Use bound parameters. The cap there is 100 bound parameters per query, so I batch at 90. The importer does INSERT OR REPLACE by primary key, so it's idempotent. On cutover day I ran a final delta sync while the old site was still taking writes, then ran it twice more because I didn't trust it. db.<ref .supabase.co is IPv6 only. I'm behind Clash with fake-IP DNS, so raw TCP to 5432 just hung, with nothing in the error worth reading. The fix is the IPv4 session pooler host, aws-0-<region .pooler.supabase.com , with the postgres.<project-ref username form and sslmode=no-verify . That last flag is for a one-off export script on my own machine, not something to carry into an app connection string. That one cost me an hour. The weekly pipeline: scrape ~10 subreddits, run an LLM over the posts to pull out niches, score and rank, generate build kits, persist, publish, queue emails. 500+ seconds end to end. On the old stack that was one HTTP invocation fired by a GitHub Actions schedule, all or nothing. If persist failed I lost the collection and the analysis, including LLM tokens I'd already paid for, and re-running meant paying for them again. Cloudflare Workflows persists the result of each step.do , so a failure retries from the failed step: export class NicheDiscoveryWorkflow extends WorkflowEntrypoint { async run event, step { const enabled = await step.do 'check-enabled', = isPipelineEnabled env ; if enabled return { success: true, skipped: true }; const analyzed = await step.do 'collect-analyze-score', { retries: { limit: 2, delay: '30 seconds', backoff: 'exponential' }, timeout: '15 minutes' }, async = { / scrape → LLM → score / } ; const report = await step.do 'persist-and-publish', { retries: { limit: 3, delay: '10 seconds', backoff: 'exponential' } }, async = persistScoredReport analyzed.scoredTop10, / … / ; } } Two things I got wrong on the first pass. I split steps by module: collect, analyze, score, persist, one each. What matters is what's expensive to redo. Collection is KV-cached and nearly free, the LLM call is where the money goes. So collect + analyze + score collapsed into a single step with the boundary right after it, and now a persist failure never re-spends analysis tokens. I also passed the raw post array between steps. Step state gets persisted and is size limited, so that falls over as soon as a week's scrape gets big. Steps now hand off the ~10 scored niches and nothing else. Config is three lines: "triggers": { "crons": "0 23 1", "0 9 ", "0 1 " }, "workflows": { "name": "niche-discovery", "binding": "NICHE WORKFLOW", "class name": "NicheDiscoveryWorkflow" } Plus re-exporting the class from your Worker entry, which I forgot, and then spent ten minutes being confused about. First production run took 7 minutes and came out green. I kept the old synchronous endpoint around behind a CRON SECRET bearer token as a manual fallback. Inbound was the easy one. My Zoho plan was expiring anyway, and Cloudflare Email Routing forwards support@ to Gmail for free. Three MX records. Outbound was harder. Resend's free tier is 100/day and I have around 900 weekly subscribers, so the job is to drain a backlog on a schedule. The daily cron takes at most 90, leaving headroom under the limit, ordered paid users first and then by oldest last sent at , with a log table so nobody gets the same report twice. Whatever doesn't fit rolls into tomorrow's run. A full cycle takes about ten days, which I'm fine with, because the report is weekly and the people paying for it get it on day one. Raising the cap later is one secret: echo '1000' | pnpm wrangler secret put NICHE EMAIL DAILY LIMIT Two things went wrong. The first was DNS error 100117 on deploy. Attaching the apex as a Worker custom domain fails while the old A record still points at Vercel. Deleting the old records and redeploying fixed it, which was obvious afterwards. The second was worse. I'd accumulated test-mode payment rows in the new database during the soft launch, so I wrote a cleanup to drop them. One of the rows I classified as test data was a real pending $95 payment from a real customer. I caught it because the verify script compares money sums per table, not only row counts. The totals didn't reconcile, I went digging, and a full re-import from production put the row back. Reconcile sums per table. A row count can match while the money is wrong. The rest of the final verify was clean: 938 users, 8,193 email log rows, and every subscription and payment row reconciled on both count and sum. One expected diff, where D1 had two extra environment kill-switch keys that never existed on the old stack. The rollback stayed loaded the whole time. DNS points back at Vercel whenever, Supabase stayed up for two weeks, and because the import is idempotent, recovering writes made during a rollback window is just 03-import --since . I'm a week in and don't have a number worth publishing, so I'm not going to invent one. What I can say is that the app, database, object storage, cache, three cron triggers, the durable pipeline and inbound email are now one Cloudflare account and one pnpm deploy . The surprise was Workflows. I migrated for cost and consolidation and came away mostly caring about durable execution. Getting retry and backoff as a config object on a step, instead of hand-rolling a queue with at-least-once semantics, changed what I'm willing to put in a cron job at all. If you're planning the same move, the Workflows step design and the D1 importer are the two pieces I have the most to say about. Ask and I'll write them up properly.