How Supabase Auth Makes a Developer's Life Easier and Why It's Not Just a GoTrue Clone

You know that feeling when you start a new project and realize you need to set up registration, password recovery, and email verification again? For the hundredth time. It seems easier to just grab a ready-made service like Firebase or Supabase Cloud. But sometimes a project demands full control over data or a closed environment where cloud solutions simply won't pass security audits. That's when Supabase Auth steps onto the stage — a Go-based authentication server you can run on a home server or in an industrial cluster.

What Is It Exactly

If you've worked with the Supabase ecosystem, you've probably used their Auth. But not everyone knows it's a separate open-source microservice that can run independently. The team originally based it on Netlify's GoTrue project, but over the past couple of years they've diverged so much that now they're two different beasts.

Supabase Auth issues JWT tokens, manages users, and plays nicely with Row Level Security (RLS) in PostgreSQL. Essentially, it's a bridge between your frontend and database that handles all the dirty work of identity verification.

What Makes It Good in Practice

The main draw of the project is that it covers almost all modern web requirements out of the box. You don't need to write a single line of code to implement login via Google or Apple.

Passwordless Login

Magic links and SMS OTP codes have become the standard. Supabase Auth supports this by default. The user enters their email, receives a link, clicks it — and they're in the system. For mobile apps, there's phone number login support through providers like Twilio or Messagebird.

Extensive OAuth Provider List

There are over a dozen available: from the classics like Google, Facebook, and GitHub to more specialized options like Discord, Notion, Slack, and even WorkOS for enterprise needs. Configuration comes down to adding a couple of environment variables with the Client ID and Secret.

Refresh Token Rotation

This is an important security feature. The server can detect when old refresh tokens get reused. If someone steals a token and tries to exchange it, the system catches this and invalidates the entire session chain for that user. It's a small detail that prevents serious incidents.

Postgres Compatibility

Since the project originated within Supabase, it's optimized for PostgreSQL. It doesn't just store users in a table—it enables complex row-level access control logic. You don't need to check user_id in every API request to the database—Postgres handles it automatically based on the JWT issued by this server.

How It Works Under the Hood

The project is written in Go, making it very lightweight and fast. It only needs a PostgreSQL database to run.

An interesting detail about migrations: they're applied automatically when the binary starts. This is convenient for Docker containers — update the image, restart, and the database is ready.

If you decide to self-host this, here's an example of how to quickly spin up an environment with Docker:

# Собираем бинарник
make build

# Запускаем инфраструктуру
make dev

After this, you'll have an API running on port 9999, ready to handle requests.

Configuration Gotchas

Configuration through environment variables is standard for microservices, and there are really a lot of them here. You can configure everything: from minimum password length to character complexity requirements.

For instance, if you want to disable regular registration and only allow invite-only login, just set:

GOTRUE_DISABLE_SIGNUP=true

And if you need to enable captcha (hCaptcha and Cloudflare Turnstile are supported), just pass the secret keys through the SECURITY_CAPTCHA_SECRET variables.

Why You Shouldn't Forget About the Proxy

The README has an honest warning from the developers: running an authentication server in production is not for the faint of heart. The team strongly recommends placing Supabase Auth behind a TLS proxy (Nginx, Kong, or cloud load balancers).

An important note for those planning a migration: Supabase Auth has dropped some features from the original GoTrue. For example, they removed native multi-tenancy support via the instances table. If your architecture relies on this, you'll need to either rethink your approach or stick with the original GoTrue from Netlify.

Who Is This For

I see three main scenarios where this project is indispensable:

1. Self-hosted projects: when you're building your own Firebase replacement on your own servers.
2. Enterprise solutions: when company security policy forbids storing user data in a third-party cloud.
3. Local development: even if you use Supabase Cloud, having the ability to run an identical authentication server offline is invaluable.

Supabase Auth is a solid tool that eliminates the need to reinvent the wheel for authorization. Yes, the README documentation may seem dry and overloaded with an endpoint list, but the code itself is stable and proven by millions of users in Supabase Cloud. If you need a reliable gateway for users that works with JWT and Postgres, it's probably one of the best solutions in Go today.