Secrets management for on-premises Linux

The credentials that never made it into the vault.

Database passwords in cron jobs. API keys in backup scripts. Service accounts in the in-house application nobody wants to touch. Arcenkey puts them behind a hardware security module without rewriting any of those scripts.

How it works Talk to us

# store a secret: prompts twice, no echo, never in shell history
$ arcenkey -s DB_PASSWORD

# read it back from any script
$ export DB_PASSWORD=$(arcenkey -r DB_PASSWORD)

Versions, tags, expiry, host-binding, and JSON output are additive flags on the same two commands.

Why it exists

Every estate has two kinds of secrets.

The ones that made it into a vault, and the ones that stayed in the scripts.

Enterprise secrets platforms earn their keep where there is a team to run them: policies to write, agents to roll out, applications to re-plumb. On an on-premises estate with a few administrators and twenty years of working automation, that project never starts. So the backup job keeps its password in a config file, the integration script keeps its API key in a variable, and a copy of each sits in every backup ever taken.

Arcenkey was built for that estate, by a company that runs one. It is a small command-line tool: one command stores a secret, one reads it back, and every value is encrypted by a physical YubiHSM 2 before it touches disk. The script changes by one line. The password leaves the config file for good.

What sets it apart

Designed around a small number of hard rules.

A hardware device behind every secret.: Decryption authority is a YubiHSM 2 you own and operate, not a software key sitting on a disk. Every read is unwrapped by the device, every time.
No central store to steal.: The server keeps no ciphertext at all. Each host keeps its own small encrypted file next to the application that uses it, so there is nothing fleet-wide to exfiltrate, corrupt, or hold for ransom. Compromise one host and you get one host.
Even the names are hidden.: Secret labels are stored only as one-way hashes. Someone who walks off with the file cannot tell what it holds, let alone read it. The same boundary holds in the audit log.
Ciphertext you can treat as data.: The encrypted file is safe to back up, replicate, or commit alongside the code that uses it. It is useless without the HSM, and optionally useless without the host that wrote it.
Lock a secret to the machine that owns it.: Optional host-binding adds a second wrap under a key that lives only on that host. A file copied elsewhere never decrypts, which closes off selective exfiltration and backups that wander.
Shared credentials that stay in step.: When several machines must present the same credential, one owns it and the rest follow within seconds of every rotation. Ciphertext only, host to host, nothing new to operate.
Audit that proves who, without revealing what.: Every operation is logged with the caller's identity and streams to your SIEM. Investigators answer "who touched this secret" by its hash. The secret's name never appears in a log.
Nothing to adopt.: No agent, no SDK, no application rewrite. A small client that slots under the scripts and cron jobs you already have, on the Linux hosts you already run.

How a read works

A short, controlled path.

arcenkey -r runs on any host and hands the request to a small local daemon that holds that host's client certificate.
The daemon forwards it over mutually authenticated HTTPS to the one server that holds the HSM credential. Clients can list more than one server and fail over on their own.
The server asks the attached YubiHSM 2 to decrypt, and the plaintext returns to your command.

The encrypted file never leaves the host. The HSM credential never leaves the server.

any host

arcenkey + local daemon

Keeps its own encrypted file and a client certificate. Never holds plaintext at rest.

mutual TLS

one hardened server

arcenkey-server

Holds the HSM credential and the host allowlist. Stores no secrets, in any form.

attached

hardware

YubiHSM 2

Holds the wrap key and performs the cryptography. The key never leaves the device.

The full picture, including failover, secondary servers, and sync.

What you get

Everything a small team needs, and nothing it has to babysit.

Everyday use

Store and read in a single command
Automatic version history
Descriptions and tags
Soft expiry that reminds you to rotate without ever breaking a production read
Shared credentials kept in step across hosts
JSON output for scripting and reporting

Security and access

Per-host certificates from a built-in private CA
Revocation by allowlist
Scoped tokens for CI and tooling, opt-in
Per-user attribution on shared hosts
Optional host-binding and envelope encryption, per secret

Operations and visibility

Web dashboard for hosts, tokens, audit, and health
Full audit trail to journald and your SIEM
Prometheus metrics
Rate limiting, with a separate budget for failed authentication
Self-service host enrollment with admin approval

Resilience

Client-side failover across servers
Active-active secondary server with its own HSM
Hot-standby HSM
Verification that decrypts every entry to prove a restore is good

On-premises by design

Runs entirely on hardware you own
No cloud service, no subscription, no third party holding keys or audit data
Works in isolated and air-gapped networks

Lean to deploy

No database, message broker, or container platform
One server daemon plus a small Bash client
Native systemd services, plain-text configuration
Windows wrapper and Java guidance for the hosts that are not Linux

Where it fits

Built for the estates platforms skip.

Arcenkey is at home in state and local government, utilities, healthcare, and mid-size regulated organizations: on-premises Linux, small teams, long-lived automation, and auditors who ask hard questions. It suits the integrators and managed service providers who run those estates on their customers' behalf just as well. ICP, the company that built it, is one of them.

It is not a replacement for a platform-scale secrets service where one is already working. It is for the hosts that service never reached.

Worth knowing up front

Arcenkey is a secrets store, not a file store. Values are size-capped; keep large blobs as files and put the key in Arcenkey.
The HSM is the root of trust. The wrap-key backup made at install time must be kept safe, and truly irreplaceable secrets should have an offline copy as well.
Live reads need the server reachable. There is deliberately no plaintext cache on clients, and the documentation covers the patterns that keep services running through an outage.
Today it supports the YubiHSM 2.