infisical-self-host
Skill36 starsChanged 3 months agoMITView on GitHub
Deploy and operate Infisical self-hosted instances with Docker, Docker Compose, and Kubernetes. Covers architecture, environment variables, ENCRYPTION_KEY management, PostgreSQL setup, Redis configuration (including the required noeviction policy), production hardening, FIPS 140-3 compliance, scaling, and high availability patterns. For deploying the Infisical platform itself. Not for the Kubernetes Operator, which is a separate Helm chart (infisical-kubernetes-operator), nor for using Infisical once running (infisical-setup).
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- infisical-access-controlSkill
- infisical-agentSkill
- infisical-apiSkill
- infisical-app-connectionsSkill
- infisical-dynamic-secretsSkill
- infisical-gatewaySkill
- infisical-kmsSkill
- infisical-kubernetes-operatorSkill
- infisical-pamSkill
- infisical-pkiSkill
- infisical-secret-rotationSkill
- infisical-secret-scanningSkill
- infisical-secret-syncsSkill
- infisical-setupSkill
- infisical-ssoSkill
- infisical-terraformSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 48
Use Redis 6.x or 7.x; at least 6.2 is advised
- Distinctive: line 49
All three topologies are supported: standalone, Sentinel, and Cluster
- Very specific: line 62
Docker Compose: Use docker-compose.prod.yml from the repository with PostgreSQL and Redis services.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Infisical Self-Hosted Deployment
This skill guides you through deploying, configuring, and operating Infisical in self-hosted environments. Whether you are running Infisical on Docker, Docker Compose, or Kubernetes, this resource covers essential setup, security hardening, scaling, and maintenance patterns.
Not this skill
| If the user wants... | Use |
| To deploy the Kubernetes Operator (also a Helm chart, different thing) | infisical-kubernetes-operator |
| To reach a private resource from Infisical | infisical-gateway |
| To configure SSO or SCIM on their instance | infisical-sso |
| Roles, permissions, audit log streams | infisical-access-control |
| To use Infisical once it is running | infisical-setup |
| An external KMS or HSM backing the root key | infisical-kms |
The Helm confusion is worth pre-empting: the secrets-operator chart installs the operator;
this skill covers the chart that installs the platform. Both come from the same Cloudsmith repo.
Guiding Principles
- ENCRYPTION_KEY is Critical: This key encrypts all secrets at rest and cannot be recovered if lost. Back it up and rotate it carefully following Infisical's rotation procedures.
- Standard deployments: a random 16-byte hex string —
openssl rand -hex 16 - FIPS-enabled deployments: a 256-bit base64 key instead —
openssl rand -base64 32
- Standard deployments: a random 16-byte hex string —
- AUTH_SECRET is Required: This key is used for session and JWT signing. It is 32 bytes (base64), generated with
openssl rand -base64 32, and must be stable across restarts. - Database Requirements: PostgreSQL is the only supported database. Use 14+ for compatibility; Infisical is extensively tested on 16. Always backup your database before upgrading Infisical. Schema migrations run automatically on boot (since v0.111.0-postgres).
- Redis is a hard dependency, not just a cache: Beyond caching it holds the background job queue, distributed locks, cross-instance coordination state, and rate-limit counters. The instance will not start unless one of
REDIS_URL,REDIS_SENTINEL_HOSTS, orREDIS_CLUSTER_HOSTSis set, and a running instance is degraded while Redis is unreachable.- Use Redis 6.x or 7.x; at least 6.2 is advised
- All three topologies are supported: standalone, Sentinel, and Cluster
- Active-passive is recommended. Active-active has not been tested and may behave in undocumented ways
- Set the eviction policy to
noeviction. This is required, not a tuning suggestion — evicting keys under memory pressure would silently drop queued work - Enable persistence (AOF, or at minimum RDB snapshots) and back Redis up. Pending secret rotations, syncs, and webhook deliveries live there; a Redis that comes back empty loses them
- Give Redis the same availability target as the app instances — an unreplicated Redis is a single point of failure for the whole deployment
- Stateless Architecture: Infisical is stateless. Scale horizontally by adding more replicas. All state lives in PostgreSQL and Redis. Each instance needs no more than 2–4 CPU cores and 4–8 GB memory; add containers rather than growing one.
- FIPS Compliance: Infisical is compliant with FIPS 140-3. Deploy the separate
infisical/infisical-fipsDocker image (an Enterprise-only image, not a tag on the standard repo) and setFIPS_ENABLED=true. Remember theENCRYPTION_KEYformat changes to 256-bit base64 in FIPS mode.
Quick Start
- Docker Standalone: Pull
infisical/infisical:<version>, set environment variables, run on port 8080. - Docker Compose: Use
docker-compose.prod.ymlfrom the repository with PostgreSQL and Redis services. - Kubernetes: Deploy via Helm chart
infisical-standalone-postgresfrom Cloudsmith registry with optional managed databases.
Reference Guides
Environment Variables
Complete reference for all configuration environment variables, including:
- Required keys (ENCRYPTION_KEY, AUTH_SECRET, database, Redis)
- Database and replication setup
- Redis with Sentinel support
- SMTP configuration
- OAuth/SSO providers
- FIPS and telemetry settings
- Security options
Docker Deployment
Docker and Docker Compose deployment patterns, including:
- Standalone container setup
- Docker Compose production stack
- Image variants (standard and FIPS)
- Production hardening with security capabilities and read-only filesystems
- Health checks
Kubernetes Deployment
Kubernetes and Helm deployment guide, including:
- Helm chart installation and configuration
- Secret creation and management
- Optional PostgreSQL and Redis (Bitnami charts)
- Pod security and RBAC
- Networking policies and Ingress/TLS
Scaling and High Availability
Production scaling patterns and HA architecture, including:
- Horizontal scaling (adding replicas)
- Sizing guidelines for Infisical, PostgreSQL, and Redis
- Database read replicas
- Redis Sentinel for HA
- Backup and upgrade procedures
- License server firewall rules
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

