Self-Host Infisical: A Secrets Manager for Your Apps and Agents

Here's a confession: for years my idea of "secrets management" was a .env file that lived in three places, drifted out of sync in all of them, and occasionally got pasted into a Slack thread so a teammate could unblock themselves. Then someone rotates a database password, forgets one of the copies, and staging goes down at 6pm on a Friday. If that story makes you wince, you already know why a real secrets manager is worth setting up.

Infisical is the open-source tool I wish I'd had back then. It's an end-to-end encrypted platform for storing API keys, database URLs, tokens, and certificates, then handing them to your apps, your CI pipelines, and increasingly your AI agents without ever writing them to disk. Let's get it running and actually use it.

What Infisical does

Think of Infisical as one central, encrypted home for every secret your stack needs. Instead of a .env per service, you store secrets in a web dashboard, organized by project and by environment (development, staging, production). Your code pulls what it needs at runtime.

The parts you'll reach for most:

• Environments and projects so a DATABASE_URL means the right thing in dev and in prod without you juggling files.
• Machine identities that let a server, container, or agent authenticate on its own, no human login required.
• Dynamic secrets that generate short-lived database credentials on demand and revoke them automatically.
• A CLI and SDKs (Node, Python, Go) that inject secrets into any process.

Getting it running on Elestio

Self-hosting Infisical by hand means standing up PostgreSQL, Redis, an encryption key, and an auth secret, then keeping all of it patched. On Elestio it's a one-click deploy on a dedicated VM with the database, backups, SSL, and updates handled for you. A small team fits comfortably on a NC-MEDIUM-2C-4G instance at around $16/month, and you can size up later. It's open-source, so there are no per-user or per-seat license fees, just the VM.

Deploy it from the Elestio Infisical page, open the admin URL, create your first account, and you've got a running vault. Create a project (say, web-app) and add a few secrets to the development environment to follow along.

Injecting secrets into your app

You don't want your code calling an API and parsing JSON just to read a config value. The Infisical CLI handles that for you. Install it, point it at your self-hosted instance, and log in:

export INFISICAL_API_URL="https://your-infisical.vm.elestio.app/api"
infisical login

Now, instead of loading a .env, wrap your process. Infisical fetches the secrets for the current project and environment and injects them as environment variables, only for that process:

infisical run --env=dev -- npm run dev

Your app reads process.env.DATABASE_URL exactly like before. The difference is that nothing sensitive is sitting in a file on the machine. Delete the .env, and don't look back.

Machine identities for CI and agents

Humans logging in is fine for local dev. Servers, pipelines, and AI agents need to authenticate on their own. That's what machine identities are for. In the dashboard you create an identity, enable Universal Auth, and get a client ID and client secret. In your pipeline you exchange those for a short-lived token:

export INFISICAL_TOKEN=$(infisical login --method=universal-auth \
  --client-id="$INFISICAL_CLIENT_ID" \
  --client-secret="$INFISICAL_CLIENT_SECRET" \
  --silent --plain)

infisical run --projectId=<your-project-id> --env=prod -- npm run start

The only two secrets your CI system stores are the client ID and secret. Everything else lives in Infisical, and you can revoke an identity the moment a runner is compromised. The same pattern works for an AI agent that needs a scoped set of credentials: give it its own identity, grant it only the secrets it should touch, and rotate on your terms.

The feature that changes how you think: dynamic secrets

Here's the part everyone underestimates. With dynamic secrets, Infisical doesn't store a database password at all. It connects to your Postgres or MySQL server, and when a client asks, it creates a brand-new user with a short time-to-live, hands over those credentials, and drops the user when the lease expires.

So your app or agent gets a database login that's valid for, say, one hour. If it leaks, it's already useless. There's no long-lived master password sitting in an environment variable waiting to be exfiltrated. For agent workloads that run untrusted or semi-trusted code, that blast-radius reduction is the whole game.

Is it worth it versus a SaaS secrets tool?

Managed secrets services bill per secret or per seat, and it adds up fast.

Plus your secrets, and the audit log of who touched them, stay on infrastructure you control.

Troubleshooting

A few things that tripped me up so they don't trip you:

• infisical login opens the wrong instance. The CLI defaults to Infisical Cloud. Set INFISICAL_API_URL to your Elestio instance (with the /api suffix) before logging in.
• Secrets come back empty. You're almost always pointed at the wrong environment. Double-check the --env slug (dev, staging, prod) matches what's in the dashboard, and that the project ID is correct.
• CI runs are slow. Set INFISICAL_DISABLE_UPDATE_CHECK=true in your pipeline so the CLI skips its version check on every run.
• Dynamic secrets fail to create users. The database role Infisical connects with needs privileges to create and drop users. Grant it those on a dedicated admin connection, not your app's role.

Where to go from here

Start small: move one service off its .env file and onto infisical run. Once you trust it, wire up machine identities for CI, then try dynamic secrets on a non-critical database. Each step shrinks the number of long-lived credentials floating around your stack, which is really the only metric that matters.

You can deploy your own managed Infisical on Elestio in a couple of minutes and have a real vault instead of a folder full of .env files.

Thanks for reading ❤️ See you in the next one 👋