Skip to main content
Infisical Secrets Management is a central store for the secrets used by applications and infrastructure. It replaces .env files, hardcoded credentials, and secrets that are shared between team members through channels such as Slack. Once secrets are stored in Infisical, they can be delivered to the systems that use them.

Secrets Management docs

Quickstart, project structure, delivery methods, rotation, dynamic secrets, and integrations.

​
Use cases

​
Pull at runtime

Deliver secrets to running apps

Fetch secrets from Infisical at runtime through the CLI, SDKs, agents, Kubernetes, or CI/CD.

Replace .env in local development

Run an application locally and fetch its secrets from Infisical instead of a .env file.

​
Sync to a native store

Sync secrets to third-party stores

Forward secrets from Infisical to platforms such as GitHub, GitLab, AWS Secrets Manager, and Vercel.

​
Generate per request

Rotate a long-lived credential

Automatically replace a credential on a schedule managed by Infisical.

Generate short-lived credentials

Generate a credential at the time of the request and revoke it after a short period.

​
Broker to AI agents

Broker credentials to AI agents

Attach credentials to agent requests at a proxy so that the agent never receives the credential.

​
What is a secret?

A secret is a confidential value that an application uses to authenticate with or otherwise access another system. Common examples include database passwords, API keys, signing keys, and access tokens. If a secret is exposed to a party that isn’t authorized to use it, the systems it grants access to are also exposed.

​
Why manage secrets centrally?

As an organization grows, secrets tend to be duplicated across multiple locations. The same credential can be committed to source code, shared in chat messages, copied into CI/CD configuration, and stored in developer .env files. When a credential is stored in many places, it becomes difficult to track who has access to it, when it was last rotated, and where its value needs to be updated when it changes. Storing secrets centrally in Infisical addresses these problems by providing a single location where a secret’s value is stored, a single set of access controls that determine who can read the secret, an audit log of accesses and changes, and a single place from which the secret can be rotated.

​
How Infisical does it

Infisical stores secrets in a four-level hierarchy:
  • Projects contain the secrets used by a single application or service, along with the access rules that determine who can read them.
  • Environments separate secrets by where they’re used. The same secret key can hold different values in development, staging, and production.
  • Folders group related secrets within an environment and can be used as boundaries for access control.
  • Secrets are key-value pairs. Every change to a secret is versioned, secrets can reference the values of other secrets, and a secret can be restored to a previous value.
In addition to storing secrets, Infisical delivers them to applications and infrastructure through the CLI, SDKs, agents, Kubernetes, and CI/CD. Long-lived credentials can be rotated on a schedule, short-lived credentials can be generated on demand, and changes to secrets in sensitive folders can require approval before they’re applied.