Who Warrant is for#
SaaS teams managing tenant roles and entitlements
Warrant fits products that need organization-level roles, feature access by plan, and resource-level sharing in one authorization model.
Skip if:
You only need a few hardcoded roles inside a single application.
Internal tools that need auditable access control
Centralizing checks helps teams control who can view or change sensitive operational data across admin panels, scripts, and support tooling.
Skip if:
Your internal tools can rely on a simple network boundary or manual approvals.
Teams evaluating self-hosted Zanzibar-style auth
The project is useful when developers want to test or extend a relationship-based authorization service before buying or standardizing on a managed platform.
Skip if:
You need a fully managed service with high-scale guarantees out of the box.
The problem it solves#
Authorization logic becomes hard to trust when roles, entitlements, and object permissions are implemented separately in each service. Teams end up debugging inconsistent rules, duplicating audit logic, and shipping brittle access checks.
A centralized authorization service reduces that drift. Warrant gives developers one place to model access rules, evaluate checks, and audit permission changes while still supporting tenant-specific and resource-level policies.
How it solves it#
Centralized authorization APIs
Warrant exposes HTTP APIs for defining roles, permissions, features, tenants, users, and access rules from application code or operational tooling.
Multiple access models in one engine
The service is built around a Zanzibar-style relationship model that can represent RBAC, ABAC, and ReBAC without splitting authorization logic across separate systems.
Self-hosted deployment paths
The open source project documents local source builds and container-based deployment options, with MySQL, PostgreSQL, and SQLite support.
Strengths and trade-offs#
Strengths
- Fits teams that need deployment controlSelf-hosting lets security-conscious teams keep authorization data, configuration, and upgrade timing inside their own infrastructure.
- Covers common SaaS authorization patternsThe project is aimed at tenant roles, entitlements, object-level sharing, and auditable access checks instead of a narrow single-use policy flow.
Trade-offs
- -Open source edition has throughput limitsThe README states the open source version is best for POCs, development or test environments, and lower-throughput workloads.
- -Requires operating another serviceTeams must provision a datastore, manage configuration, and run the authorization service instead of delegating that operational work to a hosted vendor.
Install and self-host#
Self-host Warrant locally from source:
```bash
git clone https://github.com/warrant-dev/warrant.git
cd warrant/cmd/warrant
make dev
./bin/warrant
```
For container-based setups, the repo also includes Docker deployment examples for MySQL and PostgreSQL.What it's built on#
- Languages
- Go
FAQ#
What is Warrant?
Warrant is an open source fine-grained authorization service for defining, checking, and auditing application access rules.
How do you self-host Warrant?
The project docs describe local builds from source plus deployment examples for Docker-based setups with MySQL or PostgreSQL.
When is Warrant a better fit than hosted authorization tools?
Warrant is a better fit when your team wants source access and self-hosting control. Hosted tools reduce operational work and may be a better choice for very high-throughput or fully managed requirements.
Similar open-source tools#
Oso Cloud
Open source authorization with RBAC, ABAC, and ReBAC for any app
Logto
Multi-tenant auth platform with SSO, RBAC, and social login
ZITADEL
Open source identity platform with SSO, RBAC, and multi-tenancy
Better Auth
Drop-in TypeScript auth with MFA, SSO, and multi-tenancy support
Cerbos
Move access control out of app code into testable YAML policies
iptv
A collaborative database for TV channels