# infisical spans secrets, PKI and KMS, and its sample environment file ships a real-looking encryption key

> infisical is an open-source platform for secrets, certificates, and privileged access management, offered as a hosted cloud and as a self-hosted stack. The breadth is the appeal and also the cost: six compose files, two Dockerfiles, a TypeScript backend next to a Go one, and an .env.example whose published ENCRYPTION_KEY and AUTH_SECRET have to be replaced before anything you store is protected.

**Infisical/infisical** — Infisical is the open-source platform for secrets, certificates, and privileged access management.

- Repository: https://github.com/Infisical/infisical
- Website: https://infisical.com
- Stars: 29,488 · Forks: 2,292
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/infisical-infisical

## The sample encryption key is published in the repository and must not survive first boot

The environment template is explicit about the two values that matter most, and about the fact that the ones it prints are not real:

```
# Keys
# Required key for platform encryption/decryption ops
# THIS IS A SAMPLE ENCRYPTION KEY AND SHOULD NEVER BE USED FOR PRODUCTION
ENCRYPTION_KEY=f13dbc92aaaf86fa7cb0ed8ac3265f47
```

A second block above it warns the same way about AUTH_SECRET, the key used to sign JWT tokens. The rest of the file shows what a self-hosted install expects: a DB_CONNECTION_URI assembled from POSTGRES_USER, POSTGRES_PASSWORD and POSTGRES_DB pointing at a host named db, a REDIS_URL pointing at redis on port 6379, a SITE_URL, and an SMTP block left empty. The consequence of copying the file and moving on is the one the comment is guarding against, since a key that decrypts your entire secret store cannot be one that is published in a public repository.

## Six compose files, two Dockerfiles, and the build target names a compose file that is not there

Deployment is a choice among several shapes rather than one documented path. The root carries docker-compose.dev.yml, docker-compose.prod.yml, docker-compose.test.yml, docker-compose.bdd.yml, docker-compose.e2e-dbs.yml, and docker-compose.dev-read-replica.yml, plus Dockerfile.standalone-infisical and Dockerfile.fips.standalone-infisical, a helm-charts directory, cloudformation/, docker-swarm/, and render.yaml. Against that list, two Makefile targets look off:

```
build:
	docker-compose -f docker-compose.yml build
```

There is no plain docker-compose.yml among the top-level files, and the same hyphenated docker-compose invocation in the push target points at the same missing name, while up-dev and up-prod use the newer two-word docker compose against named files. So the targets that look like the release path are the two that do not line up with the tree, and picking a deployment shape is left to you.

## The e2e harness drops the public schema on whatever database it is pointed at

One comment in the Makefile explains why the test stack is separate, and it is worth reading before you run anything:

```
# The API suites run against the throwaway stack in docker-compose.test.yml, never the dev one.
# That is not a preference: the e2e harness runs `DROP SCHEMA public CASCADE` on whatever
```

In other words, the end-to-end harness issues DROP SCHEMA public CASCADE against whichever database it has been pointed at, which is why the test, bdd, and e2e-dbs compose files are kept apart from docker-compose.dev.yml. The dev-read-replica file exists for the same reason of isolation. The consequence for a self-hoster is concrete: a test target run against a dev database takes that database with it, and the only thing standing between you and that outcome is choosing the compose file the same way the maintainers do.

## A TypeScript primary language sits beside a backend-go directory

The repository is listed as TypeScript, and the root directories include both backend/ and backend-go/, alongside frontend/, sink/, nginx/, docs/, and an e2e/ suite driven by cypress.config.js. Two backends in one tree means the language tag is not a full answer to where a feature lives, and a contributor or an operator reading the source cannot assume the server side is all TypeScript. The observability files point the same way, with otel-collector-config.yaml and prometheus.dev.yml at the root alongside the compose stack, so a self-hosted install brings a metrics path to wire up as well as the application. Before you plan work against this codebase, find out which backend owns the area you intend to change.

## The root package.json is a shell with two dependencies and four version overrides

The manifest at the root declares the package name infisical, an author field left empty, and a prepare script that runs husky install. Its entire dependency list is two entries, @radix-ui/react-radio-group and secrets.js-grempe, plus three devDependencies including eslint at 8.57.1. What is more telling are the overrides, which force flatted, minimatch, js-yaml, and @babel/runtime to specific versions regardless of what a transitive package asks for. Two things follow. Auditing this manifest tells you almost nothing about what a self-hosted install actually runs, because the real dependency sets live under backend/ and frontend/. And the overrides are a deliberate control over transitive versions that you inherit rather than choose, which is a reasonable thing to have and worth reading before you add your own tooling to the tree.

## Telemetry is off by default and the collector carries its own basic auth pair

The observability block in the environment template defaults to silence:

