Infisical: The Open-Source Secrets Platform That Swallowed PKI Whole

Hook

While most teams juggle separate tools for secrets (Vault), certificates (cert-manager), and SSH keys (manual chaos), Infisical bet that developers want one platform for all privileged access—and 26,000 GitHub stars suggest they were right.

Context

The traditional secrets management story goes like this: you start with environment variables in a .env file, graduate to AWS Secrets Manager when you go to production, then add HashiCorp Vault when you need dynamic secrets, bolt on cert-manager for TLS certificates, and eventually maintain a sprawling ecosystem of overlapping tools—each with its own API, authentication method, and operational overhead.

Infisical emerged in 2022 with a different thesis: secrets, certificates, and SSH keys are all just privileged credentials, and treating them as separate problems creates unnecessary complexity. Built entirely in TypeScript with a PostgreSQL backend, it takes a batteries-included approach that combines secrets vaulting, a full-featured PKI/certificate authority, KMS for encryption keys, and SSH certificate management in a single platform. The project is commercially backed with a managed cloud offering, but the entire codebase is open-source (MIT licensed for the core, with an enterprise license for advanced features), making it viable for both self-hosted and cloud-native deployments.

Technical Insight

Infisical's architecture revolves around a multi-tenant API server that separates the control plane (where secrets are managed) from multiple delivery planes (how secrets reach applications). The core is a Node.js/Express backend with PostgreSQL handling both metadata and encrypted secret storage, while Redis provides caching and pub/sub for multi-instance deployments.

What sets Infisical apart architecturally is its secret consumption model. Instead of forcing applications to pull secrets at runtime (the Vault model), it provides four distinct patterns:

// Pattern 1: SDK-based runtime fetching
import { InfisicalClient } from "@infisical/sdk";

const client = new InfisicalClient({
  auth: {
    universalAuth: {
      clientId: process.env.INFISICAL_CLIENT_ID,
      clientSecret: process.env.INFISICAL_CLIENT_SECRET,
    },
  },
});

const secrets = await client.listSecrets({
  environment: "production",
  projectId: "project-id",
  path: "/api",
});

// Pattern 2: Agent-based injection (no code changes)
// Secrets mounted as files or env vars by sidecar
// Application reads from /run/secrets/DATABASE_URL

// Pattern 3: Kubernetes operator declarative sync
// apiVersion: secrets.infisical.com/v1alpha1
// kind: InfisicalSecret
// spec:
//   authentication:
//     serviceAccount:
//       name: app-service-account
//   secretsPath: "/api/production"

// Pattern 4: Platform syncs (GitHub Actions, Vercel, etc.)
// Secrets automatically pushed to external platforms

This flexibility matters because different workloads have different constraints. Legacy applications can use the agent for transparent injection without code changes. Kubernetes-native apps can leverage the operator for GitOps-friendly declarative config. Modern microservices can use SDKs for dynamic fetching with caching. And CI/CD pipelines benefit from platform syncs that keep secrets in sync with GitHub Actions or Vercel.

The PKI implementation is particularly sophisticated. Infisical includes a full certificate authority with support for hierarchical CA chains, custom certificate templates, and automated certificate lifecycle management:

# Issue a certificate via CLI
infisical pki certificate issue \
  --ca-id ca_abc123 \
  --common-name api.example.com \
  --alt-names "*.api.example.com,api.internal" \
  --ttl 2160h

# Or integrate with ACME for Let's Encrypt
# Infisical acts as ACME server, handles DNS/HTTP challenges
certbot certonly \
  --server https://app.infisical.com/api/v1/pki/acme/issuer_xyz/directory \
  --email admin@example.com \
  -d example.com

Under the hood, certificates are stored as secrets with additional metadata for expiry tracking and renewal automation. The same RBAC system that governs secret access controls who can issue certificates, and the same audit logs capture both secret reads and certificate issuance. This unified approach means you're not maintaining separate access controls for your secrets vault and your certificate authority.

Dynamic secrets—credentials generated on-demand with automatic rotation—leverage a plugin system for different backends. For PostgreSQL:

// Dynamic secret leases are managed server-side
// Client requests a lease, gets temporary credentials
const lease = await client.createDynamicSecretLease({
  dynamicSecretName: "postgres-api-db",
  projectId: "project-id",
  environment: "production",
  ttl: "1h",
});

// Returns: { username: "v-root-abc123", password: "..." }
// Credentials auto-revoked after 1 hour
// No cleanup code needed

The platform manages the entire lifecycle: creating database users with limited privileges, tracking lease TTLs, and automatically revoking credentials when leases expire. This eliminates the operational burden of credential rotation while improving security posture—credentials that expire automatically can't be leaked indefinitely.

Authentication follows a dual-track approach: machine authentication (Universal Auth, AWS IAM, GCP OIDC, Kubernetes Service Accounts, Azure Managed Identity) for workloads, and human authentication (OIDC, SAML, LDAP) for dashboard access. The separation is intentional—machines shouldn't use the same auth flows as humans, and the architecture enforces this at the design level.

Gotcha

The biggest gotcha is resource consumption. A production Infisical deployment (backend API, Redis, PostgreSQL) will consume noticeably more memory than equivalent Go-based tools like Vault. In testing, a moderate workload (~10k secrets, 100 req/s) requires around 2GB RAM for the API server compared to ~512MB for Vault. The TypeScript/Node.js stack trades runtime efficiency for developer velocity and a richer ecosystem of integrations. For small teams self-hosting on limited infrastructure, this overhead adds up.

Feature richness creates operational complexity. The platform exposes dozens of configuration options across secrets, PKI, KMS, and SSH management. Teams wanting simple key-value secret storage will find themselves navigating UI sections and documentation for features they'll never use. The learning curve is steeper than simpler alternatives like Doppler or cloud-native options. Additionally, while the project has good documentation, the ecosystem of third-party integrations and community plugins is much smaller than HashiCorp Vault's—expect to build custom integrations for niche platforms. Finally, the commercial open-source model means some advanced features (advanced RBAC, audit log exports, SLA guarantees) are gated behind the paid tier, which may surprise teams expecting full functionality in the self-hosted version.

Verdict

Use if: you're building on modern infrastructure (Kubernetes, major cloud providers) and need more than basic secret storage—particularly if you're currently running separate tools for secrets and certificates, or if you need dynamic secrets and extensive platform integrations (GitHub, Vercel, AWS, etc.). The unified approach and excellent developer experience justify the complexity for teams managing privileged access at scale. Also ideal if you want open-source flexibility with the option to upgrade to managed cloud later. Skip if: you only need simple key-value secret storage (use cloud-native options or Doppler instead), you're already deeply invested in the HashiCorp ecosystem (Vault integration costs outweigh benefits), you're running on extremely resource-constrained infrastructure where the Node.js overhead matters, or you need proven performance at extreme scale (millions of secrets, thousands of concurrent requests). Small teams without dedicated platform engineers may find the operational overhead excessive for simple use cases.