One Toggle, Two Nights

I typed the URL into my browser.

stacktube-production.up.railway.app

The screen loaded. The landing page I'd made—or rather, that AI made under my direction—existed on the internet. Feature descriptions, pricing table, FAQ. All there. I sent the URL to the control tower and got confirmation: "Landing page rendering correctly, all sections verified."

Done.

But "done" had a short shelf life.

I clicked the sign-up button. Entered email and password. Clicked register. An error appeared.

validation_failed: Unsupported provider: provider is not enabled

The only words I understood were "not enabled." Something wasn't activated. But what?

I sent the error to the control tower. The answer came.

"This error occurs because the Email Provider is disabled in Supabase."

Supabase is the external service handling user authentication for this project. I followed the control tower's instructions. Supabase dashboard. Authentication → Providers → Email. A toggle switch was there. It was off. I turned it on.

Tried signing up again. It worked.

One toggle.

But before reaching that toggle, there'd been another problem. Something called a redirect URL.

When you deploy, the address changes. On my computer it was localhost:3000. On the internet it became xxxxx.up.railway.app. Obvious. What I didn't know was that the authentication service needs to be told this new address. It needs to know where to send users after they log in. I hadn't told it.

And during these two days, there was a security incident.

While sending error logs to the control tower, a GitHub Personal Access Token got exposed. This is essentially a key to my code repository, and it appeared in plain text in the chat.

The control tower flagged it immediately. "Revoke this token now. GitHub → Settings → Developer settings → Personal access tokens. Delete it and reissue if needed."

Beginners inevitably make this mistake at least once, apparently. API keys, tokens, passwords—these should never be pasted into code directly or exposed in chat. They belong in environment variables, a separate secure space. I knew this, but while hurriedly copying error logs, the token came along for the ride.

What I learned from these two nights:

Errors come in layers. Fix one and another, previously hidden behind it, appears. Unsettling but normal. The first error was blocking the view of the second, but the second was always there.

And the cause of an error is usually trivial. One toggle was off. One URL wasn't registered. That level. The entire system isn't broken. Something somewhere is missing or mismatched.

Most errors are like that. And knowing that took two nights, but afterward, errors became less frightening.

---

🔧 Technical Terms in This Episode

Deploy/Deployment Making a program that only runs on your computer available on the internet for anyone to access. Restaurant analogy: going from test kitchen to grand opening.

Railway A deployment platform that automatically sets up servers when you upload code.

Supabase Auth A service that handles sign-up, login, and password management. Building authentication yourself carries high security risks, so using specialized services is industry standard.

Provider (Authentication Provider) A type of login method. Email, Google, GitHub are each a Provider. The relevant Provider must be "enabled" in Supabase for that login method to work.

Redirect URL The address telling the authentication service "where to send users after login." When you deploy and the address changes, you must inform the auth service of the new address, or users get lost after logging in.

Token A digital ID card. An API token proves "this person has permission to use this service." If exposed, someone else can act as you—revoke immediately.