Azure Key Vault or self-hosted Infisical: which fits your secrets program
If your main problem is a Key Vault bill that grows with every secret read, or your estate already runs on Azure and you want to keep secret values inside infrastructure you operate, self-hosted Infisical is a credible Azure Key Vault alternative for application secrets. Key Vault remains the simpler choice when your workloads are almost entirely Azure-native, your team has no capacity to run a stateful service, and you are content with per-operation billing. The decision turns on four factors: who operates the platform, where secrets must physically live, how developers consume secrets day to day, and whether you need Infisical's enterprise license features such as SSO or gateways.
Start with operations. Key Vault is a managed service, so Microsoft runs availability and patching, while a self-hosted Infisical deployment means your team owns the database, backups, upgrades and access to the stack. Infisical's self-hosting documentation lists options from a single Docker container and Docker Compose to an official Helm chart with bundled PostgreSQL and Redis, so the footprint is flexible, but the on-call burden is yours. Next, check residency: if regulators or internal policy require secret material to stay in your own data centers or an air-gapped network, a self-hosted platform fits where a regional Azure service may not.
Then look at developer workflow. Infisical organizes secrets by project and environment, syncs them to platforms such as GitHub, Vercel and AWS, and delivers them to Kubernetes workloads through its operator, which can reload deployments when values change. Key Vault is accessed through the Azure SDK and Entra ID identities, which suits code already built around managed identity. Finally, confirm whether you need SSO, gateways or other enterprise features. Infisical's self-hosting documentation states that these require an enterprise license, so price that line item against the Key Vault spend you are replacing and ask the vendor for the license scope in writing before you commit.
Which option fits which scenario
This table compares Azure Key Vault with self-hosted Infisical across the scenarios that usually decide the choice. Read each row for the better fit and the condition that makes it hold, since most organizations will find that more than one row applies to them.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Azure-only workloads on Entra ID | Azure Key Vault | Managed identities and Entra ID RBAC are built in, so applications need no extra auth setup. Holds if nothing outside Azure needs the same secrets and the team does not want to operate a service. |
| Multi-cloud or on-premises teams sharing one secrets service | Infisical | One deployment can authenticate machine identities from Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth. Holds if you can run and back up the service in a location all those workloads can reach. |
| Developer teams needing projects, environments and syncs to GitHub, Vercel or AWS | Infisical | Infisical provides a dashboard per project and environment and syncs secrets to platforms such as GitHub, Vercel and AWS. Key Vault has no comparable developer-facing sync model, so confirm any sync need against current Azure features. |
| Kubernetes delivery through an operator | Infisical | The Kubernetes operator delivers secrets to workloads and reloads deployments. Holds if your clusters can reach the Infisical instance; otherwise confirm an alternative delivery path with the Azure tooling you already use. |
| Dynamic database credentials and rotation | Infisical or OpenBao | Infisical supports rotation and dynamic secrets for databases such as PostgreSQL and MySQL. Confirm the exact database engines and rotation targets your systems need before deciding. |
| Organizations that must keep secrets and keys inside their own network | Infisical (self-hosted) | Self-hosting keeps the secrets store in your own cloud accounts, data centers or air-gapped networks. Holds only if you accept operating the database, backups and upgrades yourself, and if your key requirements are met by software-protected keys or an HSM you can supply. |
| Azure services that require customer-managed keys | Azure Key Vault | Some Azure services integrate directly with Key Vault for customer-managed keys. Keep those keys in Key Vault even if application secrets move, and confirm which services require it. |
| Teams without platform operators | Azure Key Vault | A managed service removes most of the operating load from a small team. Holds if the team cannot staff on-call and upgrades for a self-hosted service, and if per-operation billing stays acceptable at your volume. |
How Azure Key Vault and Infisical differ in scope
Azure Key Vault is a managed store for secrets, keys and certificates, and it is tied to Azure identity and billing. Access is controlled through Azure role-based access control and Entra ID, operations are billed per transaction, and the vault lives inside an Azure subscription and region. That focus is narrow by design: it holds the material and returns it to callers that have Azure permissions. Infisical is a broader self-hosted platform. It covers the same storage problem but also adds developer workflows such as a dashboard per project and environment, secret versioning with point-in-time recovery, secret syncs to other platforms, secret rotation, dynamic secrets, a private PKI, a key management service, and privileged access management with session recording. Before comparing prices, a team should decide which of those surfaces it actually needs to replace.
Infisical's README lists secret syncs to platforms such as GitHub, Vercel and AWS, and dynamic secrets for PostgreSQL and MySQL. Those are the features most likely to change how a platform team works day to day, because Key Vault does not generate short-lived database credentials and does not push values into third-party tools. For illustrative purposes, if a team currently copies a Key Vault value into a CI variable by hand, a sync or a machine identity with Universal Auth or OIDC may remove that step. Confirm each of these against the current Infisical documentation for your release, since the README is a summary and feature availability can differ between the self-hosted edition and the paid enterprise license.
Before you shortlist Infisical, list the features you need and mark which of them sit behind enterprise licensing. The self-hosting documentation states that enterprise features such as SSO or gateways require an enterprise license, so check whether single sign-on, audit requirements or network gateways are on your list. Also check the licensing of the parts you plan to run: the Infisical repository is MIT Expat licensed except for content in ee directories, which fall under a separate license. Ask the vendor for a written statement of which capabilities each license tier includes, and map that statement against your Key Vault inventory before you decide the scope of the replacement.
Capability comparison from supplied facts
This table compares Azure Key Vault with self-hosted Infisical across the capabilities that usually drive a secrets manager decision. Where the supplied facts do not confirm a Key Vault feature, the cell says to check Microsoft's documentation rather than assuming a gap, so treat those cells as a checklist for your own review. Use the rows to decide which features your workloads actually depend on.
| Capability | Azure Key Vault | Self-hosted Infisical |
|---|---|---|
| Secret storage and versioning | Stores secrets with versions. Confirm version limits and retention in Microsoft documentation. | Stores secrets per project and environment with secret versioning. |
| Point-in-time recovery | Confirm recovery options and soft-delete behavior in Microsoft documentation. | Secret versioning supports point-in-time recovery. |
| Projects and environments | Organized by vault, with access set per vault and object. Confirm how environments are modeled for your team. | Dashboard per project and environment, suited to developer-facing workflows. |
| Secret syncs to platforms | Not described in the supplied facts. Confirm which Azure and third-party sync targets exist. | Syncs secrets to platforms such as GitHub, Vercel and AWS. |
| Secret rotation | Confirm rotation support and notification options in Microsoft documentation. | Supports secret rotation as a built-in feature. |
| Dynamic secrets | Not listed in the supplied facts. Confirm whether Key Vault issues short-lived database credentials before relying on it. | Dynamic secrets for databases such as PostgreSQL and MySQL. |
| Kubernetes delivery | Typically reached through CSI or SDK integrations. Confirm the supported pattern for your cluster. | Kubernetes operator delivers secrets and reloads deployments. An agent injects secrets without code changes. |
| Machine identity authentication | Azure-native identities such as managed identity and Entra ID. Confirm other federation options. | Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth, governed by RBAC. |
| PKI with ACME and EST | Certificate features exist in Key Vault. Confirm ACME and EST support in Microsoft documentation. | Private PKI for X.509 certificates with ACME and EST enrollment. |
| KMS encrypt and decrypt | Key operations are available. Confirm which key types and HSM tiers you need. | Key management service with encrypt and decrypt operations. |
| Privileged access with session recording | Not part of Key Vault's scope. Use a separate privileged access tool if you need recording. | Privileged access management with session recording included. |
| Approval workflows | Access is controlled through Azure role assignments. Confirm approval options with Microsoft. | Access requests, temporary access and approval workflows built in. |
Where the data lives and who controls it
Azure Key Vault and self-hosted Infisical differ mainly in who operates the service, where the ciphertext sits and which features sit behind a license. The cards below set out each decision so you can map them to your residency rules, identity model and audit obligations before you choose a path.
Key Vault residency and Microsoft operation
Key Vault stores your vault objects in the Azure region you select and is operated by Microsoft as a managed service. Your control is limited to region, network rules, role assignments and key configuration. Check whether your residency rules require a specific Azure geography, whether Microsoft's operational access terms fit your risk model, and which Key Vault features you depend on, such as HSM-backed keys, which carry their own tiers and location constraints.
Self-hosted Infisical in your network
Self-hosting runs Infisical in your cloud account, data center or air-gapped network, so the database, the encryption key material and the operators with access stay under your control. You choose the host, the backup targets and the network paths that machines use to reach the service. The trade-off is that your team runs upgrades, database backups, high availability and incident response that Microsoft otherwise handles for Key Vault.
Infisical Cloud as a hosted option
Infisical Cloud is the vendor's hosted service, and teams can sign up for it free. It suits pilots and non-regulated workloads, but it moves secret storage into the vendor's hosting rather than your own network. Confirm where Infisical Cloud stores data, which regions are available, how the vendor handles support access and whether its terms meet your data residency and contractual requirements before you place production secrets there.
MIT core and separate enterprise license
The Infisical repository is licensed under the MIT Expat license, but any content in an ee directory falls under a separate license file. Legal teams should read both files together, because the enterprise directories determine which features you may run and modify. Confirm with the vendor how the ee license applies to your intended use, including internal modification and redistribution to managed service partners.
Enterprise features need licensing
Infisical's self-hosting documentation states that enterprise features such as SSO and gateways require an enterprise license. If your identity model depends on SSO for administrators or on gateways to reach private networks, budget for that license in the comparison with Key Vault's per-operation billing. Machine identities such as Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth remain part of the core platform for workloads.
Identity and compliance evidence
Moving secrets changes who can read them, how access is approved and where audit logs are kept. DeployOpen can plan the access model, configure logging and prepare the evidence a compliance assessment will request. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work, so ask your assessor early which controls they will test in the new setup.
What Infisical's enterprise license adds to the open-source core
The open-source core of Infisical is MIT Expat licensed, but that license does not cover everything in the repository. Content in any ee directory falls under a separate license located in ee/LICENSE, so a team that reads only the top-level license file can miss which code is restricted. Before you plan a deployment, review both files in the Infisical LICENSE file and map each feature you need to the license that governs it.
Infisical's self-hosting documentation states that enterprise features such as SSO and gateways require an enterprise license. For this comparison, those two items matter most. SSO affects how your engineers and administrators sign in, and gateways determine whether Infisical can reach private networks where databases and internal services run. Ask the vendor to confirm in writing which features sit behind enterprise terms, whether your identity provider and network topology depend on them, and whether any feature you plan to use for Key Vault replacement, such as secret syncs, rotation or PKI, carries a licensing condition.
Get the current enterprise terms and the included feature list in writing before you commit. Then compare that quote with what you pay Azure today. Key Vault bills per operation, key and renewal, so your cost picture is driven by request volume and key count. An enterprise Infisical license is a fixed or negotiated commercial term that sits on top of your own servers, databases and operations time. Do not assume the open-source core covers everything your organization needs, and confirm the license scope against the same requirement list you use for the cost model.
Cost components on each side and what drives them
Azure Key Vault bills by operation, key and certificate renewal, while self-hosted Infisical moves most of the spend into infrastructure, data services and staff time. Each card below marks whether a cost is one-time or recurring and names the factors that push it up or down.
Key Vault operations
Key Vault charges per operation, so every secret read, write and cryptographic call adds to the monthly bill. Applications that fetch secrets on each request, or CI jobs that pull dozens of values per run, multiply this line quickly. This cost is recurring and scales with call volume. Ask Microsoft's current pricing page for the operation rates in your region and model your actual call pattern before comparing.
Keys and certificate renewals
Key Vault bills for protected keys and for each certificate renewal request, so the count of keys and the frequency of renewal both matter. Short-lived certificates that renew often can become a noticeable recurring line. On the Infisical side, private PKI and KMS run inside the server you operate, so renewals cost compute and storage rather than a per-request fee. Count your keys and renewal cycles per year before the comparison.
Infisical software licensing
The Infisical repository is MIT Expat licensed outside the ee directory, so the core platform carries no license fee. Features such as SSO or gateways are behind enterprise licensing, which is priced by quote. This is recurring if you adopt those features. Confirm with the vendor exactly which features your design needs and whether they sit in the enterprise tier before you assume the core is sufficient.
Servers and Kubernetes capacity
Self-hosting adds compute for the Infisical API, the web interface and any Kubernetes operator or agent workloads, sized to peak secret traffic and high availability. These are recurring cloud or data center costs. They rise with redundancy requirements, multi-region designs and the number of environments. Ask your platform team to size replicas and node pools from expected request rates, not from a single test run.
PostgreSQL and Redis
The official Helm chart bundles PostgreSQL and Redis, which is the fastest path to a working install but leaves backup and patching of those stores with you. Using externally managed database services moves that work to a provider and adds a recurring service fee. Either way, the database holds encrypted secret material and needs its own backup, failover and restore testing. Decide this early because it changes both the cost and the recovery design.
Backups, upgrades and on-call
Backups, version upgrades and on-call response are recurring operating costs that are easy to underestimate. Key Vault handles the service layer, while your team owns Infisical's upgrades, restore drills and incident response. The effort rises with the number of environments, integrations and secret syncs. Ask any implementation partner for a written runbook and an estimate of hours per month for these tasks, tied to your scope.
Setup and migration
Setup is one-time work covering deployment, identity integration, project and environment design, secret sync configuration and migration of existing secrets and certificates. Its size depends on how many subscriptions, vaults and applications feed into Key Vault today. Most engagements are fixed-scope, so request a written scope listing each integration, the test plan and the cutover steps before comparing quotes.
What a move from Key Vault to Infisical involves
The sequence turns Key Vault secrets, identities and consumers into an Infisical deployment that your own team can operate, with each application cut over only after its secrets are verified. Effort scales with the number of consumers, so the inventory step decides most of the plan.
Inventory secrets and their consumers
List every vault in use, the secrets, keys and certificates in each, and the application, pipeline or Azure service that reads each item. Record how each consumer authenticates today, whether through managed identity, service principal or a connection string. Owners of each application confirm their consumer list, and the output is a spreadsheet or export that maps each secret to a consumer and an owner. Items with no known consumer are flagged for review before anything moves.
Deploy Infisical in the chosen model
Choose a self-hosting option from the documented choices, such as a single Docker container, Docker Compose, the official Helm chart with bundled PostgreSQL and Redis, Linux packages, or the AWS or GCP reference deployments. Your platform team deploys it inside your own cloud account or data center, configures TLS, backups and access to the database, and confirms which enterprise features you need, since the self-hosting documentation says SSO and gateways require enterprise licensing. Done when the instance is reachable only from approved networks and a test restore of its database succeeds.
Define projects and environments
Map your Key Vault structure onto Infisical projects and environments, typically one project per application or service with environments for development, staging and production. Decide where shared values live and who holds administrative roles. Security and platform leads approve the model in writing, and the result is a documented project tree with role assignments that matches the inventory.
Reconnect machine identities
Replace the Azure identities that workloads use with Infisical machine identities. Use Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth depending on where each workload runs, and grant each identity the minimum project access through RBAC. Platform engineers test each method in a non-production environment and confirm that a workload can read only the secrets it needs. The check is a documented access test per identity.
Migrate secret values through the API
Read each secret value from Key Vault through the API using an identity with read access, and write it into the matching Infisical environment. Key Vault backups only restore inside Azure, so the API path is the route for moving values out. Record the source version and the target version for each item, and compare values after import without writing them to logs or tickets. The output is a reconciliation report showing every secret moved.
Plan re-creation of keys and certificates
Keys cannot be copied out of Key Vault in the same way secret values can, so decide for each key whether to re-create it in Infisical's key management service, to issue a new certificate from Infisical's private PKI, or to keep the item in Azure for services that depend on it. Confirm with each owner what encrypted data depends on an existing key before any key is retired. The result is a signed decision list per key and certificate, with re-encryption or reissuance steps where needed.
Cut over application by application
Change one application at a time to read from Infisical, using the Kubernetes operator or agent where that suits the workload, and keep the Key Vault value available as a fallback until the change is verified in production. Watch error rates and deployment reloads after each switch. Each application is closed only when its owner confirms that it reads from Infisical and the Key Vault reads have stopped in logs.
Retire the vault after soft-delete retention
When no consumers remain, disable access to the Key Vault and schedule its deletion, taking soft-delete and purge protection settings into account so that recovery stays possible for the retention period configured on the vault. Confirm the retention period with your Azure administrator, export any audit records you must keep, and record the decommissioning in your change system. The step is complete when the vault is deleted or purged and the audit evidence is filed.
Questions buyers ask before switching from Azure Key Vault
How much does moving off Azure Key Vault cost, and what drives it?
The cost has three parts: the software, the infrastructure it runs on, and the work to migrate and operate it. Infisical's repository is licensed under the MIT Expat license except for content in ee directories, which carry a separate license, so the software line depends on whether you need enterprise features. Azure Key Vault bills per operation, key and renewal, so your current spend rises with secret reads, key use and certificate volume. Self-hosting moves that spend to hosting, a PostgreSQL database, Redis, backups, monitoring and upgrades, which recur every month. Migration work, including inventory, application changes, testing and cutover, is one-time. Ask for a quote that separates one-time and recurring lines and states your assumptions on secret count, environments, high availability and support hours. DeployOpen works from a written scope, so the quote follows from that document. DeployOpen does not publish a price list.
How long does a migration from Azure Key Vault take?
The timeline depends on scope more than on the tool itself. The main inputs are the number of vaults, secrets and applications or pipelines that read them, plus any keys that must be re-created instead of moved. The biggest drivers are the consumer inventory, since every Key Vault reference in App Service, pipelines or code needs a new read path; the identity design, which maps Azure identities to Infisical machine identities; the Kubernetes delivery setup; and the test and change windows your process requires. Rotation and dynamic secrets for databases add design work if you adopt them. Estate with few consumers and one environment moves faster than one spread across many subscriptions. No standard duration applies, so ask for a timeline in the written scope, with milestones tied to the outcome of the inventory.
What does a Key Vault to Infisical migration need from our team?
Plan for four roles. Platform engineers run hosting, the Helm chart or Docker deployment, database backups and upgrades. Application owners change how each service reads secrets and test the switch. Identity or security staff decide how workloads authenticate, whether through Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth, and set RBAC, temporary access and approval workflows. Compliance or audit owners confirm which access records and logs they need after the move. Someone must also own the decision on keys, because Key Vault keys cannot simply be exported. Ask whether your team has time for these roles during the migration window. Delays often come from application owners who were not scheduled early enough.
Can our own team migrate from Azure Key Vault to Infisical?
Yes, if your team already runs containers, Kubernetes or Linux services and can operate PostgreSQL and Redis. Infisical supports a single Docker container, Docker Compose, an official Helm chart with bundled PostgreSQL and Redis, Linux packages, and AWS or GCP reference deployments, so the installation is not the hard part. The harder work is operational: tested backups and restores, high availability design, TLS handling, monitoring, and upgrades as new releases ship, such as v0.166.8, published on October 15, 2026. Audit logging and access reviews also need to be rebuilt on the new platform. Confirm that your team can staff on-call before you cut over. If it cannot, DeployOpen can deliver a fixed-scope implementation or an ongoing support retainer, with scope, deliverables and timelines agreed in writing first.
Does Infisical replace Azure Key Vault for customer-managed keys?
Not automatically. Infisical's key management service performs encrypt and decrypt operations for your applications, but it does not by itself replace Key Vault keys that Azure services use as customer-managed keys. Azure services that use customer-managed keys typically reference Key Vault or Managed HSM, so check the supported key sources for each service you run in Microsoft's documentation. Keys in Key Vault generally cannot be copied out, so a key that must move will be re-created and its data re-encrypted under the new key. Many teams keep those keys in Key Vault while application secrets move to Infisical. Decide this split early so encryption scope, access policies and audit ownership remain clear through cutover.
Which Infisical enterprise license features do we need for SSO?
Self-hosted Infisical requires enterprise licensing for SSO. The self-hosting documentation states that enterprise features such as SSO or gateways need enterprise licensing, and the repository places content in ee directories under a separate license, while the rest falls under the MIT Expat license. Before you budget, list your identity requirements: the identity provider you use, the protocol it supports, whether group membership must map to Infisical roles, and whether user provisioning must be automatic. Then ask the vendor for the current feature list tied to each license tier and check it against that list. Start with the Infisical self-hosting overview to confirm which deployment method fits your environment.
When keeping Azure Key Vault is the better choice
Keeping Azure Key Vault is the sensible choice when your estate is almost entirely Azure and your secrets are consumed mainly by Azure-native services. Key Vault is integrated with Entra ID, managed identities, Azure RBAC and Azure Monitor, so an App Service, Function or AKS workload can read a secret without a bootstrap credential. The condition that makes this hold is that most consumers authenticate with managed identities and nothing outside Azure needs the same secret. If your Infisical rollout would mostly replicate that wiring, the operational gain is small. Confirm in writing which identity model your workloads already use and whether any non-Azure system needs direct access.
Key Vault also fits teams that want no secrets platform to run. Microsoft operates the service, the storage layer and its availability, so your team does not patch a database, rotate a unseal key or size a cluster for it. With Infisical self-hosted, you own the Docker or Helm deployment, PostgreSQL and Redis, backups, upgrades and the encryption key material. That work is worth taking on when you need control over data location or the product's features, and not worth it when a managed service meets the requirement. Ask Microsoft for the current service level terms and data residency commitments for the regions you use, and compare them with what your own on-call rota can actually guarantee.
Some Azure services only accept customer-managed keys held in Key Vault, for example storage accounts, disks and certain database encryption configurations. In that case the key itself has to stay in Key Vault or Managed HSM, and a self-hosted Infisical key management service cannot substitute for it on the Azure side. The condition is set by each Azure service's documentation, so list every resource that requires a customer-managed key and check the current requirements for each one before you plan a move. Where Infisical's KMS is used, it covers the workloads you choose to point at it, not Azure's built-in encryption dependencies.
How DeployOpen helps evaluate and implement Infisical
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Azure Key Vault to Infisical, we start with a written scope that maps your current vaults, identities and consumers to what Infisical must cover.
How we scope
- Inventory of Key Vault secrets, keys and certificates, and the Azure services and pipelines that read them
- Mapping of projects, environments and machine identities to Infisical equivalents, with access rules agreed in advance
- Decisions on which Azure-dependent workloads stay in Key Vault, documented in the written scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
How we build
- Self-hosted Infisical deployed in your environment using the option your team selects, such as Docker Compose or the official Helm chart
- Integration of Kubernetes, Azure, AWS or OIDC machine identity authentication, configured to your existing identity model
- Security testing of the deployment and integrations before any production secret moves
- Secret sync, rotation and dynamic secret configuration documented against the workloads each one serves
How we hand over
- Runbooks covering access requests, approval workflows, backups and upgrade steps for your operators
- Documentation of which Infisical features your license covers, so enterprise gaps are visible before cutover
- Evidence and configuration records prepared for your internal reviews and independent auditors
- Knowledge transfer sessions with the engineers who will run Infisical after handover
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Review of each new Infisical release before your team applies it, including changes to self-hosting requirements
- Periodic re-testing of access rules and machine identities as your Azure estate changes
- Support scope and response expectations agreed in writing, with no price list published
