Your auth server shouldn't cost more RAM than your entire app. So I wrote my own in Rust.

Luis — Tue, 28 Apr 2026 20:33:54 +0000

I've been using Keycloak for almost 1 year across freelance projects — large-scale enterprise apps and small side projects alike. The appeal was always the same: it's free, battle-tested, and it works.

Until it doesn't.

The documentation is a labyrinth. Pages and pages of concepts and configurations that make sense if you already know Keycloak, but are genuinely hostile if you're just trying to get started.

But the real breaking point was the math. A DigitalOcean droplet with enough RAM to run Keycloak comfortably costs more than most small projects can justify. And SaaS alternatives like Clerk or Auth0 aren't much better — you're paying per seat, per month, forever, while handing your users' credentials to a third party.

So two weeks ago I started building my own. Written in Rust. Running in under 20MB of RAM.

This is what I learned.

The Landscape Problem

Let's talk about numbers. When you're a small team or even a solo developer, you're almost always choosing between the cheapest or most self-hosted options available:

Keycloak idles at ~512MB RAM. Authentik runs a server and a worker separately — combined you're looking at ~735MB, plus a Redis instance on top. Zitadel is more reasonable at ~150MB, but still needs a comfortable server to run well. All of them are written in Java, Python, or Go — runtimes that carry overhead by design.

If your VPS has 1GB of RAM, you've already spent most of it before your app starts. And if you're on a $6/mo droplet — which is where a lot of freelance and side projects live — you don't have that RAM to spare.

SaaS alternatives solve the infrastructure problem but create new ones. Clerk starts at $25/mo. Auth0 at $23/mo. Both charge per seat as you grow, and both mean your users' credentials live on someone else's servers under someone else's encryption model.

The gap between "what auth costs to run" and "what a small project can actually afford" is exactly where OVTL lives (you can even run a Minecraft vanilla server without any problem on the lowest tier).

Why Rust???

Honest answer: I wanted something lean by default, not by configuration.

Garbage-collected runtimes like the JVM introduce overhead you can't fully control — memory spikes, pause times, warmup costs. For an auth server that needs to be predictable, that's a problem. Rust doesn't have a garbage collector. The binary starts in under a second and stays there.

There's also the security angle, which — for something that guards your users' credentials — kind of matters. Rust's ownership model eliminates entire classes of memory vulnerabilities at compile time. Not in production. Not in a postmortem. At compile time.

Honestly, once it clicks, it's hard to go back.

Wait, it's also secure?

Building an auth server from scratch means making calls that aren't obvious until you're deep in it. These shaped OVTL the most.

Zero-knowledge encryption. User data is encrypted at rest with AES-256-GCM using a double-envelope key model — the server never handles plaintext credentials directly. I built a separate Rust crate for this called hefesto because nothing existing fit what I needed. It's the part I'm most proud of.

Multi-tenancy via PostgreSQL RLS. Tenant isolation is enforced at the database level through Row Level Security — not in application code. Even if something goes wrong at the app layer, tenants can't bleed into each other.

PKCE required, not optional. A lot of auth servers support PKCE but don't enforce it. OVTL requires it on every Authorization Code flow. Minor friction for developers, real protection against token interception attacks.

None of these were the easy path. But they're what makes the difference between an auth server you can trust and one you just hope works.

The result? A full OAuth2 + OIDC stack, multi-tenant, zero-knowledge encrypted — running in under 20MB of RAM. On the same $6 VPS your app already lives on. No sidecars, no Redis, no dedicated server. Just your app and your auth, together.

Oh, and did I mention it has a TUI?

No web UI required. You manage tenants, users, clients, roles, and permissions straight from your terminal — with guided wizard setup. Because if you're already living in the terminal, why would you open a browser just to create a tenant?

It looks something like this:

$ ovlt --url http://localhost:3000

And yes, it has wizards. Friendly ones.

So...what's next? (besides sleep)

OVTL is two weeks old. Yes, two weeks. It's alpha, it's rough around the edges, and there's a list of things I know need fixing — OIDC compliance, email delivery, and a bunch of stuff I probably haven't discovered yet. I'm not going to pretend it's ready for production, because it's not.

But here's the thing — the core actually works. OAuth2 + OIDC, multi-tenant, zero-knowledge encrypted, MFA, social login, audit log, all sitting comfortably under 20MB of RAM. For two weeks of work, I'll take it.

If you're the kind of developer who enjoys poking at half-finished things, finding edge cases, or just watching someone build in public and occasionally panic — you're going to feel right at home.

Drop by ovlt.tech and tell me what you think. The GitHub Discussion is open and I read everything.