What you actually get with the Infisical package on the free tier: notes from a fresh installation

[LoudLemur]

Thank you to Team Cloudron for making Infisical available. It is good timing, since we are starting to have a lot of AI applications.

We just stood up the new Infisical package (0.3.1, ships Infisical v0.162.13) and dug
into a few questions before trusting it with real secrets. We are sharing the answers since they were not obvious from the package page.

1. Which features work without a licence key?

Infiscal is "Fauxpen Source" / "Open Core"

Infisical's core is MIT but a lot of features are licence-gated server-side, and the
docs aren't always current about which tier gates what. Rather than clicking through
the UI, I read the default feature table the backend ships
(/app/code/src/ee/services/license/license-fns.ts, getDefaultOnPremFeatures) via
the app's terminal. On v0.162.13 with no LICENSE_KEY:

Available: static secrets/folders/environments, machine identities (Universal Auth,
OIDC, …), secret versioning, secret sharing, PKI with ACME, the base SSH CA
functionality (host groups are gated), integrations/secret syncs (the
non-"enterprise" ones).

Gated (Pro/Enterprise): dynamic secrets (incl. the GitHub App and Tailscale
ones), secret rotation, audit logs, custom RBAC roles, approval workflows,
SAML/OIDC SSO, LDAP, groups, Infisical Gateway, point-in-time recovery, secret
scanning, EST/SCEP PKI.

If you were planning to self-host specifically for dynamic secrets or rotation: those
need a paid licence even self-hosted. Static secrets + versioning + machine identities
still cover a lot, though. If you have a licence, cloudron env set --app <app> LICENSE_KEY=... is all it should take.

2. Where does the crypto root live, and is it backed up?

The package generates infisical-auth-secret and infisical-encryption-key into
/app/data/ on first start. The encryption key encrypts everything in Postgres —
lose it and every secret in the instance is gone. It is covered by normal Cloudron
app backups (along with the Postgres dump), but on a fresh install there's a window
where the key exists in exactly one place. My advice: make sure one backup run has
completed before you put anything real in, and consider keeping an offline copy of
that key.

3. Resource footprint

Heads-up: the manifest sets a 1 GB memory limit and my instance sits at ~925 MB
essentially idle (it's a Node backend + workers). If you see OOM restarts, raise the
limit in App → Resources. Disk in /app/data is negligible; data lives in the
Postgres addon.

4. Can other Cloudron apps consume secrets from it?

Network-wise, yes app containers can reach the instance on its public FQDN
(hairpin through the host works fine, ~sub-second TLS round trip). The catch is
injection: stock packages can only take secrets via cloudron env set (which
restarts the app), so something has to push changes. For packages you build
yourself, the app can pull natively with infisical run / Infisical Agent at start,
which is much cleaner. There's no Cloudron-specific integration in Infisical itself.

5. Small print I hit

• No Forgejo/Gitea app connection exists upstream (GitHub/GitLab/Bitbucket only), so
  Forgejo tokens stay static secrets unless you script rotation against both APIs.
• The CLI can demand an interactive infisical login in some flows even when
  INFISICAL_TOKEN is set (Infisical/infisical#5134), worth knowing before you wire
  it into CI or agents.
• The package has ClickHouse-free internals (Postgres + Redis only), for anyone
  tracking backup interactions with ClickHouse apps.

Hopefully, this saves someone a morning. Everything above was done read-only via cloudron exec and the API.

[robi]

Does it have plugins, so an OSS LDAP option could be added?

[LoudLemur]

@robi Short answer: no, not in the sense you mean.

Infisical has no third-party extension mechanism. There is no equivalent of vault plugin register, no external plugin binaries, no stable interface for adding auth methods or secrets engines. The backend/src/server/plugins/ directory is just Fastify's internal module convention, and the Backstage / Airflow / varlock "Infisical plugins" you may run across are plugins for those systems that consume Infisical's API. Nothing extends the server itself.

LDAP is also about the worst candidate for a community implementation, because of where it lives: backend/src/ee/services/ldap-config/, alongside the SAML and OIDC SSO services. Everything under ee/ is proprietary-licensed rather than MIT, and the self-hosted terms say Infisical retains rights over modifications and patches to it. You could write a clean-room LDAP auth method in the MIT half instead, which sidesteps the licence question, but it would never be merged upstream since it competes directly with the paid feature. That means maintaining a permanent fork of a codebase shipping several releases a month, and on Cloudron, building and tracking your own image forever.

Worth separating two things though. What is gated is human SSO. Machine identity auth including OIDC is on the free tier, per the feature table in my first post, so machines can already federate against Keycloak or similar without a licence. It is only admin login to the Infisical UI that needs LDAP/SAML/OIDC.

If you want a genuine plugin system with no open core, OpenBao is the honest answer: MPL 2.0, Linux Foundation governance, external plugin binaries in a separate repo, with LDAP auth, the SSH CA and dynamic secrets all included free. Not something you bolt onto Infisical, an alternative to it.

We are currently packaging OpenBao for Cloudron and will hopefully make it available as a community application later.