seekrit vs Infisical

Comparison·Infisical

Infisical is a popular open-source secrets manager: static secrets, dynamic database credentials, PKI, and an encryption-as-a-service KMS, self-hostable or run as their cloud. This page is about that core platform — not Infisical Agent Vault, their separate credential-broker product, which we compare against on its own page.

If Infisical is breached, what does the attacker get?

Infisical's own security architecture doc lays out the chain plainly: an operator-supplied root encryption key (a 256-bit AES key, held as an environment variable or sourced from an HSM) protects an Internal KMS Root Key, generated once per Infisical instance and stored in the database, which in turn protects every organization's and project's data keys, which protect the ciphertext. Per-tenant data keys do give "cryptographic isolation between tenants" — but they sit below the root key in that chain, not beside it. Holding the root key plus a copy of the database lets an attacker decrypt every data key that instance's Internal KMS Root Key wraps — which is everything on that instance, not one tenant's slice of it. Infisical's docs don't say whether Cloud runs one shared instance across all customers or isolates them, so we won't claim that part; what their own doc does establish is that the root key, wherever it lives, is the chain's single upper bound. To Infisical's credit, the same page states that "compromising the database alone is insufficient to decrypt sensitive data" — you need the root key too — and a project can move its root of trust to an external KMS (AWS KMS, GCP KMS) instead. Self-hosting also means that root key is yours alone, shared with no other tenant. None of that changes the shape of the risk: wherever the root key lives, one secret protects everything behind it, and Infisical's own threat model explicitly lists "runtime memory intrusion" — reading the live server's memory, which is exactly where the unwrapped root key sits "during operation" — as out of scope.

If seekrit is breached: there's no equivalent key to find. Our security model states it at its real strength and no stronger — secrets are encrypted client-side under a key derived from your passphrase, or wrapped individually to each principal's public key, and the server stores only ciphertext, wrapped keys, and metadata. A full compromise of our database, our infrastructure, or our staff yields ciphertext and the names of your secrets, not their values, because no seekrit process ever holds a key that unwraps more than one principal's own grant. Three honest boundaries on that: metadata is visible — org, app, environment, and secret names, versions, and timestamps are not encrypted, so don't put anything sensitive in a name. Third-party sync is the one opt-in exception — pushing a secret to a platform we can't run code in front of needs plaintext at a point with no client present, so that one sync engine can decrypt, per environment, only where you turned it on. And the guarantee is about us being breached, not about every way a credential can leak: a leaked passphrase or service token still exposes whatever that principal was granted, same as anywhere else.

This isn't an abstract comparison of designs. A platform holding the ability to decrypt customer-stored values has been exactly the failure mode behind recent, public disclosures — Railway's incident described possible access to customer environment variables, including some decrypted values, and Northflank told every customer to "assume their environment variables are decrypted and begin rotation immediately." Neither is Infisical, and we're not claiming otherwise — but both are the same architecture shape: a service that holds what it needs to decrypt on your behalf.

What seekrit's design makes possible

Per-principal wrapped grants are also what let an agent never hold the credential at all: the egress proxy substitutes {{seekrit:NAME}} at the network boundary, the hosted MCP server holds no tool that can return a secret value (enforced by a test), and agent access policy is signed in the publisher's browser so the server can serve it without being able to forge a wider one. Temporary-access mints credentials that expire rather than ones that need rotating.

Where Infisical is the better pick

Dynamic secrets, broader and more mature. Infisical generates ephemeral, auto-revoked database credentials for PostgreSQL, MySQL, MSSQL, Oracle, MongoDB, Azure SQL Database, Vertica, and SAP ASE — enterprise database engines (MSSQL, Oracle, SAP ASE) seekrit's temporary -access doesn't reach at all. Ours covers Postgres, MySQL/MariaDB, Redis, SSH, AWS, GCP, and MongoDB. Infisical's is gated to their Advanced Cloud plan, or an enterprise license even self-hosted.

PKI, which seekrit doesn't have at all. Infisical issues and manages X.509 certificates — private or external CAs, ACME/EST/SCEP enrollment, approval workflows, expiry alerting — documented at their PKI overview.

A genuinely open, fully self-hostable core — see what that costs below.

