Meet RatelKey
Today, we’re introducing RatelKey: a secrets manager built for developers who want to keep their secrets on their own infrastructure and get on with building their applications.
The idea starts with a familiar problem. Moving beyond a .env file should be a manageable step. But running a secrets manager can bring a second job with it: assembling a database, authentication, certificates, backups, and an update process before an application can read its first secret.
RatelKey brings those pieces together in a Burrow, the secrets manager you download and run yourself. Your API keys, database passwords, and other secret values live there. Your applications connect to it for the values they are allowed to read.
That is the purpose behind RatelKey: make keeping secrets on your own infrastructure practical for developers and teams.
A Burrow you can run yourself
A Burrow packages the components it needs together, so getting started does not require standing up a collection of supporting services.
The current downloads are available for Linux and Windows on x86-64. Start the Burrow, open its dashboard at https://localhost:12010, and claim it with your RatelKey account. From there, create a project, add secrets, and enroll a machine.
Projects organize secrets around an application or service. Each project starts with Development, Staging, and Production environments, and each stage can contain additional environments.
You can store a single value or group related values into a structured secret. A database connection, for example, can hold its host, port, username, and password under one name, with a separate version history for each field. The projects documentation and structured secrets guide explain how these fit together.
Your machines talk to your Burrow
For a server or application host, enrollment generates an Ed25519 key pair on the machine. The private key stays there; the Burrow receives the public key. Subsequent requests are signed with that machine’s identity.
Access is explicit. A machine receives grants for a project’s Development, Staging, or Production category. A Production grant covers every Production environment in that project, including ones added later. Changes to those grants apply on the next request.
RatelKey also supports GitHub Actions through OIDC. You register the repository and workflow, optionally restrict it to a deployment environment, and let the Burrow verify the short-lived token GitHub issues for the run. For fleets of temporary machines, enrollment tokens can assign grants and a lifetime to each new identity. The machine documentation covers enrollment, with separate guides for GitHub Actions and machine grants.
Once enrolled and granted access, an application can use the CLI or an SDK. The documentation includes SDKs for Node.js, Python, .NET, and Kotlin. For example, the Node.js SDK discovers the enrolled identity on the host:
import { Burrow } from "@ratelkey/burrow-sdk";
const burrow = Burrow();
const databaseUrl = (
await burrow.getSecret("myapp/prod/DATABASE_URL")
).value;
When enrolling a machine, choose Encrypted + verified to have it verify the Burrow’s identity as well as encrypt the connection. The default Encrypted mode does not perform that identity check.
The self-hosting tradeoff, explained
RatelKey makes a deliberate division of responsibilities.
Your Burrow holds the secrets, their encryption keys, and its audit history. It authenticates machines locally. RatelKey operates human sign-in and the update service, and offers an optional relay.
A RatelKey account lets you enter the Burrows you belong to. The Burrow checks human sessions and membership with RatelKey on each request. That makes revocation effective on the next request, but it also means the dashboard depends on the sign-in service being available.
Machine authentication does not use that sign-in service. Machines that can reach their Burrow directly can continue authenticating and reading their permitted secrets during a RatelKey sign-in outage. A machine using the relay still depends on the relay for connectivity.
This is the choice described in RatelKey’s philosophy: keep secret storage under your control while letting RatelKey handle parts of the surrounding operation. The service terms spell out the dependency. Teams that need a fully disconnected system should account for it when evaluating the product.
Reach your Burrow without managing a tunnel
A Burrow may sit behind a home router, office firewall, or connection without a usable public address. The optional RatelKey Relay makes it reachable by having the Burrow establish an outbound connection.
TLS terminates at the Burrow. The relay forwards encrypted traffic, and the certificate’s private key stays on the machine running the Burrow. Certificate issuance and renewal are handled through the relay setup.
You can also connect directly over your network or an address you manage. The relay can be disabled.
Everyday operation is part of the product
Keeping secrets is only part of running a secrets manager. RatelKey includes the work around it:
- An audit trail: secret reads, changes, denied requests, and other actions are recorded in the Burrow. You can filter events and export them as CSV, JSON, or plain text.
- Canary secrets: an armed decoy disables a machine that reads it, cutting off that machine’s access on its next request and recording what happened.
- Encrypted backups: scheduled archives can be verified, downloaded, and restored using their backup passphrase.
- Master key rotation: the Burrow can replace its managed master key and rewrap the data keys without changing secret values.
- Signed updates: the Burrow checks a release’s signature, version, size, checksum, and platform before installing it. You choose whether installation is automatic.
These features are covered in the audit log, canary, backup, encryption, and update guides.
You still operate the host and protect its data. Backup archives need safe storage and their matching passphrases. Restoring a backup also requires machines to be enrolled again, so recovery is worth planning before you need it.
Start with one application
The Developer plan is free and includes three members per Burrow. Paid plans add more included members and team controls: custom roles and SAML/OIDC single sign-on on Teams, with SCIM provisioning on Teams Max. See current pricing for plan details.
A good first step is one application, one environment, and one machine. Move a secret into the Burrow, grant the machine access, read it through the CLI or SDK, and inspect the audit event. Then configure and verify a backup.
We’re pleased to introduce RatelKey to the SikkerKey community. If you want to run your secrets manager on infrastructure you control, download a Burrow and explore the documentation.
