RatelKey vs Infisical
Summary
Both RatelKey and Infisical keep your secrets on your own infrastructure. The difference is what it takes to get there. A Burrow is a single download: run it and it is ready, with its database, encryption, HTTPS and updates built in. There is nothing else to install, configure or keep running beside it.
Self-hosting Infisical means building the stack it depends on. It needs PostgreSQL, and Redis, which Infisical calls a hard dependency to be kept as available as Infisical itself. You generate an encryption key and an auth secret, and the encryption key has to be backed up separately, because without it a restored database can't be decrypted. Email invites and multi-factor sign-in need an SMTP server. Infisical describes its Docker Compose setup as a proof of concept and points production users to Kubernetes.
A Burrow is production-hardened from its first start. It serves HTTPS with its own certificate, encrypts every value with AES-256-GCM under a master key it generates and can seal to your machine's TPM, rate-limits requests out of the box, and installs updates signed by RatelKey, rolling back on its own if a new version fails to start. RatelKey runs sign-in, passkeys, two-factor and team management for you, so there is no identity provider or mail server on your side to operate.
Everything that keeps your secrets accountable is included on every plan: the full audit log, version history, automatic rotation, canary secrets and share links. On Infisical, audit logs and secret versioning start on paid plans, and a self-hosted instance needs an Enterprise license for audit logs.
A Burrow runs production-ready the moment you start it, with its full audit log included on every plan, while self-hosting Infisical means running its database, cache and supporting services yourself and paying to unlock its audit logs.
| Feature | RatelKey | Infisical | Why it matters |
|---|---|---|---|
| 01Machine Identity | |||
| Machines (Ed25519) | Every request a machine makes is signed with its own Ed25519 private key, generated on the machine and never sent anywhere. Each signature covers the exact operation, a timestamp and a one-time nonce, so a captured request can't be replayed or pointed at another secret. You add a machine with a one-time command from the dashboard, the Burrow stores only its public key, and with approval turned on it waits for a member before it can read anything. | Machines sign in with a method such as Universal Auth's client ID and client secret, then send the access token they receive with each request.Requests carry a bearer token, valid for 30 days by default. | Your machines never send a secret to get a secret. There is no token to leak from a log, a proxy or an intercepted request, and every read traces back to one named machine you let in. |
| Machine tokens | One token enrolls any number of short-lived machines, each with its own key and a lifetime you choose, from a minute to 90 days. The token decides what its machines can read and can require a source IP range and a hostname pattern. The SDKs can keep the key in memory only and enroll a fresh machine before the old one expires. Revoke the token and nothing new can enroll, while the machines it created run out on their own. | Workloads authenticate as an identity you set up in advance, with its credentials or through their platform, such as Kubernetes, AWS or OIDC.No token that enrolls each short-lived machine as its own identity with its own lifetime. | CI runners, containers and autoscaling fleets get their own identity the moment they start, with nobody needed to approve them, and that identity expires with them. You never end up with forgotten machines that can still read your secrets. |
| Machines (OIDC) | A workflow reads secrets with the OIDC token its CI platform issues for each run, with GitHub Actions supported today. You name the repository, the workflow file and, if you want, the environment. The Burrow accepts a token only when all of them match and the token was issued for your Burrow. | Supports OIDC auth for GitHub Actions, GitLab CI/CD, CircleCI and other platforms. | Connect a CI workflow in a minute using the identity its platform already gives every run. Access stays limited to the exact repository, workflow and environment you choose, so a fork or a different workflow can't read your secrets. |
| 02Secrets | |||
| Single-value secrets | One named value per environment, identified by its slug, such as payments/prod/DATABASE_URL. | Secrets are key and value pairs stored per environment and folder. | Every environment keeps its own value under the same name, so your code reads the same secret in development and production, and only the environment it points at changes. |
| Structured secrets | One secret holds a set of named fields, each with its own type and its own version history. Reading the secret returns every field in one request, and your app takes any one of them by name. | Each secret is one key and one value. Related values are grouped by folder.No secret made of several named, typed fields. | A database login or an API client is several values that belong together. Keep them as one secret, change one field without touching the others, and have your app ask for exactly the field it needs by name. |
| Secret versions | Every change to a secret, or to one field of a structured secret, is kept as a new version with who made it and when, and every version is encrypted under its own data key. Reverting restores an earlier version by adding it as a new one, so the history is never rewritten and a revert can itself be undone. | Tracks changes per folder and environment, with revert and roll back to an earlier commit.Secret versioning and point-in-time recovery start on Pro, and need an Enterprise license when self-hosted. | A bad change is fixed in seconds: restore the last good value and your machines read it on their next request, with the full history still showing what happened. |
| Canary secrets | A decoy secret with a generated value that sits among your real ones. When it is armed, any machine that reads it is disabled on the spot and the read is recorded in the audit trail with the machine's name, where a webhook can send it straight to you. | Honey tokens plant decoy AWS IAM credentials and email organization admins when they are used.AWS credentials only, and the machine that read the decoy keeps its access. | No legitimate workload ever reads a canary, so a read means a machine is being misused. You find out the moment it happens, and that machine is already cut off before it reaches anything else. |
| Typed values | Every value has a declared type: string, integer, decimal, boolean, JSON, JSON5, YAML, XML, email, URL, UUID, password, token, hex, base64 or HMAC. The Burrow checks each value against its type when it is saved, the type holds across every environment and version, and every read returns it alongside the value. | Secret validation rules can require a length, a regex pattern, or a prefix or suffix before a value is stored.No declared value types such as integer, JSON, YAML, URL or UUID. | A malformed value is refused when someone saves it, so a typo in a port number or a broken JSON blob never reaches production and takes your app down at startup. |
| Share links | Send one secret to a person through a link that opens a set number of times, from 1 to 1,000, and expires between 5 minutes and 30 days. Add a generated passphrase, and five wrong tries destroy the link, or limit it to signed-in members of your Burrow. The link shows the value as it was when you shared it, and every open is recorded in the audit trail. | Secret sharing links with a view limit, an expiry, an optional password, and an option to limit access to organization members. | Hand a contractor or a colleague a credential without pasting it into chat or email, where it stays forever. The link runs out on its own, and you can see exactly when it was opened. |
| Automatic rotation | A secret replaces its own value on a schedule, every 5 minutes up to every 30 days, or on chosen weekdays at a set time in your time zone. The new value is generated to fit the secret's type: random characters, a UUID, random bytes as hex or base64, or a number in a range. On a structured secret you choose which fields rotate. Each rotation is a new version. | Rotates credentials held by external systems, such as database users and AWS or Cloudflare keys.No scheduled rotation of a secret's own value. Rotation starts on Pro for databases and Advanced for the rest. | Credentials stop living forever. A leaked value is only good until its next rotation, your machines pick up the new one on their next read, and nobody has to remember to change it. |
| 03Audit & Alerts | |||
| Audit log | Every action in your Burrow is recorded, including every secret a machine reads and every attempt that was refused: who did it, what it touched, when, and from which address, with the client and version behind each machine read. Filter by person, machine, action, severity, address and time, and export to CSV, JSON or text. Everything is kept until you choose a retention period, anywhere from a day to ten years. | Audit logs record actions across the organization, with retention that depends on the plan.Starts on Pro, and a self-hosted instance needs an Enterprise license. | When something looks wrong, you can answer exactly who read which secret, from where and with what, in seconds. The export drops straight into your SIEM or a spreadsheet for an auditor. |
| Webhooks | Send any audit event to Slack, Discord, or your own endpoint as signed JSON your endpoint can check came from your Burrow. Subscribe to exact events, whole families such as secret.*, or everything. Only changes that actually happened are sent, deliveries are queued on disk and retried with backoff, and an endpoint that keeps failing is paused instead of piling up attempts. | Signed webhooks to any HTTPS endpoint, Slack or Microsoft Teams for secret changes, rotation failures, honey token triggers and requests.Sending every audit event out, through audit log streaming, is an Enterprise feature. | Hear about what matters the moment it happens, such as a canary being read or a share link being opened, in the channel your team already watches. |
| 04Identity & Access | |||
| Built-in roles | Every Burrow comes with Administrator, Developer and Member. Administrators run the Burrow's contents, its members, the audit log and webhooks. Developers create and change secrets, machines and machine tokens, but can't delete them or see the audit log. Members can sign in and read the Burrow's note until you give them more. Their definitions are fixed, so Administrator means the same thing in every Burrow, on every plan. | Comes with built-in organization and project roles. | Give someone the right level of access in one click, without designing a permission scheme first. Developers can do their work without being able to wipe out production. |
| Custom roles | Build a role from a grid of every area in the Burrow, from secrets, machines and the audit log to each section of Settings, each with read, write and delete. Nobody can grant more access than they hold, or change a member or role that outranks them. Included on Teams and Teams Max. | Custom roles with permissions per project and environment.Split across two plans: basic custom roles on Pro, full role control on Advanced. | Give an on-call engineer the audit log without secret access, or let someone manage backups without touching the master key. Each person gets exactly what their job needs. |
| Members & invitations | Invite people by email with their role chosen up front, even before they have an account. Disable a member to cut their access while keeping their role for later, or remove them outright. Your Burrow checks each member's access with RatelKey on every request, so a role change or removal applies on their very next click. | Invite members to the organization and its projects, and remove them at any time.A self-hosted instance needs an SMTP server of yours to send invites. | When someone leaves or changes teams, their access changes the moment you say so. There is no cached permission or session left behind that still works. |
| Single sign-on | Connect your own identity provider over SAML or OIDC. Optionally create accounts on first sign-in with a default role, limited to email domains you have verified, and require SSO so everyone but the owner signs in through it. Turning that on signs out every session that didn't come through your provider. Included on Teams and Teams Max. | SAML and OIDC single sign-on with common identity providers, on paid plans.Enforcing SSO for everyone starts on Advanced. | Your team signs in the way they already do everywhere else, and your identity provider's policies, such as MFA and device checks, apply to your secrets too. |
| SCIM provisioning | Your identity provider pushes users and groups to your Burrow, and each group maps to a role. Remove someone in your provider and their Burrow access is cut. A member disabled by hand stays disabled whatever the provider says. Included on Teams Max. | SCIM provisioning from your identity provider, on the Enterprise plan. | Onboarding and offboarding happen in one place. Nobody keeps access to your secrets because someone forgot a second system. |
| Passkeys | Sign in with a passkey alone, with no password on the account at all, or add one alongside a password as its second factor. A passkey is a complete sign-in on its own, because your device confirms it's you. Included on every plan. | WebAuthn can be used as a second factor after a password.Not documented as a way to sign in on its own, without a password. | Your team signs in with a fingerprint, a face or a security key in a second, with no password to remember or type. |
| Two-factor authentication | Turn on an authenticator app for two-factor sign-in, with recovery codes that get you back in if the phone is lost. Included on every plan. | Two-factor sign-in with an authenticator app or a code sent by email.Email codes on a self-hosted instance need your own SMTP server. | Add a second step to sign-in with the authenticator app your team already uses, and keep access when a phone goes missing. |
| GitHub sign-in | Create an account, sign in, or link GitHub to an existing account. Linking is done from inside your account and never by matching email addresses, and there is no OAuth app for you to register. Included on every plan. | GitHub sign-in, available on cloud and self-hosted.A self-hosted instance needs its own GitHub OAuth app registered and configured. | Your team signs in with the GitHub account they already use every day, with nothing to set up first. |
| 05Deployment | |||
| Linux | Runs on Linux, on x86-64 and ARM64. Install it with one command or from the download page, bundled with nothing else to install. Starts at boot as a systemd service, and can seal its master key to the machine's TPM 2.0. | Offers a Linux package for native installation.PostgreSQL and Redis have to be installed and run alongside it. | Host your secrets on hardware you already run, from a cloud server to a small board on your own network, with nothing to install or maintain beside it. |
| macOS | Runs on macOS, on Apple silicon and Intel. Install it with one command or from the download page, bundled with nothing else to install. Starts at boot through launchd. | No native macOS server install. Its self-hosting options are Docker, Kubernetes, a Linux package and cloud reference setups. | Run your Burrow on a Mac you already have, such as a Mac mini on your network, with every feature it has on any other system. |
| Windows | Runs on Windows, on x86-64. Install it with one command or from the download page, bundled with nothing else to install. Starts at boot as a Windows service, and can seal its master key to the machine's TPM 2.0. | No native Windows server install. Its self-hosting options are Docker, Kubernetes, a Linux package and cloud reference setups. | Teams on Windows servers host their secrets on the machines they already manage, running as an ordinary Windows service. |
| Docker | Runs in Docker on Linux, on x86-64 and ARM64. Install it with one command or from the download page, bundled with nothing else to install. Starts at boot with Docker, and keeps its data and updates in a volume when the container is recreated. | A Docker image and a Docker Compose setup that runs Infisical with PostgreSQL and Redis.Infisical describes the Compose setup as a proof of concept and recommends Kubernetes for production. | Run your Burrow alongside the rest of your containers and manage it the same way, with nothing lost when the container is replaced. |
| Signed updates | Your Burrow updates itself on every platform, automatically or with one click. Before anything is written, each release is checked for RatelKey's signature, its published checksum and a newer version than the one running. If a new version fails to start, the Burrow rolls back to the one that was working. | You upgrade by backing up PostgreSQL, reviewing the release notes and deploying the new version yourself. Database migrations run when it starts.No self-update, and no automatic rollback. | Stay on the latest Burrow without thinking about it. Every update arrives through a channel only RatelKey signs and lands with a quick restart, so updating is something you can leave switched on. |
| RatelKey Relay | Every Burrow gets its own address at your-burrow.ratelrelay.com, reachable from anywhere with no port to open and no fixed IP needed. Your Burrow connects out to RatelKey and keeps the connection open, and the encryption runs from the browser or machine all the way to your Burrow, under a certificate your Burrow holds the key for and renews by itself. Free, on by default, and switched off from Remote access whenever you like. | Its Gateway and Relay let Infisical reach resources inside your private network, on the Enterprise plan.Making a self-hosted instance reachable from outside your network is up to you. | Run your Burrow at home, behind a company firewall or on a shared connection, and your team and machines still reach it from anywhere, with nothing to set up on your network. |
| 06Encryption & Keys | |||
| AES-256-GCM encryption | Every secret value, and every version of it, is encrypted with AES-256-GCM under a fresh 256-bit data key of its own, which is wrapped by your Burrow's master key. Each ciphertext is authenticated against its project, environment, secret, field and version, so it decrypts only in the place it was written. | Encrypts secrets with AES-256 keys in a key hierarchy under a root key from ENCRYPTION_KEY, an HSM or an external KMS. | Every value gets standard authenticated encryption with a key no other value shares, and its integrity is checked on every read. |
| TPM 2.0 key sealing | On Linux and Windows, seal your Burrow's master key to the machine's TPM 2.0 in one click. From then on the key opens only on that machine, and secrets read just as fast as before. Turn it off again whenever you like, and backups still restore on any machine. | The root key can come from an external HSM such as Thales Luna or AWS CloudHSM.No sealing to the machine's own TPM. An HSM is separate hardware or a cloud service you run. | Tie your secrets to the hardware they run on, using the chip your server already has, at no extra cost and without changing anything for your apps. |
| Master key rotation | Rotate the master key in one click. Your Burrow generates a new key and re-encrypts every data key under it in a single step, while secret values stay as they are, so machines, SDKs and the CLI keep reading without any change. Every backup keeps the keys it was taken with and still restores, and each rotation is recorded in the audit log. | Generate a new root encryption key in the server console, then deploy it to every instance.The rotation only takes effect once you redeploy the instances with the new key. | Replace your key whenever your policy calls for it, with no downtime and no app to redeploy. |
| Encrypted backups | Every backup is encrypted with AES-256-GCM under a key derived with Argon2id from a ten-word passphrase your Burrow generates and shows you once. Each archive carries everything it needs, so it restores on any Burrow with only the file and the passphrase. | Backups are yours to set up, for example with pg_dump and your own encryption.No built-in backups, and the ENCRYPTION_KEY has to be kept separately to restore them. | Keep copies of your whole Burrow wherever suits you, on another disk or in cloud storage, and bring them back on any machine when you need them. |
| HTTPS by default | Your Burrow serves HTTPS from its first start with a certificate of its own. Upload your own, or give it a domain and it gets a Let's Encrypt certificate and renews it by itself. Plain HTTP is answered only on the local network, for a tunnel or reverse proxy on the same machine. | Serves plain HTTP by default. HTTPS is turned on with HTTPS_ENABLED and your own certificates, or with a reverse proxy in front.No certificate out of the box, and no built-in Let's Encrypt. | Every connection to your Burrow is encrypted from day one, and moving to a trusted certificate takes a minute. |
| 07Developer Tools | |||
| Node.js SDK | @ratelkey/burrow-sdk, for Node.js 18.17 and later, with zero runtime dependencies and TypeScript types. Reads single and structured secrets, follows changes live, enrolls short-lived machines in memory, signs in with OIDC, and verifies your Burrow's signed webhooks. | @infisical/sdk reads and manages secrets, dynamic secrets and KMS keys, signing in with Universal Auth or AWS IAM.Its docs don't cover following changes live or verifying webhook signatures. | Bring secrets into your Node.js app in a few lines, and pick up new values the moment they change, with nothing to restart. |
| Python SDK | ratelkey-burrow-sdk, for Python 3.9 and later, with one dependency. Reads single and structured secrets, follows changes live, enrolls short-lived machines in memory, signs in with OIDC, and verifies your Burrow's signed webhooks. | infisicalsdk reads and manages secrets, dynamic secrets and KMS keys, signing in with Universal Auth, AWS, OIDC, LDAP or a token.Its docs don't cover following changes live or verifying webhook signatures. | Bring secrets into your Python app in a few lines, and pick up new values the moment they change, with nothing to restart. |
| Kotlin / Java SDK | com.ratelkey:burrow-sdk, for Kotlin and Java on JDK 17 and later, with one runtime dependency. Reads single and structured secrets, follows changes live, enrolls short-lived machines in memory, signs in with OIDC, and verifies your Burrow's signed webhooks. | An official Java SDK for reading and managing secrets. | Bring secrets into your JVM app in a few lines, and pick up new values the moment they change, with nothing to restart. |
| .NET SDK | RatelKey.Burrow.Sdk, for .NET 8 and later, with one dependency. Reads single and structured secrets, follows changes live, enrolls short-lived machines in memory, signs in with OIDC, and verifies your Burrow's signed webhooks. | An official .NET SDK for reading and managing secrets. | Bring secrets into your .NET app in a few lines, and pick up new values the moment they change, with nothing to restart. |
| CLI | ratel, installed with npm on Linux, macOS and Windows. Enroll a machine with one command, read any secret, and run your app with an environment's secrets as variables, restarting it when they change. Sign in as yourself to manage your Burrow from the terminal, in an interactive session or from scripts. | The infisical CLI, installed with Homebrew, winget, Scoop, npm or Linux package repositories. infisical run injects secrets into a command, and --watch restarts it when they change. | Use your secrets anywhere a shell runs, with no code changes, and manage your Burrow without leaving the terminal. |
The Infisical details on this page are our reading of publicly available information as of 9 October 2026, and can change. Check Infisical's own documentation for the current state.
Download the Burrow