Self-hosted secrets management with open source

Why self-hosted secrets management is now a licensing decision as well as a security one

Most organizations that need to centralize secrets already have them scattered across application configuration files, CI pipeline variables, container images and personal password vaults. Moving them under your own control is a security goal, but the platform you pick also determines what license terms you live with for years. The two open-source options to evaluate for self-hosted secrets management are OpenBao, licensed under MPL-2.0 and hosted under the OpenSSF, and Infisical, which is MIT licensed for its core with a separate enterprise license covering content in its ee directories. The right choice depends on your licensing posture, the tooling your teams already use, and how much operating capacity you can commit to running a secrets service that other systems depend on.

The reason this is now a licensing question is that HashiCorp Vault 1.15.0 and later are distributed under the Business Source License 1.1, with IBM named as licensor. The Business Source License is not approved by the Open Source Initiative, so it does not carry the usage freedoms that open-source procurement policies often assume. Organizations that standardized on Vault for its open-source history should not assume that a current Vault release can be deployed, modified or offered internally on the same terms as earlier versions. Legal and procurement should read the current license text in the Vault license file before any architecture work begins, and should document which Vault versions, if any, are already in use.

Treat the license review as an input to the evaluation rather than a final gate. Ask counsel to confirm how the MPL-2.0 and MIT-plus-enterprise terms apply to your planned use, including whether any feature you need sits in the enterprise tier. Then compare each candidate on the operational questions that the license does not answer: how high availability and unseal are handled, whether your application and CI integrations already exist, and who on your team will patch, back up and rotate the root of trust. A license that fits your policy can still produce a secrets platform nobody can operate safely, so the decision should record both answers.

What to agree before choosing a secrets platform

Most secrets platform problems trace back to decisions made late or never: what gets stored, who and what reads it, where keys live, and who runs it afterward. The cards below are the questions to settle with your security, platform and audit teams before comparing OpenBao and Infisical on features.

Secret types and their lifecycles

Passwords, API keys, TLS certificates and encryption keys rotate on different schedules and fail in different ways. Inventory each type, its owner, its current storage location and how it is rotated today. Certificates need issuance and renewal workflows, while encryption keys need versioning so older data stays readable. Agree which types move into the platform in the first phase and which stay where they are until a later one.

Human and workload access patterns

Engineers need short-lived, audited access for troubleshooting, while services need identities that present themselves without a stored password. Map which applications, batch jobs and people need each secret, and whether access is by role, path or policy. Confirm how each consumer authenticates to the platform before you pick a product, because that choice determines how much custom integration you will build.

CI/CD and Kubernetes consumers

Pipelines and clusters are where secrets most often leak into logs, images and environment files. List every build system, deployment tool and cluster that needs secrets, and note whether each can fetch them at runtime or needs them injected. Decide early whether pipelines receive short-lived tokens or long-lived credentials, and who owns the sync or injection components that connect the platform to your clusters.

Data residency and key custody

Decide where the platform runs, which jurisdictions its data may touch, and who holds the unseal or root material. For a self-hosted deployment, the answer is usually your own cloud account, data center or air-gapped network. Settle whether keys are held in a hardware security module, a cloud key management service or by operators with split custody, since each option changes recovery procedures and audit questions.

Audit log retention and review

Auditors will ask who read which secret, when, and from where. Agree how long audit logs are kept, where they are stored, who can read them and how they reach your SIEM. Confirm that the platform writes audit records for every secret read and administrative change, and that the logs cannot be altered by the administrators they describe. Retention periods come from your own legal and contractual obligations, not from the product defaults.

Ownership after go-live

A secrets platform is a tier-zero dependency, so an outage can stop every application that depends on it. Name the team that patches, backs up, rotates the root credentials and runs recovery drills, and the on-call path for failures at night. Decide whether internal staff will operate the platform, whether a partner will support it under a retainer, or whether a hybrid model splits those tasks.

Which open-source secrets platform fits which situation

This table compares OpenBao, Infisical and HashiCorp Vault 1.15.0 and later across license, fit, feature areas to confirm and operating effort. Read it as a shortlist filter: license terms come first, then fit, then the features you must verify against current vendor documentation before you commit.