Compliance attestations seekrit doesn't hold. Infisical states it holds SOC 2 Type II, HIPAA, and GDPR certifications, with FIPS 140-3-validated crypto modules available in their Enterprise FIPS mode. Per our own trust page, seekrit holds none of those yet.

What self-hosting Infisical actually costs

Self-hosting answers "the vendor can read my secrets" by making it true that nobody but you can — but it does that by moving the root key to you and handing you the job of operating the system around it, not by removing the key. Worth being concrete about what Infisical's own docs say that job involves:

• A database and cache to run. Docker Compose bundles Postgres and Redis for evaluation; their HA reference architecture recommends a managed HA Postgres (RDS Multi-AZ, Cloud SQL HA, or equivalent) and a managed HA Redis for production, or self-managing a 3-node Postgres/Patroni/Etcd cluster and a 3-node Redis/Sentinel cluster if you don't.
• A root encryption key you generate and keep. Their production hardening guide marks generating the ENCRYPTION_KEY and AUTH_SECRET as the two required steps — openssl one-liners, with nowhere documented to recover them if you lose them.
• Upgrades and backups you run. Their upgrade guide and Linux upgrade guide both say to back up the database first; the HA architecture doc lists "backup strategy and point-in-time recovery" as something you plan for self-managed Postgres, without specifying a schedule or retention target.
• Monitoring and hardening. A dedicated monitoring guide covers Grafana and OpenTelemetry; the hardening guide adds TLS, firewalling, Docker/Kubernetes security settings, and disabling public signup as recommended (not required) steps.

To Infisical's credit, none of this is overstated in their own docs — the single-container and Compose paths really are described as the quickest way to get an instance running, and they don't pretend that's the same thing as a production deployment. Someone on your team owns that database, that key, and those upgrades, because the whole point of self-hosting is that nobody else can.

seekrit's side of this is nothing to deploy. npx -y @seekrit/cli init --org-name "Acme Storefront" --yes signs up, mints a machine credential, and writes a config file — no database, no container, no key to generate, because the security model means there's no root key for seekrit to hold on your behalf in the first place. The API runs on Cloudflare's global edge, with no cluster for you to size and no secret material to replicate, reads are cached at the edge, and a single org can drive tens of thousands of resolves a day without you provisioning anything for it. That's the trade self-hosting exists to make — and you get it without self-hosting anything, because "the vendor can decrypt this" was never true of our design to begin with.

To be fair about the other side of that trade: seekrit's customer-side pieces — the egress proxy, seekrit run, the ESO Kubernetes sidecar, and the provisioner — do run in your environment too. They're small single binaries or containers with no database behind them, not nothing.

Where self-hosting is still the right call: an air-gapped network, a data-residency mandate, a requirement that no third party hold even your ciphertext, or a team that already runs Postgres-and-Redis-shaped infrastructure well and would rather extend that than add a SaaS vendor. Any of those settles it in Infisical's favor regardless of the rest of this page.

Side by side

When Infisical is the right call

• You need dynamic secrets for a database we don't cover — Oracle, MSSQL, SAP ASE, Vertica — or want the breadth of a mature secrets-engine product.
• You need certificate issuance from the same platform.
• You want to run it entirely yourself, so the root key answers to nobody but you, and you're prepared to operate the deployment and its database.
• A compliance checklist needs an attestation today.

When seekrit is the right call

• You want no key anywhere, operated by anyone, that opens more than one principal's own access — not "we promise not to use it," a design with nothing to compromise that reaches further than that.
• AI agents are the ones holding credentials, and you want the agent to never hold the value at all.
• You don't want to run a secrets platform. Infisical self-hosted is real infrastructure — a database, a control plane, an operator holding the root key. seekrit is one thing to point your tools at.

The bottom line

Infisical built a broad, mature, genuinely open-source secrets platform, and if you want to run every part of it yourself — database included — it's a strong, well-documented choice with dynamic secrets and PKI we don't have. What it isn't is zero-knowledge: by its own architecture doc, one key protects everything behind it, wherever that key lives. seekrit trades that breadth for a design with no such key to begin with.

npx -y @seekrit/cli proxy run --preset openai

Free for one developer, no card, and nothing in the path that can decrypt your keys except the client asking for its own.