helix-tribune lands Cloudflare/Supabase-to-AWS migration in nine staged commits

saratpediredla-level5 migrated the helix-tribune fork off Cloudflare Workers and Supabase onto a fully AWS-native stack. Nine logically staged commits cover every layer: infra (SST v3), database (Aurora + Drizzle), auth (Clerk), storage (S3), email (SES), and frontend (OpenNext AWS adapter).

infrastructuresecurity

The frontend moves from @opennextjs/cloudflare to @opennextjs/aws, deployed to CloudFront and Lambda. The backend becomes a containerized Fargate service behind an ALB, with LibreOffice baked into the image for document conversion. Postgres shifts from Supabase to Aurora Serverless v2 fronted by RDS Proxy. SST v3 is the single infrastructure description, covering VPC, RDS, S3, Fargate, the Next.js app, and secrets that now live in AWS Secrets Manager.

The data and auth layers were rewritten from scratch. @supabase/supabase-js is gone from every route, replaced by Drizzle ORM. The author explicitly rejected building a Supabase-shaped adapter over pg - the decision log says clean types and no leaky abstraction were worth the per-callsite rewrite. Row-level security is dropped entirely; access checks live in route handlers. Authentication switches to Clerk on both sides: <ClerkProvider> and clerkMiddleware on the frontend, JWT verification via @clerk/backend in the Express middleware. The dropped Supabase handle_new_user trigger becomes a first-request profile bootstrap in auth middleware, cached in-process to avoid re-running. user_id columns retype from uuid to text for Clerk identifiers.

Supporting systems follow the same direction. R2 is replaced by S3 using IAM-role credentials from the Fargate task role (standard AWS credential chain locally). A SESv2 helper replaces Resend - the helper is present even though there are currently no callsites upstream. Member-lookup queries that previously fetched all Supabase users and filtered now call Clerk's users.getUserList({ emailAddress }), scoped by email address.

A few files are deliberately left on disk as no-ops: backend/schema.sql, the old nixpacks.toml, and the previous open-next config. The stated reason is to keep three-way merges from upstream/main clean by not deleting files the upstream repo may still reference.

Verification reported zero tsc --noEmit errors on both packages, no remaining @supabase/* imports anywhere, and lint problems confined to pre-existing issues. The PR ships an upstream-fork strategy document predicting which paths will conflict on future merges (route handlers, auth middleware, storage lib, frontend auth files) and which won't (infra, Dockerfile, SST config, Drizzle schema). A deployment checklist covers SST secret population, SES identity verification, the initial Drizzle migration against RDS via the SST bastion, and DNS cutover to the CloudFront distribution.

So what Worth a look if you're planning to run willchen96/mike on AWS. The nine-commit structure gives you a staged migration sequence you can follow independently, and the Drizzle schema plus migration files handle the hardest translation work from the original Supabase schema. Skip if you're staying on the upstream stack - this is a full platform fork with no portable feature additions.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?