When Infisical Cloud fits and when self-hosted Infisical fits
Choose Infisical Cloud when your team can accept the vendor hosting your secrets and you would rather not operate the platform yourself. It suits teams that want to sign up, start with a project and environment dashboard, and rely on the vendor for uptime and upgrades. Choose self-hosted Infisical when your secrets must stay inside your own network or cloud accounts, whether for data residency, internal policy or a regulator's expectations about where credentials are held. Self-hosting moves operational responsibility to you, so the decision is really about who runs the database, the upgrades and the access controls.
Be precise about licensing before you plan a self-hosted rollout. Infisical's repository is MIT licensed, but content in any ee directory falls under the separate license in ee/LICENSE, so the core and the enterprise-licensed parts carry different terms. Infisical's self-hosting documentation says features such as SSO or gateways require enterprise licensing, and its pricing page says supported, licensed self-hosting is arranged by talking to one of its experts. Ask for that arrangement in writing, and confirm which features your team needs are included before you commit. Read the Infisical LICENSE file alongside the vendor's terms.
Run a short fit test before you decide. List the systems that will read secrets, whether they can reach a hosted endpoint, and which of them need enterprise features such as SSO. Then ask who on your team will patch the container or Helm release, back up PostgreSQL and Redis, and respond to an outage at 2 a.m. If no one owns those tasks, the hosted service is usually the simpler starting point. If your security team requires that credentials never leave your environment, plan for self-hosting from the start and budget for the licensed support you will need.
Infisical Cloud vs self-hosted Infisical: the factors that differ
This table sets Infisical Cloud against self-hosting Infisical with Docker, Compose, Helm or Linux packages, factor by factor. Read each row as a question to answer for your own environment, and confirm any gap with Infisical before you commit to a model.
| Factor | Infisical Cloud | Self-hosted Infisical |
|---|---|---|
| Where secrets and metadata are stored | In Infisical's hosted service. Confirm the hosting region and data residency options with the vendor. | In your own infrastructure, in the PostgreSQL and Redis instances you run or deploy alongside Infisical. |
| Who runs upgrades and backups | Infisical operates the service, including upgrades. Confirm the backup and recovery commitments in writing. | Your team or a delegated partner applies releases such as v0.166.8 and backs up PostgreSQL and Redis. |
| Licensing that applies | Hosted service under Infisical's terms. Free sign-up is available per the README. | MIT Expat for the core repository. Content in any ee directory falls under ee/LICENSE, so check which features you use. |
| Enterprise features that need a license | Covered by the plan you subscribe to. Confirm which plan includes SSO, gateways and other paid features. | SSO and gateways require enterprise licensing per the self-hosting documentation. Supported, licensed self-hosting is arranged through Infisical's experts. |
| PostgreSQL dependency | Managed by Infisical. You do not provision or tune it. | Required. You provision, size, secure and back up PostgreSQL. |
| Redis dependency | Managed by Infisical. You do not provision or operate it. | The Helm chart bundles Redis, but you still own its availability, sizing and persistence choices. Confirm the Docker Compose setup with the vendor. |
| Kubernetes operator and agent | Workloads connect to the hosted API over the network. Confirm required egress paths and allowed endpoints. | The operator and agent run inside your cluster and reach your self-hosted endpoint, so network routing and certificates are your responsibility. |
| Private network placement | Secrets traverse Infisical's hosted service. Review whether that fits your data handling rules. | Secrets stay inside your network boundary, which is the main reason regulated teams self-host. |
| Machine identity authentication | Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth are available. Confirm which methods your plan includes. | The same methods are documented in the README. Confirm each one behaves identically against your instance version. |
What you pay for in each model and what drives the bill up
In Infisical Cloud, the bill is a vendor subscription. You pay Infisical for the hosted service and its plan tier, and your team carries only the work of configuring projects, environments, machine identities and integrations. The recurring cost is the subscription itself, which scales with the plan you choose and the features it gates. In self-hosting, the cost is split across several parties. You pay for a licensed agreement with Infisical if you need supported, enterprise-licensed modules, and Infisical's pricing page says that licensed self-hosting is available after speaking with its experts, but it does not publish a self-hosted price, so you should ask for a written quote. You also pay your cloud or data center provider for compute, storage, networking and backups, and you pay for the PostgreSQL and Redis services that the platform depends on, whether you run them yourself or buy them as managed services. The largest hidden cost is staff time for upgrades, patching, backup testing and on-call response.
Recurring and one-time costs differ in each model. In Cloud, almost everything recurs, and the main one-time cost is migrating existing secrets and rewiring pipelines. In self-hosting, one-time work includes designing the topology, standing up the database and cache, configuring TLS, integrating your identity provider, and running the first backup and restore test. Recurring costs include the licensed agreement, infrastructure, managed database fees, support and the ongoing engineering effort to keep Infisical and its dependencies current. Several factors push the self-hosted bill up: the number of environments you must run (production, disaster recovery, non-production), whether you need high availability for PostgreSQL and Redis, how many enterprise modules you license, and whether your security team requires the platform to stay inside an air-gapped or regulated network. Each of these can change the infrastructure and support footprint substantially.
When you request a quote, ask for four items in writing. First, the scope of licensed modules, named explicitly, so you can confirm which features are included and which are excluded. Second, the support terms, including response expectations, upgrade assistance and who handles security advisories. Third, the infrastructure assumed by the quote, such as the Helm chart with bundled PostgreSQL and Redis or your own managed services, the number of environments and the expected high availability design. Fourth, what happens at renewal and if you later move between Cloud and self-hosted. Use the Infisical self-hosting overview to confirm which deployment options your quote assumes, and compare the quote against your own estimate of the staff hours required, so the comparison reflects your environment rather than a generic figure.
Self-hosting Infisical with Docker, Compose, Helm or Linux packages
The single container is the smallest footprint in the vendor's self-hosting options. It runs the Infisical application on one host, and your team owns the host, the container image version, the network path and everything the application writes. Because the application needs a PostgreSQL database and a Redis instance, the database and cache are not part of the container and must be provisioned and connected separately. This option suits evaluation, a non-production pilot or a small internal deployment where one operator can manage a single node.
- Operator: your team runs and upgrades the host and the container image.
- State: secrets, identities and audit data live in the PostgreSQL database you connect, so the database is the item to back up.
- Dependencies: PostgreSQL and Redis are not bundled with a single container and must be supplied.
- High availability: a single container is one point of failure. Running more than one instance behind a load balancer needs a configuration the vendor documents, which you should confirm.
- Backups: you must schedule and test database backups and restore procedures yourself.
Before you rely on this option, confirm with Infisical which features your container build covers, since the self-hosting documentation says enterprise features such as SSO or gateways require enterprise licensing.
Docker Compose describes the application and its supporting services in one file, so a single host can start the Infisical application together with PostgreSQL and Redis. This is a practical choice when you want the dependencies defined as code and started in a known order, but you still run everything on one machine. The operational responsibility is the same as the single container, with the added work of maintaining the Compose file, the volumes and the versions of each service.
- Operator: your platform or infrastructure team owns the host, the Compose file and the upgrade sequence.
- State: named volumes or bind mounts hold database data, so storage location and permissions need to be set deliberately.
- Dependencies: PostgreSQL and Redis are defined in the stack you write or adapt, so each version becomes your responsibility.
- High availability: Compose on one host does not provide host-level failover. Multi-host resilience requires a different platform, which you should plan and confirm with the vendor.
- Backups: volume snapshots alone are not a substitute for consistent database dumps, so define backup jobs for PostgreSQL.
Ask the vendor which Compose configuration it supports for production and whether enterprise features are included in your license tier.
The official Helm chart is the option for teams that already run Kubernetes. The chart includes bundled PostgreSQL and Redis, which removes some setup work at install time but moves the question of database operations into your cluster. Bundled services are convenient for evaluation, yet a production deployment usually needs a decision on whether to keep the bundled database or point the chart at a managed or separately operated PostgreSQL instance. This choice affects backups, upgrades and recovery.
- Operator: your platform team owns the cluster, the chart values, the upgrade cadence and the secrets used during install.
- State: persistent volumes hold PostgreSQL and Redis data, so storage class and reclaim policy matter.
- Dependencies: PostgreSQL and Redis are bundled, and you decide whether to replace them with externally managed services.
- High availability: replica counts and the behavior of bundled PostgreSQL and Redis under node failure need to be verified in your cluster.
- Backups: the chart does not replace a backup plan. Confirm how to take consistent PostgreSQL backups and test restores.
Confirm with Infisical which chart version matches your target release and which enterprise features the chart enables by default.
Linux packages install Infisical directly onto a supported host, without a container runtime or orchestrator. This option fits organizations that standardize on host-based operations and want the service managed like other system software. Your team handles the operating system, the service configuration, the database connection and the upgrade path. The database and cache still need to be provisioned, so this option carries the most system administration of the four install methods.
- Operator: your systems team owns the operating system patching, service configuration and upgrades.
- State: the service configuration files and the connected PostgreSQL database hold the data that needs protecting.
- Dependencies: PostgreSQL and Redis are not bundled and must be installed or provided separately.
- High availability: a package install on one host is a single point of failure unless you design a multi-host arrangement and confirm it with the vendor.
- Backups: back up the configuration, the database and any encryption-related material the service depends on, then test restoration on a separate host.
Check the supported operating system versions and the package channel with Infisical before you commit to this path.
The AWS and GCP reference deployments are starting points that show how to run Infisical inside your own cloud account. They are useful when you want cloud-native networking, managed databases and identity controls, but they are reference architectures rather than a managed service. Your team still owns the account, the infrastructure code, the database service configuration and the decision of which components are managed by the cloud provider. This option keeps the secrets inside your own cloud boundary, which matters for teams with residency or network isolation requirements.
- Operator: your cloud and platform teams own the account, the network design, the IAM model and the upgrades.
- State: data sits in the managed database and storage services you provision in your account.
- Dependencies: the reference designs choose the cloud services. Confirm whether they use managed PostgreSQL and Redis or bundled equivalents.
- High availability: multi-zone or multi-region designs must be built and tested by your team against the reference.
- Backups: use the cloud provider's snapshot and retention controls, and confirm that secrets and keys are included in the restore scope.
Ask Infisical which reference design it currently recommends and which enterprise features need a license in addition to the infrastructure.
Where secrets live, who controls access and what compliance needs
Choosing between Infisical Cloud and self-hosted Infisical comes down to where secret values are stored, who holds the platform and its keys, and what evidence an assessor will ask for. The cards below cover those decisions in the order they usually surface in a security review.
Where secret values are stored
With Infisical Cloud, secret values, metadata and audit logs sit in the vendor's hosted environment, so the question is which region and which tenancy model apply to your data. With self-hosting, the PostgreSQL database and Redis instance live wherever you deploy them, whether a Docker host, a Compose stack, a Helm release or a Linux package. Confirm with the vendor where the cloud service hosts data, how it is encrypted at rest and in transit, and which certifications apply to the service today.
Administrator control of keys
A self-hosted deployment puts the platform administrators, the encryption key handling and the database backups inside your own change control. Ask who holds the root encryption key material, where it is stored, how it is rotated, and whether a key loss would make secrets unrecoverable. In a cloud deployment, those answers come from the vendor's documentation and contract, so ask for them in writing before you commit.
Network reachability and egress
Machine workloads such as Kubernetes pods, CI runners and servers must reach the Infisical endpoint to fetch secrets, and secret syncs push values out to platforms such as GitHub, Vercel and AWS. A cloud service adds egress from your workloads to a vendor endpoint, while a self-hosted instance keeps that path on your network. For air-gapped or segmented environments, confirm which sync targets and integrations can operate without outbound internet access.
Machine identity access and approvals
Infisical authenticates machine identities through Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth, and governs access with RBAC, temporary access, access requests and approval workflows. The deployment model does not change this logic, but the paid gates do. Its self-hosting documentation states that enterprise features such as SSO or gateways need enterprise licensing, so confirm which approval and identity features your chosen model includes before you design the access model.
Audit evidence and retention
Assessors will ask who read or changed a secret, when, and from which identity. Confirm what the audit log records, how long it is retained in each deployment model, and whether you can export it to your SIEM or evidence store. With self-hosting, your team owns log storage, backup and integrity controls, which is the evidence your auditor will examine. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the audit reports and certifications.
Questions to put to the vendor
Ask the vendor for the cloud service's hosting regions, encryption design, subprocessor list, incident notification terms, and current certifications with dates. Ask for the licensing terms that apply to self-hosted enterprise features and what support they include. Record the answers next to your control mapping, so the evidence trail for each control names a source and a date rather than an assumption.
What your team runs in each model
This table lists the recurring run tasks for Infisical and shows who carries each one in Infisical Cloud and in a self-hosted deployment. Use it to size the operating work before you decide, then confirm release cadence and support windows with the vendor, since those are not set out in the facts used here.
| Run task | Infisical Cloud | Self-hosted Infisical |
|---|---|---|
| Upgrades | Infisical operates the hosted service and rolls out its releases | Your team pulls each new release (for example, from the GitHub releases page) and applies it to Docker, Compose, Helm or Linux package installs |
| PostgreSQL operation and backups | Handled by Infisical as part of the hosted service | Your team runs PostgreSQL, including sizing, patching, backups and restore testing, unless you point Infisical at a database you already operate |
| Redis operation | Handled by Infisical as part of the hosted service | Your team runs Redis; the official Helm chart bundles it, so confirm whether that bundled instance suits your availability requirements |
| Certificate and key handling | Infisical manages the platform's own TLS and encryption keys | Your team manages TLS certificates for the Infisical endpoint, the encryption key material and any private PKI or KMS configuration you enable |
| Kubernetes operator and agent rollout | Your team configures the operator or agent against the hosted endpoint | Your team deploys and versions the operator and agent alongside the self-hosted instance and keeps them compatible with each upgrade |
| Monitoring and alerting | Infisical monitors the hosted service; your team watches secret sync and access events | Your team monitors the application, PostgreSQL, Redis and the host or cluster, and wires alerts to your own tooling |
| Incident response | Vendor handles platform incidents; your team handles integration and access incidents | Your team leads platform incidents end to end, with vendor support scope confirmed in writing before go-live |
| Capacity planning | Infisical scales the hosted service; your team manages its own machine identity and project growth | Your team sizes the application, database and cache for load and for backup and restore windows |
| Licensed features and support | Plan tiers are set by the vendor; confirm which features your plan includes | Enterprise features such as SSO or gateways require enterprise licensing; ask for the self-hosted license scope and support terms in writing |
How PostgreSQL, Redis and the Kubernetes operator add to your run book
The first decision is whether to keep the PostgreSQL and Redis services that the official Helm chart bundles or to point Infisical at databases and caches your team already operates. The bundled option is quicker to stand up, but it means your run book now covers a stateful database and a cache inside the Kubernetes cluster, including backups, restores, storage classes, version upgrades and who gets paged when they fail. Pointing Infisical at services you already run moves that work to existing owners, but it requires you to confirm the supported PostgreSQL and Redis versions, connection settings and high availability model with Infisical before go-live. Ask the vendor which components must be present for each Infisical release you plan to run, and test an upgrade against a copy of your database before you commit.
The Kubernetes operator and agent change the failure picture for your workloads. The operator delivers secrets to workloads and reloads deployments when values change, so a Infisical outage or a stalled sync can affect whether a rollout completes or whether running pods keep their last known values. Map which paths touch the database or cache: secret reads by the operator and agent, machine identity logins, audit writes, and sync jobs to external platforms. For each path, document what the workload does when Infisical is unreachable, whether cached secrets remain usable, and how a forced reload behaves during a database failover. Run these scenarios in a non-production cluster and record the results in your change and incident procedures.
Before go-live, confirm in writing with Infisical which self-hosting components are required, which are optional, and how the Helm chart's bundled PostgreSQL and Redis are supported for production. Then verify in your own environment: backup and point-in-time restore of the database, Redis eviction and persistence settings, network policies between Infisical, the operator and the cache, and alerting on operator reconciliation errors. Ask your team to rehearse a database failover and a cluster node loss with the operator running. If you cannot answer these questions from the vendor's documentation, treat the gap as a launch blocker rather than an operational detail to fix later.
Moving secrets between Infisical Cloud and self-hosted Infisical
This sequence moves secrets, machine identities and delivery configuration from one Infisical deployment to the other without a gap in secret delivery, and it ends with a verified target and a documented retirement of the old instance.
Inventory projects, environments and integrations
Your platform or security team lists every project, environment, folder, secret sync (for example to GitHub, Vercel or AWS), dynamic secret configuration, and machine identity in the current instance. Record which workloads read each project through the Kubernetes operator, the agent, or direct API calls, and note the RBAC roles, approval workflows and access requests attached to each. The step is complete when the inventory is a single document that someone outside the team could use to rebuild the setup, and each item has an owner.
Confirm license terms for the target model
Before you build anything, confirm with Infisical which features you need on the target and under which license they are available. Infisical's self-hosting documentation says enterprise features such as SSO or gateways require enterprise licensing, and its pricing page says supported, licensed self-hosting is arranged through one of its experts. Ask in writing what license applies to each feature in your inventory, what support is included, and how licensing changes if you later move back to Infisical Cloud. The step is complete when you hold a written answer for every feature on your list.
Stand up the target and its data dependencies
Deploy the self-hosted instance using the method your platform team has approved, such as Docker Compose, the official Helm chart or Linux packages. If you use the Helm chart with its bundled PostgreSQL and Redis, confirm whether those components are suitable for your production backup, high availability and patching standards, or whether you will supply external services. Confirm the target's TLS endpoint, network access from your workloads, and backup schedule for the database. The step is complete when the target starts cleanly, passes a health check, and a restore test of the database has succeeded.
Recreate identities, secrets and version history
Recreate projects, environments, folders and roles on the target, then move secret values through the export and import path that Infisical documents for your versions, or through an approved script run by your team. Ask Infisical exactly how secret versioning history, point-in-time recovery data, and audit records transfer, because they may not carry over in the same form. Recreate machine identities and their auth methods (Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth) on the target and generate new credentials rather than copying old ones. The step is complete when every project's secret count matches the inventory and you have recorded what history was and was not transferred.
Move operator, agent and sync configuration
Update the Kubernetes operator custom resources, agent configuration and secret sync targets so they point at the target instance and use its new machine identities. Keep the old configuration in version control so you can roll back. Check that deployments the operator reloads behave as expected in a non-production namespace first. The step is complete when each operator, agent and sync definition is reviewed, committed, and applied to a test environment with no unexpected changes in the workloads.
Repoint workloads in controlled batches
Switch workloads to the target in small groups, starting with the least critical services, and keep the old instance running in read-only or reachable state until every group has been verified. Record the change window and rollback step for each batch. Watch application errors and authentication failures during each cut. The step is complete when every workload reads secrets from the target and no workload still authenticates against the old instance.
Verify delivery, rotation and dynamic secrets
Test that each workload receives its secrets, that rotated values reach workloads, and that dynamic secrets for databases such as PostgreSQL and MySQL issue and revoke credentials as configured. Confirm that approval workflows and access requests still enforce the approvals you documented. Check that audit records for the test period appear on the target and that your SIEM or log pipeline receives them. The step is complete when your test checklist passes for every project and you have a signed-off record of the results.
Retire the old instance with a documented exit
After a period agreed with your security and compliance owners, revoke remaining credentials on the old instance, export any audit records you must keep, and then decommission the instance and its database backups according to your retention policy. Keep a record of what was retained, where, and for how long. If your Infisical Cloud or self-hosted contract has terms for ending service, follow them and confirm them in writing with Infisical. The step is complete when the old instance is shut down, its retained records are stored in an approved location, and the decommission is recorded in your change system.
Questions buyers ask before choosing Infisical Cloud or self-hosting
What does self-hosting Infisical cost compared with Infisical Cloud?
Self-hosting moves cost from a subscription to your own infrastructure and staff time, so the answer depends on what you already run. The Infisical self-hosting documentation says enterprise features such as SSO or gateways require enterprise licensing, and Infisical's pricing page says supported, licensed self-hosting is available after talking to one of its experts. Cost drivers include the number of identities and environments, the compute and storage for PostgreSQL and Redis, backups, upgrades and on-call coverage. Ask Infisical for the written licensing terms for your self-hosted scope, and ask DeployOpen for a fixed-scope quote that lists each deliverable separately.
How long does a self-hosted Infisical rollout take?
The timeline depends on your hosting target, how many systems need secrets, and how much integration work is in scope. A single Docker container is the lightest starting point, while a production setup adds PostgreSQL and Redis, TLS, backup and restore testing, identity provider integration, and secret syncs or the Kubernetes operator. The topic facts do not supply a duration, so ask Infisical for its reference deployment steps and ask DeployOpen to state the phases, dependencies and acceptance tests in a written scope before work starts.
Can our team run self-hosted Infisical without outside help?
Yes, many teams with container and database experience can run it, but the answer depends on the skills you already have. Operating Infisical means owning the PostgreSQL and Redis dependencies, certificate and key handling, upgrades between releases, and restore testing. The official Helm chart bundles PostgreSQL and Redis, which speeds up a first install but still needs a plan for backups and version upgrades. If your team lacks these skills, you can hand specific parts to DeployOpen under a fixed scope or a retainer for ongoing upgrades and support.
What skills and staff time does a self-hosted deployment need?
Plan for platform engineering skills in containers or Kubernetes, PostgreSQL administration, identity configuration, and secrets handling for every workload that will consume Infisical. Staff time recurs for patching, monitoring, certificate renewal, and reviewing access requests and approval workflows. Infisical's self-hosting overview lists several deployment options, so pick one your team already supports. Ask your staff to name an owner for the platform, a backup and restore runbook, and a clear on-call path before you commit.
When must secrets stay inside our own network?
Keep secrets inside your network when your policy, contracts, or regulator require control over where key material and secret values are stored and processed, or when you cannot accept a third-party hosted service in the data path. Self-hosting also suits air-gapped or restricted networks. Infisical Cloud is a hosted service that teams can sign up for free, so it fits teams whose policy allows a vendor-hosted secrets store. Confirm your data classification and residency rules with your compliance lead before deciding, and ask Infisical which components, including syncs and the operator, reach outside your network.
How hard is it to move from Infisical Cloud to self-hosting later, or back?
Moving is manageable when you keep secrets organized by project and environment and document each machine identity, but the work grows with the number of workloads, syncs and integrations. Plan for exporting or re-creating secrets, updating machine identity authentication for Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth, and re-testing every consumer. Ask Infisical what export and import options exist for your plan and version, and ask DeployOpen for a migration scope that covers cutover, rollback and verification.
Does Infisical's MIT license cover everything in a self-hosted install?
No. Infisical's repository is MIT licensed except content in any ee directory, which falls under the separate license in ee/LICENSE. Features that the self-hosting documentation says require enterprise licensing, such as SSO or gateways, sit in that licensed layer. Confirm exactly which features your deployment needs, then check them against the license file and the written terms from Infisical before you design around them.
How DeployOpen scopes, delivers and supports self-hosted Infisical
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Infisical, that means starting from where your secrets must live and which edition and licensing path your team needs, then building and handing over the deployment in writing. Most engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- Written scope names which Infisical components are in play, such as the Docker, Compose, Helm or Linux package route and the Kubernetes operator or agent.
- We record where secrets must stay, including network boundaries, regions and which workloads and machine identities will authenticate.
- Licensing questions are listed for confirmation with Infisical, including which enterprise features your design depends on before work starts.
How we build
- We size and configure the PostgreSQL and Redis dependencies for the chosen deployment path, with backup and restore arranged alongside them.
- Access design covers machine identity methods, RBAC, approval workflows and secret rotation settings matched to your own identity provider.
- Each deliverable is tested against the agreed scope, including secret delivery into Kubernetes workloads and the failure paths your team will rely on.
How we hand over
- Handover documentation covers the deployed topology, configuration keys, upgrade steps and the decisions recorded during scoping.
- Your operators receive a walkthrough of day-to-day tasks such as onboarding projects, rotating credentials and reviewing access requests.
- Evidence for internal reviews is organized as described in the written scope, without any audit opinion implied by the work.
How we support
- Ongoing support, version upgrades and continuous testing are available as a retainer, scoped separately from the original build.
- Upgrades are planned against the Infisical release cadence and tested in a non-production environment before rollout.
- Before choosing a support model, ask us to confirm response expectations and service terms in writing, since these are set per engagement.