Dimension	OpenBao	Infisical	HashiCorp Vault 1.15.0 and later
License	MPL-2.0, hosted under the OpenSSF	MIT for core, separate enterprise license for content in ee directories	Business Source License 1.1 with IBM named as licensor, not an OSI-approved license
OSI-approved open source	Yes	Core is MIT, so yes for core only	No
Best fit	Teams that want a Vault-style server under an open license and can run their own HA cluster	Teams that want secrets, certificates and access in one product with a developer-facing workflow	Organizations already running Vault that can accept BSL terms and review them with counsel
Dynamic secrets	Confirm supported secret engines and plugin model in current OpenBao docs	Confirm which dynamic credential types are available in your edition	Documented in Vault; confirm current scope for your version and edition
PKI and certificates	Confirm PKI engine behavior, CRL and OCSP options, and renewal workflows	Confirm certificate issuance and lifecycle features in current docs	Mature PKI engine; confirm version-specific behavior before relying on it
Transit encryption	Confirm transit engine coverage and key rotation options	Confirm encryption-as-a-service support and which key types are included	Transit engine available; verify features against your target version
Secret sync to cloud and CI targets	Confirm sync options; often built with external tooling	Confirm native sync destinations and which are enterprise-only	Confirm integrations; many depend on separate products or plugins
High availability and unseal design	Plan own HA storage backend and unseal method (confirm in docs)	Plan own HA deployment and key handling (confirm in docs)	Plan own HA storage and unseal design; confirm current guidance
Operating effort	High: you own upgrades, storage, unseal, backups and monitoring	Moderate to high: you own hosting, upgrades, database and access policy	High: same operating burden as OpenBao, plus license review at each contract change

Reference architecture components and how they connect

A self-hosted secrets platform is a small set of components that must agree on who holds which key and who can reach which secret. Each component below connects to the next in a fixed order, and each has an owner on your side that a partner can help set up but cannot take over.

Storage backend and replication

The storage backend holds encrypted secret data, policies and audit-relevant state, so it is the component you can least afford to lose. Confirm which backend the candidate platform supports, how it replicates across nodes or sites, and how restores are tested. Decide whether replication stays inside one region or spans sites, because that choice sets your recovery point and your data residency posture. Your team owns backup schedules, restore drills and capacity growth.

Cluster and load balancing

Applications and pipelines reach the secrets service through a load balancer in front of a small cluster, with one active leader handling writes. Check how the platform handles leader failover, how health checks are defined, and whether clients retry safely during a switch. Plan TLS termination and certificate rotation for the listener. Your network team owns the load balancer, firewall rules and the placement of nodes across failure domains.

Unseal design

Most secrets platforms start sealed, and the master key must be recovered before any secret can be read. Choose between manual unseal with key shares held by named people, auto-unseal through a key service you control, or HSM-backed protection where the platform and your hardware support it. Each option changes your outage profile and your key ceremony. Your security team owns key custody, share distribution and the documented procedure for a cold restart.

Operator identity federation

The people who administer the platform should sign in through your existing workforce identity provider, with multi-factor authentication enforced there rather than through shared root tokens. Map identity groups to narrow administrative roles, and keep a break-glass path with split custody. Confirm how the candidate platform handles OIDC or LDAP login and whether administrative actions are tied to a named person. Your identity team owns group design and the break-glass register.

Workload authentication

Applications, containers and CI jobs should prove who they are before they receive a secret, using platform identity methods such as Kubernetes service accounts, cloud instance identity or OIDC tokens from the CI system. Avoid long-lived static tokens for workloads wherever the method allows it. Test that each method issues short-lived credentials and that revocation works. Your platform and application teams own the policy for each workload and the mapping from identity to secret path.

Audit logging and retention

Every read, write and policy change should produce an audit record that leaves the secrets service and lands in your log platform. Confirm the audit device options, whether logs can be sent to more than one destination, and whether sensitive values are hashed or redacted in the log stream. Set retention to match your regulatory and internal policy, and test that a sample request can be traced end to end. Your security operations team owns the pipeline, alerting and retention settings.

How applications, Kubernetes and CI pipelines consume secrets

Application services are the most common consumers and usually the largest source of hard-coded credentials. The usual pattern is for the service to authenticate to the secrets platform with an identity it already holds, such as a cloud workload identity, a platform-issued machine identity or an AppRole-style role and secret ID pair, then request only the secrets its role allows. Credentials issued this way are leased or time-bound, so the application renews them rather than storing a long-lived password in a configuration file.

