DEV Community: Mark Odera

Most Auth Tools Give You Users and Sessions. HVT Gives You Something Better.

Mark Odera — Thu, 14 May 2026 09:41:52 +0000

Firebase Auth, Auth0, and Clerk are all solid products. If you need authentication up and running in an afternoon and you never want to think about it again, any of them will do the job.
But there is a problem none of them will tell you about: you do not own any of them.
Your user data lives on their servers. Their pricing teams decide what you pay next year. Their roadmaps decide what features you get. And if any of them go down, change their terms, or get acquired and rebranded into something unrecognisable, which has already happened with Auth0 and Okta, you are along for the ride whether you like it or not.
That is a problem HVT was built to solve.

What the alternatives actually cost you

Firebase Auth is the easiest to get started with, which is exactly why so many teams default to it. But it is a Google product, closed-source, and there is no self-hosted option. Your user data sits on Google's infrastructure permanently. If you are building anything in fintech, healthtech, or any space where data residency matters, that is a compliance conversation waiting to happen.

Auth0 used to be the serious choice for teams that needed more control. Then Okta acquired it, and the pricing has become infamous enough that "Auth0 pricing shock" is practically a genre of developer blog post at this point. It is powerful, but closed-source and expensive at scale.

Clerk has arguably the best developer experience of the three. The DX is genuinely good. But it is entirely hosted, there is no self-hosting path at all, and the MAU-based pricing model means your auth bill scales against you as your product grows. For non-US teams, data residency is also a real concern.
The pattern across all three is the same: you are renting infrastructure from a company whose priorities are not necessarily yours.

What HVT does differently

HVT is open-source, AGPL v3, and fully self-hostable. You run it on your own infrastructure, your user data never leaves your servers, and because the entire codebase is public, you can audit it, fork it, and modify it.
But self-hosting is not the only differentiator. SuperTokens, Keycloak, and others are also self-hostable. What separates HVT is the access model.

Most auth tools think in terms of users and sessions. HVT thinks in terms of a hierarchy:
Org → Project → API key → Runtime token

You create an organisation. Within it, you create projects. Each project has scoped API keys with explicit permissions. At runtime, those keys exchange for short-lived tokens. Every layer is explicit, auditable, and scoped.

This matters more than it sounds. When your product grows from one service to ten, when you bring on contractors who need access to one project but not others, when you need to rotate credentials without touching your entire auth layer, a flat user-session model becomes a liability. The hierarchy scales with you.

Who HVT is for

HVT is not trying to replace Firebase Auth for the developer spinning up a weekend project. If you need auth in two hours and you will never think about data ownership, Firebase is fine.
HVT is for teams that have been burned before. Developers building in regulated industries. Founders who want infrastructure they actually control. Anyone who has ever had to explain to a client why their user data lives on a third-party server in a country they did not choose.
If that is you, HVT is worth a look

Get started

Live platform: hvts.app

Documentation: docs.hvts.app

GitHub: Star the repo and follow the project, HVT is actively developed and community feedback shapes the roadmap.

If you have questions, run into issues, or want to discuss a specific use case, drop a comment below. Always happy to talk through it.

Why I built an open-source alternative to Auth0

Mark Odera — Tue, 28 Apr 2026 18:14:03 +0000

Auth0 is a great product. So is Clerk. But at scale, both get expensive fast. Auth0 can run into hundreds of dollars a month once you cross certain MAU thresholds. Clerk charges per user. If you are building a multi-tenant SaaS, those numbers compound quickly.
I spent a long time looking for an alternative. Something with JWT rotation, RBAC, webhooks, audit logs, and multi-tenancy baked in. I could not find one that covered the full surface, so I built it.

What HVT is

HVT is a self-hostable authentication platform. You run it yourself for free, or use the managed cloud version at hvts.app. It is licensed under AGPL v3.

The core model is: Organisation → Project → API key → Runtime token.

Each app or environment gets its own project. Runtime users (your app's end users) are isolated per project. The same email can exist across different projects without collision.

What it covers

JWT with rotation and blacklisting
Runtime user signup, login, social auth (Google, GitHub)
Per-project RBAC with custom app roles and permission slugs
HMAC-signed webhooks with retry and auto-disable
Full audit logging across 21 event types
TypeScript SDK (@hvt/sdk)
One-click Railway deploy

Why AGPL

If you modify HVT and deploy it as a network service, you have to open-source those changes. That is intentional. It keeps the ecosystem honest and ensures improvements flow back to the community.

Where it is now

The backend is live at api.hvts.app. Docs are at docs.hvts.app. The SDK is published under @hvt/sdk on npm. It is early, but it works.

Check out the HVT GitHub Repository

If you have been burned by auth pricing or vendor lock-in, give it a look. Feedback welcome.

markodera / hvt

HVT is an open-source authentication infrastructure built for developers, start-ups and teams who want to build fast and take full control of their authentication systems

HVT

HVT is an open-source authentication platform built with Django and Django REST Framework. It provides a control plane for organizations, projects, API keys, invites, webhooks, and audit logs, plus a runtime auth plane for customer-facing applications.

Current Scope

email and password authentication
JWT access and refresh tokens
registration, email verification, and password reset
Google and GitHub social login
organizations, projects, and API keys
project-scoped runtime auth with shared identity across projects
invitations, project roles, permissions, and audit logs
webhook delivery for organization events

Project Model

HVT separates two concerns:

control plane: the dashboard and admin-facing APIs used to manage organizations, projects, API keys, social providers, invites, and webhooks
runtime plane: project-scoped auth flows that your application uses for sign-up, sign-in, social login, verify-email, and password reset

True Multi-Tenant Isolation: User accounts are strictly isolated at the project level. Unlike traditional Django apps where an email must be globally unique…

View on GitHub

Django Task Manager: Built in a Day with Django

Mark Odera — Sat, 18 Jan 2025 23:06:27 +0000

Built in a Day with Django

Introduction

Hey Dev.to community! 👋I built a task manager app in one day for the Dev.to Django Challenge. My aim was to explore Django’s capabilities while creating something functional.

Features ✅

Authentication & CRUD for tasks

Prioritization & due dates

Search and filter options

Responsive design

Tech Stack 🛠️

Django 4.x

Python 3.x

Bootstrap 5

SQLite3

Setup 🚀

Clone repo:

git clone https://github.com/markodera/freshstart-taskmanager.git
cd freshstart-taskmanager

Activate virtual environment:

python -m venv venv && source venv/bin/activate

Install dependencies:

pip install -r requirements.txt

Run migrations and server:

python manage.py migrate && python manage.py runserver

Lessons Learned ✍️

Plan first.

Focus on essentials.

Leverage Django’s built-in tools.

Closing Thoughts

Django is amazing for quick, powerful builds. Try a similar challenge—you’ll learn a ton!

GitHub Repo: https://github.com/markodera/freshstart-taskmanager.git 🙌