Infisical

Last reviewed Aug 26, 2026 · 824 words

Infisical fixes a problem most homelabs have and few admit: 20 compose stacks, 20 .env files, and no record of which API key lives where or when it was last rotated. The price is that the secrets manager itself is 3 containers (the app, PostgreSQL, Redis), a domain, and an encryption key you must never lose. Whether that trade pays off depends almost entirely on one question: does anything other than you read those secrets? If a CI runner, a Kubernetes cluster or a second human does, it pays off fast. If not, keep reading, because the last section names the lighter options.

The 3-container install and the 2 values you cannot lose

The project publishes a production compose file; the shape is an infisical/infisical container on port 8080, a Postgres 14-or-newer database and a Redis. The environment needs, at minimum:

ENCRYPTION_KEY=<openssl rand -hex 16>
AUTH_SECRET=<openssl rand -base64 32>
DB_CONNECTION_URI=postgres://infisical:password@db:5432/infisical
REDIS_URL=redis://redis:6379
SITE_URL=https://secrets.example.com

ENCRYPTION_KEY encrypts everything at rest. Lose it and a perfect database backup is a perfect pile of ciphertext, so store it in two places that are not the server. Back up Postgres nightly, back up the key separately, and do one restore into a scratch stack before you trust either. Put TLS in front with a reverse proxy; SITE_URL must match the public URL or login redirects and CLI callbacks break.

Secrets get out through the CLI, the operator, or the API

The dashboard is where you put secrets in. Getting them out without pasting is the point, and there are three paths that matter for self-hosters.

infisical login --domain https://secrets.example.com
infisical init                      # binds this directory to a project and environment
infisical run --env=prod -- docker compose up -d

infisical run injects the environment's secrets as variables into the child process, so the compose file references ${STRIPE_KEY} and no .env exists on disk. infisical export --format=dotenv writes one for tools that insist. For anything that is not a human, create a machine identity (Universal Auth issues a client ID and secret) and give it read on exactly one environment. On Kubernetes, the operator watches an InfisicalSecret custom resource and materialises a native Secret, so deployments never learn about Infisical at all. The integration catalogue also pushes secrets into GitHub Actions, GitLab, Vercel and a few dozen others, which is how it earns the "Doppler replacement" label.

Versioning is the feature you will actually use

Every change to a secret is versioned, with point-in-time recovery for the whole environment, so "which key was live last Tuesday" has an answer and a one-click rollback. Rotation is automated for specific targets (database credentials, some cloud IAM keys) and manual with reminders for the rest. Secret referencing lets one value be composed from others, ${BASE_URL}/api, so a single change propagates. Audit logs record who read what; for a solo operator that is mostly noise, for a team it is the reason to have a secrets manager at all.

What is gated behind the enterprise licence

The core is MIT, with an ee directory under a separate licence, the pattern Gitea and GitLab users will recognise. At last check the gated pieces are the ones a company buys: SAML and SCIM, some of the rotation targets, longer audit retention, finer-grained access policies. A homelab or a small team hits none of them. Read the current pricing page rather than trusting this paragraph, because the line moves.

Infisical versus the three tools you might already run

Vaultwarden is for secrets a human types: it has no machine identities and no CI injection, and using it for API keys means copy-paste. OpenBao (the open fork of HashiCorp Vault) is the choice when you need dynamic secrets, PKI, or a transit engine, and it is a considerably heavier operational commitment with a steeper policy language; the Vault alternatives page compares them directly. And for a solo homelab whose deployments come from one git repo, sops with age keys encrypts the .env files in place with zero servers, which is honestly enough for most single-operator setups. Infisical wins the middle: a team, a CI runner, a cluster, and a preference for a dashboard over a policy DSL. The AWS Secrets Manager comparison covers the cloud-migration case.

What I'd do

If you are one person deploying from one repo, use sops and skip the service. The moment a second reader appears, a Woodpecker runner, a k3s cluster, a collaborator, deploy Infisical: 3 containers behind Caddy, ENCRYPTION_KEY in two offline places, machine identities per consumer with read on one environment each, nightly Postgres dump. It replaces the .env sprawl within an afternoon, and the versioning alone will save you the first time a rotation goes wrong.