The app itself was the easy part. Next.js 14, Supabase auth, Tailwind, a calendar view for scheduling Build and Bail posts across TikTok, Shorts, Reels, Reddit, and the blog. Standard stuff. Claude Code knocked that out before I even got seriously involved.
Then I tried to deploy it to Cloudflare Pages.
Three days, four separate problems, one leaked Supabase password. Here’s the autopsy.
Problem 1: The login redirect loop
Signed in. Got bounced back to login. Signed in again. Bounced back again. Rinse and repeat until I started questioning my life choices.
Cookie writes from server actions weren’t persisting on Cloudflare’s edge runtime. The fix:
- Move the sign-in call to a browser client
- Use a hard
window.location.hrefredirect after success - Stop trying to be clever with server actions for auth on the edge
Not elegant. Works.
Problem 2: “Supabase env vars: (none found)”
I’d set the NEXT_PUBLIC_* variables as Secrets in the Cloudflare dashboard. Seemed reasonable. Secrets are for secret things, right?
Wrong.
- Next.js inlines
NEXT_PUBLIC_*vars at build time - Secrets in Cloudflare Pages aren’t exposed at build time
- So every Supabase call crashed with undefined credentials
Fix was moving them into wrangler.toml under [vars] as plaintext. I added a note to .env.example so future me doesn’t do this again.
Problem 3: 500s on every static chunk
This is where I burned most of the three days.
Every JS and CSS file under _next/static/* was returning empty-body 500 errors. Build output looked fine. Logs were clean. Everything was correct. Except nothing worked.
I went down a rabbit hole patching _routes.json, which produced a routing overlap error that ironically proved the routing was fine all along.
Root cause: the Pages project itself had a corrupt asset bundle. Deleting and recreating the project fixed it in about 90 seconds.
The signature to watch for, if anyone else hits this:
- Empty-body 500s on static assets
server: cloudflarein response headers- No
cf-cache-statusheader at all - Build log shows success
If you see all four, stop debugging the code. Delete the Pages project and start over.
Problem 4: My Supabase password ended up in my browser history
At some point during all this, a form submission fell back to a GET request because the JS hadn’t loaded yet. My password got stuck in URL query strings. Which means it’s in my browser history. Which means it’s plausibly in Cloudflare’s edge logs too.
I rotated the password. You should probably assume any credential that’s ever touched a form has leaked somewhere.
What actually shipped
A working content calendar with:
- Supabase auth that doesn’t loop
- A weekly calendar view for scheduling across platforms
- Status tracking (draft / scheduled / posted / flopped)
- A quick-add modal so I can dump ideas when they hit
- Hosted on Cloudflare Pages for free
The meta part: I built this specifically to schedule posts like this one. The first post on the calendar is a post about the calendar.
Time breakdown
- Actual building: ~30 minutes
- Waiting for Cloudflare builds: a lot
- Chasing the wrong theory on problem 3: at least an hour I’m not getting back
- Total wall clock: 3 days
The real lesson
Deploys lie. When every layer says “success” but nothing works, the infrastructure itself might be broken in a way that doesn’t surface in logs. Recognize that pattern earlier next time.
Also: I could have just used Notion. I know. I know.