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.href redirect 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: cloudflare in response headers
• No cf-cache-status header 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.

Read more at Build and Bail