AuthCell
Self-hosted API key management: issue, verify and rotate keys on your own infrastructure
Open-source API key management you run yourself. AuthCell issues, verifies, rate-limits, rotates and revokes API keys for your own services, as a single Go binary backed by PostgreSQL.
- Status
- Open source
- Licence
- Apache 2.0
- Built for
- Teams shipping an API who want key management on their own servers, not on a third-party platform.
- Category
- Self-hosted API key management
The problem
Almost every API needs keys. Someone has to generate them, store them safely, check them on every request, count usage, enforce limits, and let customers rotate or revoke them without downtime.
Most teams either build this inside their main app, where it quietly grows into a security liability, or hand it to a hosted key service. A hosted service means every request your API serves waits on someone else's network, and your customers' key data lives in someone else's database.
AuthCell is the middle path: a small, focused service that does API keys properly and nothing else, running next to your API on your own servers. It is open source under Apache 2.0, so you can read every line that touches your keys.
How it works
- 01
Deploy it
Run the Docker image or the single binary next to PostgreSQL. Set an admin token, start it, and the schema migrates itself. Docker Compose, Kubernetes, a VM or a server in your own rack all work.
- 02
Issue keys
Your backend calls the admin API to create a key with a prefix, a name, JSON metadata, an optional expiry and a rate limit. The full key is returned once and never stored.
- 03
Verify on every request
Your API sends the incoming key to AuthCell's verify endpoint and gets back yes or no, the reason, the key's metadata and its remaining rate limit. Node.js and Python clients are included.
- 04
Rotate and revoke
Rotate a key in one call, which issues a replacement with the same settings and revokes the old one. Every admin action lands in an audit log, and every verification lands in a usage log.
What it does
- Full key lifecycle: create, list, update, rotate, revoke
- Verification in one indexed lookup plus a constant-time hash compare
- Per-key rate limits that hold across multiple AuthCell instances
- Expiry, names and JSON metadata on every key
- Usage log for every verification and audit log for every admin action
- Admin API behind a bearer token, with an optional token for the verify endpoint
- Versioned schema migrations that run on startup and upgrade older databases in place
- Distroless Docker image, Docker Compose setup and release binaries for Linux, macOS and Windows
- Zero-dependency Node.js and Python clients
- Apache 2.0 licence, no telemetry, no external services
How we built it
Fast hashing, because the keys are random
Passwords need slow hashes like bcrypt because people pick guessable ones. API keys don't. An AuthCell key carries 192 bits from a cryptographic random source, so a SHA-256 digest is just as safe and costs microseconds instead of tens of milliseconds on every request. Keys hashed with bcrypt by earlier versions still verify, and are moved to the new format the first time they are used.
A key you can find without searching
Every key has the shape prefix, key id, secret. The key id is 16 random hex characters stored in a unique index, so verification is one indexed lookup no matter how many keys exist. The secret never leaves the request: only its digest is stored, and it is compared in constant time.
Rate limits in one statement
Counting requests in application memory breaks as soon as you run two copies of the service. AuthCell keeps the window in PostgreSQL and updates it with a single atomic UPDATE ... RETURNING, so the count is correct across any number of instances without Redis or a separate coordinator.
Saying no without saying too much
A verify endpoint can leak which keys exist if it explains every failure. AuthCell answers "invalid" until the caller has proved they hold the real key. Only then does it say whether the key was revoked, expired or rate limited.
Upgrades that don't need a maintenance window
Migrations are numbered, run in a transaction and take a Postgres advisory lock, so several instances can start at once and only one migrates. The first migration is the original schema, so databases created by earlier releases upgrade in place.
AuthCell: common questions
Is AuthCell free?
Yes. AuthCell is open source under the Apache 2.0 licence. You can use it, change it and run it commercially at no cost. The source, Docker setup and release binaries are on GitHub.
What is self-hosted API key management?
It means the service that creates and checks your API keys runs on servers you control, instead of a third-party platform. Your key data stays in your own database, and verification happens on your own network, close to your API.
How do I verify API keys with AuthCell?
Send the key to POST /v1/keys/verify, in the JSON body or an X-API-Key header. A valid key returns 200 with its metadata and remaining rate limit. An invalid, revoked or expired key returns 401, and a rate-limited key returns 429 with a Retry-After header.
Where can AuthCell run?
Anywhere you can run a container or a Go binary with PostgreSQL next to it: Docker Compose on a single VPS, Kubernetes, AWS, Google Cloud, Azure, or servers in your own data centre. It makes no outbound calls, so it also works in networks without internet access.
Can Labvent deploy and run AuthCell for us?
Yes. We can set it up on your cloud account, on-premise or in an air-gapped network, wire it into your API, migrate keys from an existing system, and stay on to run upgrades and monitoring. Tell us about your setup and we'll scope it.
Can AuthCell be extended for our product?
Yes. Common additions are key scopes and permissions, per-customer usage billing exports, a self-service key dashboard for your users, and SSO for the admin side. We build these on top of AuthCell for clients, in your codebase or as a fork you own.