Secrets management with quantum-seeded keys.

Store, rotate and read infrastructure secrets through one API, with a per-secret encryption key derived from quantum entropy, per-principal access policies and an access audit trail. Keys are derived and held server-side — this is not zero-knowledge; we can read your secrets.

Create Your First VaultHow It Works

How Vault works

Step 1
Store
POST the secret to the API. The service derives a per-secret key from quantum entropy and encrypts it
→
Step 2
Rotate
Schedule rotation with a randomised interval, so the rotation moment isn't predictable
→
Step 3
Read
Read it back by name, gated by your access policy and recorded in the audit chain

Where the trust sits: you send the plaintext secret to the API and it holds the key that decrypts it, so the operator can read your secrets. That buys you key management, rotation and audit you didn't have to build. If you need a vault that genuinely cannot read your data, you want client-side encryption — that is not what this is.

Storage: secrets, their wrapped keys and the access log are held in Postgres and survive restarts and redeploys. We do not yet publish a backup, restore or uptime commitment — if you need one contractually, ask us before you rely on it.

Quickstart — store and load a secret

# 1. create a vault curl -X POST https://vault-api.qntyx.io/vaults/ \ -H "Authorization: Bearer $QNTYX_TOKEN" -H "Content-Type: application/json" \ -d '{"name":"production"}' # 2. store a secret — the value goes to the server, which encrypts it curl -X POST https://vault-api.qntyx.io/secrets/<vault_id> \ -H "Authorization: Bearer $QNTYX_TOKEN" -H "Content-Type: application/json" \ -d '{"name":"DB_PASSWORD","value":"s3cret-value"}' # 3. read it back by name (policy-checked and audit-logged) curl https://vault-api.qntyx.io/secrets/<vault_id>/DB_PASSWORD \ -H "Authorization: Bearer $QNTYX_TOKEN"

A Python client and a qvault CLI exist in the repo, but neither is published to a package registry yet — pip install quantum-vault will not work. Use the API directly for now.

What Vault gives you

Quantum-seeded key derivation

A separate key per secret and version, derived with HKDF-SHA256 from QuantumRand entropy. Falls back to the OS CSPRNG if the entropy service is unreachable, and the response labels which was used.

Randomised rotation

Rotation runs on a base interval plus a random offset, so the moment of change isn't predictable. The offset comes from the OS CSPRNG, not the quantum source.

Tamper-evident access log

An append-only hash chain over every read, write and denial, so an altered entry breaks the chain and is detectable.

Per-principal policies

Access rules per secret and per principal, evaluated on every read, with denials recorded in the same audit chain.

Why route secrets through an API at all

The point is to stop secrets living in your repository and on developer laptops. Fetch them at boot over HTTPS instead, and you get one place to rotate a value, one access policy to change, and one log of who read what — none of which you had to build.

per-secret keys · tamper-evident access log · per-principal policies

Pricing

Starter
$29/mo
  • Single workspace
  • Core secrets + rotation
  • Rotation scheduling
  • Standard support
Get Started
Professional
$99/mo
  • Team vaults + RBAC
  • Tamper-evident access log
  • Randomised rotation offsets
  • Priority support
Start Free Trial
Enterprise
$299/mo
  • Unlimited vaults + secrets
  • SSO & advanced security
  • Dedicated support
  • SLA
Contact Sales

A free Developer tier is available in the product. Every tier uses the same cryptography; paid tiers raise limits and add team policies, rotation and the access log.

QNTYX
quantumrand.dev →