```
OTEL_TELEMETRY_COLLECTION_ENABLED=false
OTEL_EXPORT_TYPE=prometheus
OTEL_EXPORT_OTLP_ENDPOINT=
OTEL_OTLP_PUSH_INTERVAL=
```

A few lines further down there is OTEL_COLLECTOR_BASIC_AUTH_USERNAME and OTEL_COLLECTOR_BASIC_AUTH_PASSWORD, so the collector endpoint is expected to be protected, and OTEL_DROP_HIGH_CARDINALITY_METERS is set to false. SENTRY_DSN is marked optional, and a separate block for POSTHOG_HOST and POSTHOG_PROJECT_API_KEY carries the comment that it should be ignored and is not applicable for the self-hosted version. The consequence is that a self-hosted install sends nothing until you change the flag, which is the right default, and it also means metrics are entirely your problem until you supply an endpoint and credentials.

## Tags are still 0.165.x and three patches landed on three consecutive days

The release trail is v0.165.14 dated 2026-09-21, v0.165.15 dated 2026-09-22, and v0.165.16 dated 2026-09-23, with the last push to main dated 2026-09-28. The repository is not archived, so the work is current, but three patch tags inside three days on the same 0.165 line is a different story from a mature 1.x with occasional updates. The pre-1.0 number carries no compatibility promise, and a patch line that moves daily means the tag you test against can be several builds behind by the time you deploy it. Pin an exact tag, and treat the gap between the newest tag and the last push as a reminder that the branch is where the current work actually is.

## One platform now spans secrets, a private CA, and a KMS, each with its own external contract

The feature surface is grouped into three pillars, and each one drags in a set of outside systems you now depend on. Secrets management covers versioning with point-in-time recovery, rotation for PostgreSQL, MySQL, and AWS IAM credentials, on-demand dynamic secrets for PostgreSQL, MySQL, and RabbitMQ, secret sync to GitHub, Vercel, and AWS Secrets Manager, a Kubernetes Operator that reloads deployments, an agent that injects values without touching code, honey tokens that alert when a decoy is used, and an Agent Vault that proxies AI agent requests so they never hold real credentials. Certificate management adds an internal CA, external CAs such as Let's Encrypt, DigiCert, and Microsoft AD CS, enrollment by API, ACME, or EST, revocation with CRL and inventory tracking, sync to AWS Certificate Manager and Azure Key Vault, and code signing. KMS covers central key management and encrypt and decrypt operations. Every one of those integrations is a contract to verify, and the platform does not reduce the number of them.

## Conclusion

infisical suits a team that wants secrets, a private CA, and a KMS in one self-hosted place, and that is prepared to run the operational surface that comes with them: Postgres, Redis, a metrics collector, and at least one deployment shape chosen from six. Do not adopt it purely for a secret store if you have no capacity to operate that, and do not treat the version number as stability, since the tags are still 0.165.x and move daily. Before the first start, generate ENCRYPTION_KEY and AUTH_SECRET yourself, read the LICENSE file at the repository root rather than the ISC line in package.json, pin an exact tag, and confirm which backend, TypeScript or Go, owns the feature you care about.

## FAQ

### What is infisical used for?

It is the open source security infrastructure platform teams use for secrets, certificates, and privileged access management. The stated aim is to centralize application secrets across every environment with versioning, rotation, and leak prevention, and to keep secret tooling accessible beyond security teams.

### how to install infisical

The README contains no install command and points to a self-hosting overview page instead. The repository itself carries Dockerfile.standalone-infisical, Dockerfile.fips.standalone-infisical, six docker-compose files, helm-charts, cloudformation, and render.yaml, so the install path is one of those shapes rather than one command.

### how to install infisical cli

No CLI install command appears in the README. The CLI version is pinned in build-versions.env, which the Makefile includes and exports as INFISICAL_CLI_VERSION so the Dockerfiles pick up the same value.

### is infisical open source

It presents itself as the open-source secret management platform, with a LICENSE file at the repository root. Note that the root package.json declares ISC as its license, so read the LICENSE file itself to see which terms cover which part of the tree.

### How much does Infisical cost?

No pricing appears in the README. The only cost distinction it draws is between Infisical Cloud and self-hosting, which links to a self-hosting overview, with community and documentation pages alongside them.

### is infisical safe

The README claims leak prevention through secret scanning and honey tokens that alert when a decoy credential is used, plus an Agent Vault that proxies AI agent requests. What is safe for your data still depends on your own key handling, starting with replacing the published ENCRYPTION_KEY and AUTH_SECRET samples.

## Sources

- [Infisical/infisical on GitHub](https://github.com/Infisical/infisical)
- [Issues](https://github.com/Infisical/infisical/issues)
- [Project website](https://infisical.com)
- [README](https://github.com/Infisical/infisical/blob/main/README.md)
- [Releases](https://github.com/Infisical/infisical/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/infisical-infisical