Machine identity first: Prefer an identity the runtime already has over a bootstrap secret stored beside the application. Confirm which auth methods OpenBao or Infisical support in your environment.
Dynamic and leased credentials: Where the target system supports it, request database or cloud credentials with a lease so they expire without manual rotation.
Local caching and renewal: Use an agent or sidecar pattern, or a client library, to renew leases and avoid the application failing on expiry.
Inventory before migration: Scan repositories, container images and configuration files for embedded values, then map each to an owner and a rotation plan.
Staged cutover: Move one service at a time, keep the old value revocable, and remove it only after the new path has run in production.

Before committing, ask the implementation partner which languages, frameworks and legacy runtimes need custom client code and which can use an existing integration.

How a self-hosted secrets rollout runs in phases

The sequence moves from knowing what secrets exist to a secrets platform that your own team can run, recover and audit without depending on the implementation partner. Each phase closes with a written output that the next phase depends on.

Inventory secrets and their consumers
The team lists where passwords, API keys, certificates, database credentials and encryption keys live today, including config files, CI variables, scripts and password managers. For each secret, the inventory records the owner, the consuming application or pipeline, the rotation method and the blast radius if it leaks. The step is done when the inventory is reviewed by the application owners and every high-risk secret has a named owner. Gaps found here set the migration order later.
Confirm licensing and record the architecture decision
Compare OpenBao and Infisical against your requirements, including the license terms of the edition you plan to run. HashiCorp Vault 1.15.0 and later are under the Business Source License 1.1, which is not an OSI-approved open source license, so legal review is needed before any choice is made. Infisical's enterprise features sit under a separate license in its ee directories, so confirm which features your scope depends on. The output is a signed architecture decision record covering the platform, storage backend, hosting account, key custody and who holds the unseal material.
Build a non-production cluster and test HA and unseal
The team deploys a non-production cluster that matches the planned topology, with the storage backend, load balancing, TLS and network paths your production design will use. Engineers then test node failure, leader failover, restart and unseal procedures, including what happens when a quorum of unseal key holders is unavailable. Auto-unseal through a cloud or hardware key service is evaluated against your custody rules. The step closes when each failure test has a recorded result and the unseal runbook has been executed by someone other than its author.
Design the identity and policy model
Engineers map workloads, people and pipelines to authentication methods and least-privilege policies. Workloads are typically authenticated by platform identity such as Kubernetes service accounts or cloud identities, human access is federated from your workforce identity provider, and CI jobs use short-lived credentials. Audit devices are configured so that every secret read and administrative change is logged to a destination your security team monitors. The output is a reviewed policy catalog and an access matrix that auditors can trace from role to secret path.
Pilot with selected workloads and one CI pipeline
The team moves a small set of low-risk applications and one CI pipeline to dynamic or fetched secrets, leaving existing credentials in place until the pilot is stable. Application owners confirm that their code reads secrets correctly after restarts and during rotation, and the pipeline proves that build jobs no longer hold long-lived keys. Failures are logged and fixed in the templates used for later waves. The step is complete when the pilot runs through a full rotation cycle without manual intervention and the owners sign off.
Migrate in waves and rotate exposed secrets
Remaining workloads move in waves ordered by the risk recorded in the inventory, starting with the highest-exposure credentials. For each wave, the team rotates the secret, updates the consumer, verifies the new value works and revokes the old one, and it records the change for the audit trail. Secrets found in source repositories or old config files are treated as compromised and rotated, not just moved. The wave is done when the inventory shows no remaining copies of the migrated secret outside the platform.
Hand over operations with runbooks and restore tests
Before production is accepted, the operations team runs the backup and restore procedure into a separate environment and confirms that secrets, policies and audit configuration come back intact. They also rehearse upgrades, certificate renewal, key rotation for the platform itself and incident response for a suspected leak. Runbooks are reviewed by the team that will own them, and on-call responsibilities are agreed in writing. The handover is complete when the internal team has performed a restore test and a platform upgrade without partner staff in the room.

What migration from an existing vault and operating cost actually involve

The cost of a self-hosted secrets platform is mostly people time, and it splits into a one-time migration and a recurring operating load. Migration covers inventorying every secret, certificate and encryption key, deciding which ones move, re-pointing applications and pipelines, and rotating credentials that were exposed to the old store. Platform engineers carry most of that work, with application owners needed to confirm cutover windows. Ask a partner to price the inventory and dependency mapping as a separate line, because that is where scope usually grows. Confirm with the vendor and your own environment how the existing vault's data, policies, audit logs and leases will be exported or re-created, since not every item moves cleanly between stores.

