Security model
A model you can verify, not just trust.
Security shouldn't be a promise on a marketing page. lazyit is built so the guarantees that matter are structural — provable in the code you run on your own servers, not assurances you have to take on faith. Here's how it holds up.
The server can't decrypt your secrets. By design.
Your Secret Manager vaults are end-to-end encrypted. Values are encrypted in your browser before they ever reach the server, and decrypted only there, by a member of the vault. lazyit stores a form it cannot read — not the server, not an administrator, not a database backup can reveal a secret value.
There is no master key on the server, so there is no back door. That's exactly what makes the guarantee worth trusting: you don't have to take our word for it.
Visible to lazyit
Vault names · member lists · secret labels & handles
Never readable by lazyit
Secret values · your password · your recovery key
Names and members stay visible so the app can show a list and admins can manage access — so name vaults and secrets plainly, and never put a secret value in a label.
Production secrets
12 items · 4 members
- DATABASE_URL••••••••
- STRIPE_SECRET_KEY••••••••
- ZITADEL_SA_KEY••••••••
The server can never decrypt your secrets.
Layered access, enforced on the server.
No single control carries the weight. Identity, authorization and decryption are separate concerns, each enforced independently.
Per-vault membership
Reaching the Secret Manager and decrypting a vault are two different things. Permission to enter lets you see that vaults exist; only membership of a vault lets you decrypt it. You can't share a vault you aren't a member of — access only ever flows down from people who already hold it.
Per-domain authorization
What you can do is read from lazyit's own database — three fixed roles and the permissions behind them — never from your sign-in token. A misconfigured or tampered token can't grant power inside lazyit. New users start read-only; least privilege is the default.
Delegated identity (OIDC)
lazyit stores no sign-in passwords. Authentication is delegated over OIDC to your own identity provider — bring your own, via Zitadel — so MFA, password policy and lockout live where they belong. There's no password database to leak.
Nothing is hard-deleted. The trail stays intact.
Ownership is a dated relation, never a column — assign and reassign, and the history writes itself. Retire an asset, offboard a person, revoke an access: the record stays. So the system always answers the question that matters in an incident or an audit — who had this, and when.
- Soft delete — domain data is retired, never erased
- Append-only logs and ledgers, immutable by construction
- Full history on every asset, person, grant and revoke
Yours to run, audit and keep.
lazyit is AGPL-3.0, so every claim on this page is one you can read for yourself. It runs entirely on your infrastructure, and nothing phones home.
AGPL-3.0
Read the source, fork it, run it forever. No black box.
Self-hosted
Your servers, your database, your backups. Data never leaves.
No telemetry
No phone-home, no tracking, no per-seat billing.
Found something? Tell us privately.
If you believe you've found a vulnerability, please report it privately first, so it can be fixed before it's public. The fastest path is a GitHub Security Advisory — it opens a private channel with the maintainer.
Being straight with you: lazyit hasn't had a third-party security audit yet. So rather than point to someone else's stamp, we keep the code open and the model simple enough to audit yourself.