Security1 publisher2 min readPublished
Keyorix ships a self-hosted, single-binary secrets manager that imports from Vault
Keyorix SL released an open-source secrets manager that runs as one binary on a company's own servers with no internet connection. Air-gapped and NIS2- or DORA-bound teams get a self-hosted option, described so far mainly by its maker.
The Watch · Security desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Keyorix SL's own comparison table sets the product against Vault, which runs on premises but needs a dedicated admin, and Doppler, which is simple but SaaS-only.
- Teams already running Vault can import their existing secrets into Keyorix.
- Applications pull secrets through a command-line tool that injects them as environment variables, or through SDKs for Go, Python and Node.js.
- Storage is SQLite for development and small teams, or PostgreSQL for production.
- Access controls include role-based access, group permissions, secret versioning, separate development, staging and production environments, and service tokens for CI/CD jobs.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- constraint Because the master key comes from a passphrase set at startup, every restart needs that passphrase supplied, so an offline deployment has to settle who holds it and how it reaches the server after a reboot.
- decision A team running Vault without the staff to maintain it can test Keyorix against its real secrets before committing to a migration.
- cost Regulated buyers cannot put the vendor's own comparison in front of a NIS2 or DORA review, so the testing and the evidence fall to them.
The key design limits what a copied database file is worth to an attacker. According to Help Net Security, each secret value is encrypted with AES-256-GCM. The data key is wrapped by a key-encrypting key, which is stretched from a passphrase set at startup and lives only in memory [9]. The unwrapping key is never written to disk. A stolen SQLite or PostgreSQL file therefore holds ciphertext and a wrapped data key, and nothing that opens either [1]. How long that holds depends on the passphrase and on the stretching step. The write-up does not name the function used for that step, and it does not mention an independent audit of the code.
The running server is a different case. While Keyorix is up, the key-encrypting key sits in memory and wraps the data key behind every stored value [9]. An attacker who can read that host's memory has what the stolen file lacks.
Audit covers the store itself. Every access is logged with who, what, when and from where, across two audit layers [11]. A secret delivered as an environment variable [5] leaves the store once the app reads it. What the application does with the value after that falls outside those logs. Rotation, as the source describes it, is a dashboard alert for secrets nearing a deadline [14]. Someone still has to rotate them.
The stated purpose is to keep database passwords, API keys and tokens out of config files and source code [13]. For an air-gapped network still running on config files, that alone moves the credentials off disk in the clear and behind an access log.
None of this is threat news. The code is free on GitHub [12]. One Docker Compose command starts the full stack, web interface included [7]. I think a team already running Vault with an admin in place has no reason here to move. A team whose credentials sit in plaintext config on an offline network has a free candidate to put through its own review [12].
What to watch
- An independent security audit of Keyorix's encryption, passphrase stretching and audit logging.
- Documentation on how the startup passphrase is supplied for unattended restarts or high-availability deployments.
- A named NIS2- or DORA-regulated organisation running Keyorix in production.