Running an Akeyless alternative for air-gapped and on-premises networks
OpenBao or Infisical can be deployed fully inside your network boundary, with no dependency on an external control plane. The decision is not whether the platform can run offline but which one fits your feature needs and how much operating capacity your team has. Akeyless gateways on site keep traffic local, but the control plane that issues policy and holds configuration still sits in Akeyless's cloud. An air-gapped design needs the server, its storage, its authentication backends and its PKI all running inside the boundary, so the gateway model alone does not satisfy the requirement.
Plan three things before any installation. First, licensing: OpenBao is MPL 2.0 and Infisical's repository is MIT Expat outside any ee directory, but enterprise features such as SSO or gateways require enterprise licensing under Infisical's self-hosting documentation, so confirm which features you need and which license covers them in writing. Second, packages: container images, Helm charts, Linux packages and plugin binaries must be mirrored into your registry, and you should verify each artifact's checksums and signatures before it crosses the boundary. Third, updates: OpenBao releases such as v2.7.1 must be pulled, verified and staged offline on a schedule your change process can support.
Unseal and high availability need explicit design. OpenBao's Shamir unseal keys must be split among custodians who can be reached inside the boundary, and an auto-unseal option backed by an HSM or an internal KMS should be evaluated against your key custody rules. For HA, the officially supported backends are integrated Raft storage and PostgreSQL, and the choice affects how you run node replacement. Ask your vendor or integrator to document the restore path for both the storage backend and the unseal material, and test that path in a lab before go-live.
What an air-gapped boundary requires from a secrets manager
A secrets manager inside an isolated network has to work without help from outside it, and the way its packages arrive is itself a control. The cards below set out the requirements that follow from NERC CIP-013-2 and CIP-005-7, and what to check against OpenBao or Infisical before you commit to either.
No runtime external dependency
A secrets manager on an isolated network must serve reads, leases and policy decisions with no call to a vendor control plane. Akeyless places its control plane in the cloud and relies on gateways on site, so the gateway model does not carry over directly. Confirm that every authentication method, lease renewal and revocation path you need completes against servers you run, and test it by cutting the network link during a pilot.
Verified offline installation and updates
Every package crossing the boundary needs an integrity and authenticity check. NERC CIP-013-2 expects procurement processes to address verification of software integrity and authenticity for vendor software and patches. Record the checksums or signatures you validate for each OpenBao or Infisical image, chart and binary, and keep the release notes with the transfer record. The OpenBao releases page is the place to compare what you are importing against what was published.
Key custody and unseal inside the boundary
Unseal material and the root of the encryption hierarchy must be held inside the boundary, with a documented procedure for who can unseal and how key shares are split and stored. OpenBao uses Shamir unseal for Vault-compatible deployments, so plan share custody, a restart runbook and the operators who hold shares. Ask whether an HSM or a cloud KMS can be used for auto-unseal, and whether that dependency would itself sit outside the perimeter.
High availability without external services
Standby nodes must keep serving when one node fails, and the cluster must not depend on a database or lock service outside the boundary. OpenBao HA uses an active node holding a lock in the data store, and integrated storage (Raft) and PostgreSQL are its officially supported HA backends. Decide which backend you will run inside the network, size the node count for your failure tolerance, and rehearse a failover before go-live.
Remote access to the secrets platform
Administrative and vendor sessions into the secrets manager are remote access paths that CIP-005-7 expects to be controlled. Route interactive access through an intermediate system with encryption and multi-factor authentication, and make sure you can detect and disable an active vendor session. Confirm which login methods OpenBao or Infisical support for operators, including login MFA and OIDC against your own identity provider.
Audit logs kept locally
Audit records of every secret read, write and policy change should be written to storage you control and forwarded to your own log platform without leaving the boundary. Confirm the audit device options for your chosen product, how log integrity is protected, and how long records are retained. Akeyless audit trails are tied to its platform, so verify that the self-hosted option gives you the complete record your assessor will ask for.
Which open-source option fits a fully inside-the-boundary design
This table compares OpenBao and Infisical on the requirements that decide whether a secrets platform can run fully inside an isolated boundary. Read each row as a question to confirm with the vendor, because offline operation is not documented for every feature. Akeyless gateways still depend on its SaaS control plane, so neither option is a like-for-like swap for that design.
| Requirement | OpenBao | Infisical |
|---|---|---|
| License | MPL 2.0 covers the OpenBao repository. | MIT except content in ee directories, which uses a separate license. |
| Enterprise features offline | Confirm with the OpenBao project which features, if any, need a paid edition. | SSO and gateways need enterprise licensing. Confirm how the license is validated offline. |
| Install without internet access | Install from mirrored binaries and images. The Helm chart requires Helm 3.6 or later. | Docker, Compose, Helm and Linux packages exist. Confirm offline image and chart mirroring. |
| Storage and HA backends | Integrated Raft and PostgreSQL are the supported HA backends. Docs favor PostgreSQL for easier safe operation. | Helm chart bundles PostgreSQL and Redis. Confirm external database options for HA. |
| Unseal model | Shamir unseal is the path in the migration guide. Confirm auto-unseal options for your HSM. | Confirm how the encryption root key is supplied at install and after restart. |
| PKI coverage | Confirm PKI engine support and enrollment protocols in your release before relying on it. | Private PKI for X.509 certificates with ACME and EST enrollment. |
| KMS and encryption as a service | Encryption as a service is documented. Confirm key import and HSM integration. | Key management service for encrypt and decrypt operations. Confirm HSM integration. |
| Removes Akeyless gateway dependency on SaaS | Self-hosted core with no required external control plane. Confirm no outbound calls in your build. | Self-hosted deployment with no required external control plane. Confirm no outbound calls in your build. |
How to deploy OpenBao inside an isolated network
This sequence takes an OpenBao cluster from an empty isolated environment to a running, unsealed, authenticated service whose images and releases were checked before they crossed the boundary. Each step names the output that confirms it is complete.
Choose the Kubernetes or VM target
The platform team picks where OpenBao will run inside the boundary: an existing Kubernetes cluster or plain virtual machines. For Kubernetes, confirm the cluster can be built or already runs without internet access, which the kubeadm documentation supports by pre-pulling control plane images and pointing kubeadm init at a private registry. Record the chosen target, node count, and the network zones that will reach the service. Done when the architecture note lists the target, the nodes, and which clients sit in which zone.
Mirror images and the Helm chart into a private registry
Copy the OpenBao container image, its Helm chart and any sidecar images into the internal registry through a controlled transfer process. Install Helm 3.6 or later on the admin host, since the OpenBao Helm chart requires that version or newer. Pin the image tags and chart version in the change record rather than pulling latest. Done when a test pull from an isolated node succeeds from the internal registry only and the pinned digests match the values recorded at import.
Select Raft or PostgreSQL storage and HA layout
Decide between integrated storage (Raft) and PostgreSQL. OpenBao documents both as the officially supported HA backends, and its docs describe PostgreSQL as easier to operate safely than Raft. Raft keeps storage inside the OpenBao nodes, which removes a database dependency but makes the team responsible for snapshots and peer management. PostgreSQL adds a database to patch and back up, and since OpenBao 2.5.0 Raft standbys can serve read-only requests, extended to PostgreSQL in v2.7.0. Done when the storage decision, node count and backup owner are written down and the cluster shows one active node and standbys.
Plan unseal and key custody inside the boundary
Decide between Shamir key shares and auto-unseal. Whichever you choose, the unseal material must stay inside the boundary: name who holds each Shamir share or which key service backs auto-unseal, and where recovery material is stored offline. Confirm with your vendor or OpenBao's current documentation which unseal mechanisms are available in your version, because this page does not assume one. Done when a written custody table names each key holder or key service, the location, and the recovery procedure, and an operator has completed a test unseal after a simulated restart.
Configure auth methods for servers and workloads
Enable AppRole for servers and Kubernetes auth for pods, which matches OpenBao's guidance to use Userpass for developer machines and AppRole for servers. Create one role per application with the narrowest policy, and bind Kubernetes roles to specific service accounts and namespaces. Disable any method no workload uses. Done when a test workload in the isolated network obtains a token with only its intended policy, and an attempt to read a path outside that policy is denied.
Define an offline update path with verification
Set up a repeatable process for bringing new OpenBao releases across the boundary. Watch the OpenBao releases page for the current example, v2.7.1, released on October 1, 2026 with security fixes, and verify each artifact against the checksums and signatures published with that release before import. Stage the upgrade in a non-production cluster first, then upgrade nodes one at a time. Where a release changes the image or chart, mirror it through the same import path as step two. Done when the first update has been rehearsed, the verification record is filed with the change, and the rollback steps are tested.
Confirm health, backups and the cutover checklist
Verify the running cluster against a checklist: leader election works, a standby takes over after the active node is stopped in a test, snapshots or database backups restore into a scratch environment, and audit logging ships to a destination inside the boundary. Confirm with your security team which evidence each compliance program requires, since DeployOpen prepares controls and evidence but does not issue assessments. Done when the test failover, restore test and audit log check are all recorded and signed off before any production secret is loaded.
Unseal, updates and HA design without an external control plane
Unseal decides whether an air-gapped OpenBao cluster can serve secrets at all, so settle who holds it before the first node starts. OpenBao starts sealed. Under Shamir unseal, the method the OpenBao migration guide assumes for existing Vault Community 1.14.1 clusters, the root key is split into shares and a threshold of them must be presented to bring a node up. Assign shares to named custodians in separate locations, store each one offline (sealed envelopes or hardware tokens in a safe are common choices), and record the custodian list and threshold in your key ceremony file. Do not keep shares on the cluster or in the same backup set. Confirm with the OpenBao documentation whether an HSM-based auto-unseal option fits a network with no external services, and what it adds to your key custody model.
In HA, one node holds the active role through a lock in the data store, and standby nodes forward or redirect requests to it. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends. Raft keeps all state inside the cluster, which suits a boundary without a database team. The OpenBao storage docs describe PostgreSQL as easier to operate safely, which matters if your network already runs a hardened PostgreSQL service. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL, so read load can spread across standbys. Writes still go through the active node, so size the cluster for write volume and failover first. Test failover by stopping the active node and confirming that a standby takes over and clients reconnect. Use the OpenBao high availability docs as the reference for this design.
Update rollouts in a closed network start with moving release artifacts through your approved transfer path, verifying their integrity and recording the hashes. This is the kind of control NERC CIP-013-2 expects procurement processes to address for software carried across an isolated boundary. Then upgrade node by node: upgrade a standby, confirm it rejoins and unseals, fail over, and upgrade the former active node. Keep the previous minor line available for rollback. The OpenBao migration guide documents a node-by-node in-place route only from Vault Community 1.14.1 on Raft with Shamir unseal, and it was tested only against that version. Treat any other starting point as a project that needs its own rehearsal. Backup and restore testing is your responsibility: take snapshots on a schedule, restore them into an isolated cluster, and confirm unseal using the shares your custodians actually hold.
When Infisical fits an isolated network instead
Infisical's self-hosting documentation lists several ways to run the platform. A single Docker container suits a small pilot or a lab. Docker Compose adds the supporting services in one file. The official Helm chart is the option most platform teams will evaluate for Kubernetes, because it bundles PostgreSQL and Redis so the cluster does not depend on external services. Linux packages and the AWS or GCP reference deployments are other routes, but cloud reference architectures do not apply inside an air-gapped boundary, so teams should map each option to hardware they actually control.
- Single container: fastest to start, usually a single point of failure with no separate database high availability.
- Docker Compose: a good fit for a contained host, with PostgreSQL and Redis defined alongside the application.
- Helm chart with bundled PostgreSQL and Redis: the bundled services are convenient, but you must confirm their storage, backup and upgrade behavior inside your cluster.
- Linux packages: useful where no container runtime is approved, so confirm what the package set pulls in.
- Cloud reference deployments: rely on cloud services that an isolated network may not have, so treat them as design references only.
Ask the vendor to confirm which components the chosen method needs at runtime and which are only needed during installation.
Infisical is broader than a secrets store. Its documentation covers a private PKI that issues X.509 certificates with ACME and EST enrollment, a key management service for encrypt and decrypt operations, and privileged access management with session recording. For an isolated network, these features can replace several separate tools, but each one changes what must be hardened, backed up and audited inside the boundary. Certificate authority keys, KMS key material and session recordings are all sensitive data that need the same custody discipline as static secrets.
- Private PKI: ACME and EST enrollment let internal devices and services request certificates without public internet access, so confirm which clients in your network support each protocol.
- Key management: encrypt and decrypt operations are useful for application-level encryption, but you should verify where key material is stored and how it is protected.
- Privileged access: session recording helps with accountability, and its retention and storage must sit inside the boundary.
- Machine identities: Kubernetes, cloud, OIDC and Universal Auth methods must be checked against what your isolated network can actually reach.
- Scope creep: adopting every feature at once enlarges the audit surface, so start with the modules your use case requires.
Ask for a written mapping from each feature you need to the specific product control and evidence it produces.
The core Infisical repository is licensed under the MIT Expat license, but content in any ee directory falls under a separate license. The self-hosting documentation states that enterprise features such as SSO or gateways require enterprise licensing. Regulated teams often need SSO for administrator access and gateways to reach isolated targets, so the licensing question is central to the design rather than a footnote. Confirm the exact feature set that the community build provides before assuming any control works in your environment.
- MIT Expat core: the main codebase can be reviewed and retained under its license terms.
- Enterprise directories: code under ee follows its own license, so legal review should cover it separately.
- SSO: if your identity provider governs administrator access, confirm whether SSO requires an enterprise license.
- Gateways: if targets sit in segments that the main instance cannot reach directly, confirm whether gateways are enterprise-only.
- Support terms: licensing may also determine which vendor support and upgrade channels are available.
Request a written statement of which features are included in each license tier, and have counsel review the ee license terms before the design is approved.
Running Infisical in an isolated network means every container image, Helm chart, package and database dependency must be brought across the boundary before installation and again for each upgrade. The NERC CIP-013-2 standard requires supply chain procurement processes to address verification of software integrity and authenticity of vendor software and patches, which is the control behind checking every artifact carried across an isolated boundary. Most of the work is in building a repeatable mirror process and recording what was imported and when, not in the first installation.
- Image mirroring: copy container images and their digests into an internal registry, then deploy only from that registry.
- Chart and dependency review: inspect the Helm chart and the bundled PostgreSQL and Redis versions before transfer.
- Integrity checks: verify signatures or checksums where the publisher provides them, and record the results.
- Upgrade cadence: plan how new releases will be evaluated, tested and carried across, since an isolated network cannot pull updates on its own.
- Transfer records: keep a log of each import for audit evidence.
Ask the vendor which release artifacts are published in a form suitable for mirroring, and confirm that your process covers every transitive dependency.
Questions teams ask before running secrets infrastructure offline
What does running OpenBao or Infisical offline actually cost?
The software itself carries no license fee for OpenBao, which is MPL 2.0 licensed, and the supplied sources describe no license fee for it. The recurring cost is people, hardware or virtual machines, storage, backups, and an optional HSM if you want keys held in hardware. The one-time cost is the implementation: architecture, unseal design, HA setup, client migration and testing. Ask any implementation partner for a written quote that separates these components, and ask which items recur every year. For Infisical, confirm which features you need, because enterprise features such as SSO or gateways require enterprise licensing according to its self-hosting documentation.
How long does an air-gapped secrets deployment take?
No duration is supplied for this work, so treat any number you see elsewhere with caution. The timeline depends on how many clients need migrating, whether you need HA across sites, whether an HSM is involved, how many secret engines and auth methods must be rebuilt, and how quickly your change process approves each step. Ask for a timeline in the written scope, with milestones for an isolated test cluster, unseal and backup validation, client cutover and a rehearsed recovery. Most engagements are fixed-scope, so the scope document should name these deliverables before work starts.
What must our internal team provide before the work starts?
Your team needs to provide the target infrastructure inside the boundary, including Kubernetes or virtual machines, load balancing, DNS, certificate authority trust, storage and a backup target. You also need named owners for unseal material, the identity source for human and machine logins, and a list of every application that reads secrets today. Security and compliance staff should confirm the control evidence they will need. Ask the provider which of these inputs they expect and when each must be ready, since missing inputs are a common cause of delay.
Can our own staff run OpenBao or Infisical without outside help?
Yes, if you have engineers who already operate Kubernetes or Linux services, understand TLS and identity systems, and can rehearse recovery. Both projects publish installation options, and OpenBao's Helm chart is the recommended Kubernetes installation path, requiring Helm 3.6 or later. The harder skills are unseal key custody, Raft or PostgreSQL HA operations, backup restores and upgrades. Ask whether your team has done a restore test and an in-place upgrade in a non-production environment. If not, a retainer for upgrades and support may reduce the risk of running alone.
How do we verify OpenBao or Infisical updates on an isolated network?
Verify every package before it crosses the boundary. Download the release from the project's official channel, check the published checksums and signatures where the project provides them, and record the hash in your change ticket. NERC CIP-013-2 is an example of a control that expects vendor software integrity and authenticity to be verified as part of supply chain procurement, and similar expectations appear in many frameworks. Keep a staging environment inside the boundary to test each release before production. For OpenBao, review the release notes for the version you move to, since the migration guide notes changes such as a shorter token format. Confirm the exact verification steps with the project and your change board.
What does high availability look like without an external control plane?
OpenBao uses an active node that holds a lock in the data store, with standby nodes that forward or redirect requests. Integrated storage (Raft) and PostgreSQL are its officially supported HA backends. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL. The docs describe PostgreSQL as easier to operate safely than Raft, which is worth weighing against your team's database skills. Plan node count, failure domains inside your data center, unseal behavior after a restart, and backup frequency. Confirm these choices against the current HA documentation before you commit to a design.
How should we sequence an Akeyless exit for an isolated network?
Start by building the target inside the boundary and proving unseal, backup, restore and HA failover with test data. Next, inventory every static secret, rotated secret, dynamic target, certificate and gateway dependency, then decide which become OpenBao or Infisical engines and which are retired. Export static values through the vendor's CLI or API before the SaaS account is closed, and re-create rotated and dynamic targets on the new side. Move clients in groups, switch each to its new auth method, and keep Akeyless read-only until the last cutover is verified. Remove gateways only after nothing depends on them. Ask your provider to document each gate and the rollback path in the written scope.
Evidence to keep for an isolated secrets deployment
An isolated secrets manager is only as credible as the records behind it. The cards below list the evidence an operations and security team should keep inside the boundary so that every image, unseal, failover and access decision can be reconstructed later. DeployOpen can prepare this evidence, but independent auditors and certification bodies are the ones who issue any assessment.
Image and chart provenance
Keep a record of every OpenBao or Infisical image and Helm chart that crossed the boundary, with the source, the version tag, the digest and the person who approved the transfer. For OpenBao, record the release line you mirrored, such as v2.7.1 from the October 1, 2026 release, so the deployed version can be matched to a known release. Check that the mirror contents match the manifest before anything is installed.
Release verification logs
For each import, log the checksum and signature verification result of the artifacts, the tool used, and the reviewer who signed off. Confirm with the project which signing keys and checksum files it publishes for each release, and store those reference values offline. A failed or skipped check should be recorded with the decision taken, not silently overwritten.
Unseal ceremony records
Shamir unseal keys or the chosen auto-unseal mechanism need a dated record of who held each key share, where it is stored and which custodians took part in each unseal. Record the quorum used for unsealing and any rekey or key rotation events. Test that the ceremony can be completed by the people named in the plan, because a sealed cluster with no available key holders is an outage that no backup can fix.
HA and failover test results
Keep dated results from node-loss and leader-failover tests on the chosen storage backend, whether integrated storage (Raft) or PostgreSQL. Record how long clients were unable to read or write secrets and which clients reconnected automatically. Retest after each upgrade, since the storage and read-scaling behavior changes between minor releases.
Backup and restore records
Store the backup schedule, the encryption of each backup, its off-site copy location inside the boundary and the result of periodic restore tests into a separate, isolated environment. A backup that has never been restored is an unverified claim. Record the recovery point achieved and the unseal steps needed after restore, and confirm those steps with your own environment before relying on them.
Access and audit logs kept locally
Audit devices, authentication events, policy changes and privileged session records should be forwarded to a log store that also runs inside the network, with retention set by your own policy and the rules that apply to you. Confirm with the vendor how each audit device behaves when its log target is unavailable, because a secrets service that cannot log may need to stop serving requests.
What a fixed-scope isolated deployment includes
A fixed-scope engagement for an isolated network means DeployOpen plans, implements, hardens, backs up, upgrades and documents the secrets platform inside your own boundary, whether that is OpenBao or Infisical. The scope, deliverables and timeline are agreed in writing before any work starts, so the boundary, the components in it and the evidence you will receive are fixed up front. Ask for the written scope to name the storage backend, the unseal approach, the HA topology, the backup target and the update path for air-gapped media, since each of these changes the work.
The client supplies the conditions the platform depends on. Network zones must be defined in advance, including where the OpenBao or Infisical nodes sit, which hosts may reach them and how an operator gets in. You provide the hardware or Kubernetes cluster, along with the storage and any HSM that your key custody policy requires. Confirm the key custody model before design begins, meaning who holds unseal material, how recovery keys are split and where they are stored. You also name staff who will own the platform after handover, including on-call operators who can perform unseal and upgrades without outside help.
Ongoing support and retainers are optional. A retainer can cover upgrades, backup restore testing, continuous security testing and documentation updates after handover, and it can be scoped to the same boundary as the original work. DeployOpen does not publish prices, so ask for a quote built from the written scope, and confirm which items are one-time and which recur. Confirm with your own change board whether a retainer fits your procedures for approving updates that arrive on physical media.
How DeployOpen deploys secrets managers inside air-gapped networks
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an Akeyless replacement that must run with no external control plane, we scope the boundary, the secrets inventory and the operating model before any software is brought in.
How we scope
- Map every Akeyless workload, gateway and auth path to its OpenBao or Infisical equivalent inside the boundary
- Agree in writing which secret types move: static, rotated, dynamic, PKI and encryption keys
- Define the unseal, key custody and recovery model with the people who will hold the keys
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Prepare an offline media and package intake process so every image and binary is verified before crossing the boundary
- Deploy OpenBao or Infisical with HA storage, TLS, auth methods and access policies in your environment
- Test failover, unseal procedures and backup restore against the written acceptance criteria
- Document the update path so new releases are verified and carried in through the same controlled process
How we hand over
- Deliver architecture, runbooks for unseal, backup, upgrade and rollback, and the configuration baseline
- Provide evidence packs that map controls to your compliance requirements, prepared for your independent assessors
- Train your platform and security staff to operate, monitor and audit the secrets platform
- Confirm the handover checklist with your team before any client workloads cut over
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Plan periodic upgrade windows that reuse the offline verification and staging process
- Re-run failover and restore tests after topology or version changes
- Confirm support terms, response expectations and included services in the written scope