Recurring cost is less visible. It includes infrastructure for the high availability nodes and the storage backend, along with backups and the network paths between them. It also includes unseal and key custody: whether unseal keys or auto-unseal keys sit with a cloud key service, an HSM, or a split-custody process run by named people. Each choice changes who is paid to hold the keys and how quickly recovery can happen. Upgrades, security patches and rotation policy reviews recur on every release cycle, and someone must be on call for a sealed or degraded cluster. A quote should show these as separate recurring items, with the hours for on-call coverage and the named roles that carry them.

Ask for the written scope to state the number of environments, the count of secret engines and integrations, the migration waves, the cutover approach and the handover of runbooks, and to separate one-time work from retainer support. DeployOpen does not publish a price list, and a quote follows from that written scope. The cost drivers that move the number most are the size of the secret inventory, the number of CI pipelines and applications to re-point, the custody model chosen for unseal material, and how long the team wants vendor-backed support after go-live. Compare licensing terms early, since a platform's license (for example, the Business Source License that applies to HashiCorp Vault 1.15.0 and later) can change the cost of commercial support and redistribution.

Systems the secrets platform must connect to

A self-hosted secrets platform is only as useful as the systems that consume it and the systems that watch it. The six integrations below set the access model, the audit trail and the ways credentials reach workloads, so each one should be scoped in writing before the first secret is migrated.

Operator login through the identity provider

Administrators and auditors should sign in to the secrets platform through the workforce identity provider, not through local root tokens or shared accounts. Confirm which OIDC or SAML claims map to policies, how break-glass accounts are stored and tested, and whether MFA is enforced at the identity provider and at the secrets platform. Ask who approves group changes and how removed staff lose access within a defined window.

Kubernetes and container runtimes

Pods and containers need short-lived secrets injected at runtime, usually through a sidecar, a CSI driver or an operator that syncs secrets into the cluster. Confirm which injection method fits your admission controls, how service account identities map to secrets paths, and what happens when the secrets platform is unreachable during a pod restart. Keep static secrets out of container images and manifests in Git.

CI/CD runners and pipelines

Build and deploy pipelines need credentials for registries, cloud accounts and deployment targets, and those runners are a common source of leaked secrets. Use short-lived tokens issued through workload identity where your CI platform supports it, and confirm that runner identities are scoped per project and environment. Ask how pipeline logs are masked and how a compromised runner token is revoked without halting releases.

Databases and cloud services for dynamic credentials

Dynamic credentials let the platform create a database user or cloud role on request and expire it automatically, which shrinks the window of a leaked password. Support varies by target system and by platform version, so confirm the exact database engines and cloud APIs you need before design. Check how rotation interacts with long-running connection pools and which application changes are required.

SIEM for audit log collection

Every read, write and policy change on the secrets platform should reach the SIEM so that access to credentials can be reviewed and investigated. This ties directly to the open source SIEM design, including retention, parsing and alerting on unusual secret reads. Confirm the audit device formats the platform emits, where logs are stored, and how the audit trail is protected from tampering.

Certificate issuance for internal PKI

Certificates and encryption keys are often managed alongside passwords, and internal PKI is one of the most common uses. Decide which certificate authority signs internal certificates, who owns the root and intermediate keys, and how short certificate lifetimes are automated to avoid outages. Confirm whether your certificate authority is hosted by the platform or by a separate system, and test renewal before a production cutover.

Which compliance controls secrets management helps evidence

This table maps two US control sets to the evidence a self-hosted secrets platform can produce, such as access logs, encryption settings and authentication records. Read each row as a prompt to ask what your platform and configuration will actually generate. DeployOpen prepares the systems and evidence for assessment, but independent auditors and certification bodies issue any attestation.

