The Problem

Teams adopting infisical face a fragmented onboarding experience across seven independently versioned projects. The repository structure reveals a portfolio rather than a unified codebase, with significant divergence in language, framework, and maturity across frontend (4400 files, TypeScript-dominant), backend (3814 files), and backend-go (162 files, Go). This modular architecture, while allowing specialization, creates coordination overhead for teams seeking a cohesive deployment path, particularly when CI hygiene, secret handling, and dependency management practices vary substantially between projects.

What This Does

infisical operates as seven semi-independent projects under a single umbrella. The frontend (4400 files, 4149 code files) is a React-based UI for secret management, while the backend (3814 files, 3762 code files) provides the API surface in TypeScript/Node. The backend-go project (162 files, 141 code files) constitutes the core runtime in Go, with entry points at backend-go/cmd/infisical/main.go:27 (main) and backend-go/cmd/infisical/main.go:54 (run). The call graph shows 2451 resolved intra-repository edges, with NodeJS functions called from 105 places and Go functions from fewer call sites. The backend-go/internal/services/permission/project/subjects.go is the most heavily routed file, with 116 function(s) and 58 class(es)/type(s) defining SubjectType and GetField accessors. The backend-go/internal/server/api/secretmanager/secret/gen.go handles secret validation (45 functions) and is called from only 1 other file, indicating a narrow integration point. The backend-go/internal/database/pg/pg.go provides the Postgres connection layer (9 functions) invoked from 32 other files. Seven distinct projects exist: frontend, backend, backend-go, upgrade-impact, e2e, sink, and wasm—each with independent dependency files, Docker configurations, and test suites. No single architecture binds them; each project manages its own .env.example, Dockerfile, and CI workflow.

How It Is Wired

Execution begins at backend-go/cmd/infisical/main.go:27 (main), which reaches 100 function(s) and is called by nothing else in the repo. The run function at line 54 reaches 90 function(s) and is itself called from 1 place. Tracing from main: main -> run -> NewClientFromEnvConfig performs database reads via redis.ParseURL. From backend-go/internal/queue/queue.go:175, Start reaches 34 function(s) and is called from 5 places; it triggers findOrCreateRootConfig which performs database writes via tx.Rollback and cryptographic operations via s.hsm.RandomBytes. Init at backend-go/internal/services/serverconfig/serverconfig.go:147 reaches 7 function(s) and is called by nothing else; it invokes findOrCreateConfig with database writes via tx.Rollback. The internal call graph shows LoadConfig -> Optional x161 and LoadConfig -> OptionalBool x35 as the most frequently resolved edges, indicating pervasive optional configuration handling. Representative flows include validateUserTokenClaims -> WithErrf x18 and getPermission -> Add x13. The call graph reveals no single horizontal pipeline across all projects—each project’s entry points and call patterns are isolated. Edges to libraries and unresolvable method calls are excluded, so this reflects self-contained intra-repository calling only.

How To Use It

Setup: The repository requires Go 1.26+ and Node.js 22+ based on Dockerfile references (backend-go/Dockerfile.dev, Dockerfile.standalone-infisical). Dependency management uses npm (backend/package.json, backend/package-lock.json) and Go modules (backend-go/go.mod). No single build command spans all projects; each has its own Makefile, docker-compose configurations (.github/resources/docker-compose.be-test.yml), and package scripts.

Configuration: Environment variables are defined in .env.example, .env.dev.example, and per-environment examples. The backend-go project expects POSTHOG_API_KEY among other secrets; however, the HIGH-severity issue notes this value is baked into Dockerfile.fips.standalone-infisical as ARG POSTHOG_API_KEY with a baked value, making it readable via docker history. Required env vars are not uniformly documented across the seven projects.

Running it: To start the Go backend, invoke go run ./cmd/infisical from the backend-go directory. The frontend requires npm install && npm run dev from the frontend directory. No unified start script exists; each project must be booted independently. For containerized deployment, Dockerfile.standalone-infisical and Dockerfile.fips.standalone-infisical exist but carry the embedded secret issue noted above.

Real-World Use

A development team needs to rotate PostgreSQL credentials across environments. They add a new secret via the infisical dashboard (frontend), which triggers the backend API to persist the entry. The Go runtime fetches the secret at runtime via the Postgres connection pool defined in backend-go/internal/database/pg/pg.go. The team configures a sync to their CI pipeline using the infisical secret sync CLI, which reads from the local infisical runtime. When a new developer joins, they clone the repo, run go run ./cmd/infisical to start the local server, and add INFISICAL_CLIENT_ID/INFISICAL_CLIENT_SECRET to their .env.local. Secret versioning and point-in-time recovery allow rolling back a mistaken rotation. Dynamic secrets generation for PostgreSQL is configured through the platform’s secret rotation templates, which the Go service consumes via the external KMS integration (backend-go/internal/ee/services/externalkms/externalkms.go).

Code Health & Issues

The static analysis identified 9 findings across the portfolio:

  • [HIGH] Make CI invoke the test suite it has - .github/workflows: 196 test files exist, but no test command appears in the 3 workflows read. A green check that never executes assertions is worse than no check, as reviewers come to trust it.
  • [HIGH] Stop passing the secret as a build argument or image env - Dockerfile.fips.standalone-infisical: ARG POSTHOG_API_KEY with a baked value is recorded in image layers and readable with docker history by anyone who can pull the image; deleting the file in a later layer does not remove it.
  • [MEDIUM] Declare least-privilege permissions for GITHUB_TOKEN - .github/workflows/generate-release-changelog.yml: 2 workflow(s) declare no permissions, and 2 reference secrets. Without declaration the token inherits the repository default, allowing any injected step to push commits or mint releases.
  • [MEDIUM] Enable Dependabot or Renovate: 10 manifest(s) exist with no update bot configured. Without a bot a published advisory sits unpatched until hand-audited, which across 1,322 repositories means never.
  • [MEDIUM] Pin the container base image by digest - Dockerfile.fips.standalone-infisical: node:22.22.0-trixie-slim, golang:1.26-trixie, debian:trixie-slim are untagged/mutable bases, meaning today's build and last month's contain different libc and a different CVE set with no record of which shipped.
  • [MEDIUM] Gate pull requests on a dependency vulnerability scan - .github/workflows: no dependency scan in CI. This is the one gate that would catch a known-vulnerable package before it reaches a build.
  • [MEDIUM] Set persist-credentials: false on checkout - .github/workflows/generate-release-changelog.yml: checkout keeps the token, then dependencies are installed. The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.
  • [LOW] Set timeout-minutes on the workflow jobs - .github/workflows/generate-release-changelog.yml: 2 workflow(s) declare no job timeout; a wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.
  • [LOW] Add the repository convention files this project lacks: missing .editorconfig, .gitattributes, a formatter config. Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Additional SDLC observations supported by structure: committed secrets YES (flagged in hygiene), CI present (GitHub Actions, 39 workflow files), Dockerfile yes, licence yes, lockfile yes, but 5187 doc files and 276 test files indicate substantial documentation and test coverage exist, though CI does not invoke the test suite.

The Bottom Line

infisical is a capable, well-structured secret management platform with strong feature coverage across secrets sync, versioning, rotation, and dynamic secret generation—but it is not a single product. It is a portfolio of seven projects with varying maturity, language, and operational practices. Teams should expect to assemble their own deployment pipeline, manage seven separate CI configurations, and guard against the documented secret-in-image-layer risk. It is suitable for organizations needing flexible, multi-platform secret management and willing to invest in orchestration; it is less suitable for teams seeking an out-of-the-box, turnkey solution with uniform ops experience.