Lockr is an open-source, self-hosted secrets manager written in Go. It ships as a single ~15 MB binary with no external dependencies — no database, no agents, no cloud required.

How does Lockr encrypt secrets?

Each secret is encrypted with AES-256-GCM using a per-path key derived via HKDF-SHA256 from a master key. The master key is itself protected by Argon2id using your server passphrase and is never stored in plaintext.

Yes. Lockr is fully open source and free to self-host forever. There is no enterprise edition, no license key, and no premium plan.

How do services authenticate with Lockr?

Services authenticate via Ed25519 challenge-response or TOTP. Human operators use username/password (Argon2id hashed). Admin tokens use long-lived lkat_-prefixed tokens.

Lockr — Your secrets. Your server. One binary.

Name: Lockr
Author: Lockr

No Vault complexity. No cloud dependency. No SaaS trust issues. Drop one binary on your server and you're done."

$█

WHY Lockr

Vault is overkill

Needs Consul or etcd. Dedicated ops knowledge. You wanted secrets management, not a distributed systems project.

Lockr needs nothing but a passphrase.

Cloud means lock-in

Your secrets live in their region, billed by their API, gone if you leave. That is not ownership.

Your server. Your region. Your rules.

SaaS means trust

Doppler. Infisical. Great products — but your production secrets live on someone else's infrastructure.

Air-gapped by design. No SaaS required.

CORE CAPABILITIES

$█

Note: 5 versions kept. 30-day soft delete. Recoverable.

ENCRYPTION

Secret encryption

·AES-256-GCM (per secret, not per database)

Key derivation

·HKDF-SHA256 with path as derivation input

Master key

·Argon2id-protected, never stored in plaintext

Session tokens

·Argon2id hash only, lvt_ prefix, 1h TTL

Transport

·TLS 1.3 minimum, no fallback, self-signed CA on init

Audit log

·Append-only NDJSON, secret values never written

Encryption Flow

WRITE PATHYour App↓→HKDF-SHA256↓→Per-path key↓→AES-256-GCM↓→BadgerDB

AUTH PATHpassphrase↓→Argon2id↓→master.key.enc↓→TLS 1.3↓→session token

Each path has its own derived key. Compromising one secret exposes nothing else.

GET RUNNING IN 4 COMMANDS

One binary. No database. No agents. No cloud.

View on GitHub →

# build the binary

$go build -o Lockr ./cmd/Lockr

# initialise data directory

$Lockr init --data-dir /var/lib/Lockr

✓master key generated ✓ TLS certificate created

# start the server

$Lockr_PASSPHRASE=yourpassphrase Lockr server

✓listening on https://0.0.0.0:8300

# write your first secret

$Lockr set secrets/prod/stripe '{"key":"sk_live_abc123"}' --token <token>

✓written secrets/prod/stripe (version 1)

INTENTIONALLY OUT OF SCOPE

Lockr does one thing completely. These are not planned features.

The goal is to remain small and operationally simple. Forever.