Requirement	What the secrets platform can produce	What to confirm before assessment
HIPAA 45 CFR 164.312 access control and unique user identification	Per-identity accounts or roles for people and workloads, with policies that limit which secrets each identity can read	Whether every human and service identity is unique, and how shared or break-glass accounts are restricted and recorded
HIPAA 45 CFR 164.312 audit controls	Audit logs of secret reads, writes, policy changes and token issuance, which can be forwarded to a SIEM	Log destinations, retention period, tamper protection and who reviews the records on a set schedule
HIPAA 45 CFR 164.312 person or entity authentication	Authentication methods for humans and machines, such as OIDC or SSO login for operators and short-lived tokens for workloads	Whether human logins require MFA through the identity provider, and how application identities are verified
HIPAA 45 CFR 164.312 transmission security	TLS settings for client connections, cluster traffic and secret delivery to applications and CI runners	Certificate management, protocol versions, and whether any secret is ever sent unencrypted
FTC 16 CFR 314.4 encryption at rest	Encryption of stored secrets and keys, with the root or unseal key protected by a documented method	Where the key encryption key lives, how it is rotated, and whether hardware or cloud key services are used
FTC 16 CFR 314.4 encryption in transit	Encrypted channels between clients, the secrets service and its storage backend	Certificate authority used, certificate rotation schedule and any internal services that bypass TLS
FTC 16 CFR 314.4 logging of authorized user activity	Records of which authorized user or service accessed which secret and when, including denied requests	Whether logs cover administrative actions and whether they are monitored, not only stored
FTC 16 CFR 314.4 multi-factor authentication	Enforcement of MFA happens in the identity provider that fronts the secrets platform, not inside the secrets platform alone	Which accounts can bypass SSO, and whether emergency root tokens are restricted and monitored

Questions buyers ask before hiring help with self-hosted secrets

What drives the effort and cost of self-hosted secrets management?

Effort follows the number of secret types, applications, pipelines and environments that must move to the new platform, plus the availability design you need. The main cost components are the people who design and build the cluster, the time spent onboarding each application and CI job, the infrastructure that runs the servers and storage, and the ongoing operation that follows go-live. Most of the one-time cost sits in integration work, not in installing the software. Recurring cost comes from patching, backup testing, rotation policy upkeep and on-call coverage. When you request a quote, ask for the work broken out by component: architecture, high availability and unseal design, each integration class, migration of existing secrets, and handover. Ask which items are fixed and which depend on counts you still need to confirm.

How long does a secrets platform rollout take?

No fixed duration applies to every environment, so the timeline is set by the scope agreed in writing before work starts. The variables that move it most are the number of applications and CI pipelines to integrate, whether existing static credentials must be inventoried and rotated, how many environments need a separate cluster, and how quickly your security and change approval processes can review designs and cutover plans. Staged rollouts usually begin with a non-production cluster, one or two pilot applications and a rollback plan, then expand workload by workload. Ask any partner for a phased plan with entry and exit criteria for each phase, and confirm which dependencies sit with your teams rather than with the implementer.

What does our team need to provide for the engagement?

Your team typically needs to supply a named technical owner, access to the target cloud accounts, data centers or air-gapped networks where the platform will run, and decisions on identity sources for human and workload access. Security should define the required policies, such as who may read which secret paths, rotation expectations and audit retention. Application owners must confirm which services consume credentials and how they can be changed to fetch them at runtime. Operations needs to agree on monitoring, backup location and on-call responsibilities. Ask the partner to list these inputs in the statement of work, with a named owner and a date each input is needed.

Can a small platform team run self-hosted secrets management alone?

A small team can operate a secrets platform if it has engineers comfortable with Linux, TLS, identity federation, Kubernetes or virtual machine automation, and infrastructure as code, and if the scope is limited at first. The work that often overwhelms small teams is not the first deployment but the recurring duties: upgrades, unseal procedure drills, backup restore tests, policy reviews, onboarding new workloads and responding to access requests. Before deciding, estimate how many people can cover those duties without single points of failure and whether they can respond outside business hours. DeployOpen supports self-hosted platforms through fixed-scope implementation and retainer-based support, so a team can split responsibilities between internal staff and external help.

How do we choose between OpenBao and Infisical?

OpenBao is a secrets, certificate and key management system licensed under MPL-2.0 and hosted under the OpenSSF, and it fits teams that want infrastructure-centric secret leasing, dynamic credentials and certificate issuance under a permissive license. Infisical is a platform for secrets, certificates and access licensed under MIT, except content in ee directories that carries a separate enterprise license, and it often fits teams that prioritize developer workflows, a managed user interface and broad application integration. Compare them against your required secret engines, audit export format, high availability model, identity provider integration, policy granularity and the operations skills you have. Confirm each feature against the current release notes before you commit.

What happens if we lose the unseal keys?

If the unseal material for a sealed secrets cluster is lost and no recovery path exists, the stored secrets can become permanently unreadable, so this is the most serious operational risk in the design. Prevention is the work that matters. Ask for a documented unseal design that defines how key shares or recovery material are generated, split, held by named custodians and stored separately, plus an approved procedure for rotating them. Auto-unseal with a cloud key management service or hardware security module shifts the trust point and needs its own recovery plan. Test restores from backup in a non-production environment on a schedule, and confirm that the partner will document and rehearse the recovery runbook before go-live.

How does licensing differ for enterprise features?

Licensing differs by project and by directory. Infisical's core is under MIT, but content in its ee directories carries a separate enterprise license, so features in those directories need a commercial agreement. HashiCorp Vault moved to the Business Source License 1.1 starting with version 1.15.0, with IBM named as licensor, which is not an OSI-approved open source license and limits some production or competitive uses. OpenBao is licensed under MPL-2.0. Before you choose, ask counsel and the vendor to map every feature you need to its license, confirm usage restrictions for your deployment model, and record which capabilities depend on a paid edition.

Which compliance evidence does a self-hosted secrets platform support?

A secrets platform supports evidence for several requirements, but it does not produce an audit opinion on its own. For HIPAA covered entities and business associates, the Security Rule at 45 CFR 164.312 covers access control with unique user identification, audit controls and transmission security, and a secrets platform can provide access policies, identities and audit logs for those controls. For the FTC Safeguards Rule at 16 CFR 314.4, relevant evidence includes encryption of customer information at rest and in transit and logs of authorized user activity. Auditors and certification bodies decide sufficiency. Ask a partner to map each control to specific configuration, logs and runbooks you will be able to produce.

What to ask an implementation partner before signing

Start with unseal and key custody, because it decides whether the secrets platform can recover at all. Ask the partner who holds each unseal key share or recovery key, how those shares are split across people and locations, and whether auto-unseal depends on a cloud KMS or an on-premises HSM. Ask for the written key custody procedure and a demonstration of a sealed node being brought back using only the documented steps. A partner who cannot show who can unseal the cluster at 3 a.m. without the original operator is describing a design that will fail under pressure. Also confirm where the root token is generated, who revokes it after bootstrap, and how break-glass access is logged and reviewed.

Next, ask for evidence rather than assurances on high availability. Request the failover test plan, the recovery time and data loss results from a leader loss and a network partition, and the procedure for restoring from the storage backend snapshot. Ask how the migration will be run from any existing secrets store, including whether secrets are re-issued or copied, how dual-running is handled for applications still reading the old path, and what the rollback trigger and rollback steps are. Confirm that the partner will leave the old store readable for a defined window. Ask which features of the chosen product are enterprise-only (for example, namespaces, replication or audited HSM integration), whether those licenses are priced into the quote, and who owns the license relationship. Confirm that the edition and license terms are checked against the current vendor license file before scope is signed.

Finally, settle what happens after go-live. Ask who owns runbooks, upgrades, certificate rotation for the secrets platform itself, and the backup and restore tests, and whether those documents are handed over in your repository with named owners. Ask how audit device logs are routed to your SIEM, which events are retained and for how long, and whether the partner will show a sample of the access record for a secret read by an application identity. Finally, confirm what support is included after handover and what is a separate retainer, so that the first major version upgrade does not become an unscoped project.

How DeployOpen scopes, builds, hands over and supports secrets management

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For secrets management, that means agreeing the platform choice, high availability and unseal design, and integration scope in writing before any build work starts, then handing over a system your own team can operate.

How we scope

Inventory the secret types, such as passwords, API keys, certificates and encryption keys, and the systems that consume them
Agree in writing whether OpenBao or Infisical fits the licensing, deployment and integration requirements
Define the unseal method, high availability topology and backup targets inside your own infrastructure
Confirm which CI pipelines, applications and migration sources are in scope, with deliverables and timelines fixed before work starts

How we build

Deploy the chosen platform into your environment with hardened configuration, access policies and audit logging enabled
Configure application and CI integrations so pipelines retrieve short-lived credentials instead of stored static values
Test failover, unseal recovery and backup restoration before any production workload depends on the platform
Plan and rehearse migration of existing secrets from current stores, with a rollback path for each application

How we hand over

Document architecture, policies, integration patterns and recovery runbooks in a form your operations team can follow
Provide evidence packs covering access control, audit log configuration and encryption settings for your assessors
Walk administrators through key custody, rotation procedures and onboarding steps for new applications
Confirm ownership of configuration, credentials and source artifacts so the client keeps control after go-live

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial build
Review platform releases and apply upgrades on an agreed schedule, with testing against your integrations first
Run security testing of the secrets platform and its integration points, including periodic review of access paths
Revisit policies and documentation when new applications, pipelines or compliance requirements are added