A self-hosted installation is a deployment that an organisation runs on its own infrastructure rather than in a provider-managed cloud environment. In password management, it can coexist with cloud accounts under the same multi-account sign-in model, while still remaining operationally and logically separate from other accounts.
Expanded Definition
A self-hosted installation is software that an organisation deploys and operates on infrastructure it controls, rather than consuming the same service as a provider-managed cloud tenancy. The term is used most often when the deployment model changes who owns availability, patching, backup, segmentation, and data handling, not just where the software runs.
In security discussions, self-hosted usually means the operator must manage the full trust boundary around the instance. That includes authentication flow, log retention, upgrade timing, and any connected credentials or integrations. This is different from merely choosing a private network or a dedicated tenant, because provider operation and customer operation are still distinct responsibilities. Definitions vary across vendors, but the practical boundary is simple: if the organisation is responsible for the runtime and its protections, the installation is self-hosted.
A common misunderstanding is to treat “self-hosted” as automatically more secure. In reality, it only changes the control model. The security outcome depends on whether the operator can maintain it correctly, not on the deployment label itself.
Examples and Use Cases
Self-hosted installation appears in several practitioner settings where control, data locality, or integration depth matters more than outsourcing operations. It is often chosen when teams need direct access to the stack or must align the deployment with internal policy.
- An organisation runs a password manager on its own infrastructure so administrative access, backups, and retention stay under internal control.
- A regulated business hosts collaboration or workflow software in its own environment to keep logs, metadata, and authentication paths inside a defined boundary.
- A security team deploys internal tooling on a private cluster so it can tune network restrictions, telemetry, and update cadence to match its own change process.
- An enterprise uses self-hosting when a provider-managed service cannot meet residency, integration, or segregation requirements.
The tradeoff is operational burden. Self-hosting can improve configurability and data control, but it also makes resilience, patch discipline, and incident response depend on the operator’s maturity rather than the vendor’s service model.
Security Implications
Self-hosted installations shift more failure modes onto the organisation. If patching is delayed, backups are incomplete, or the instance is exposed too broadly, the result can be direct compromise rather than a provider-side service issue. The most common security problem is not the hosting model itself, but weak ownership of the surrounding controls.
Because the operator controls the deployment, mistakes often show up as configuration drift, inconsistent logging, overbroad admin access, or untested recovery procedures. Those weaknesses can turn a single exposed instance into a durable foothold, especially when the installation stores secrets, authenticates users, or brokers access to other systems. NHIMG notes that 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, which is a useful reminder that self-hosted control only helps when the controls are actually sound.
A practitioner should assume that any self-hosted service becomes part of the organisation’s attack surface the moment it is exposed, integrated, or trusted by other systems. That is where the security burden increases fastest.
Domain and Governance Relevance
In NHI, identity governance, and secrets management, self-hosted installation matters because it changes who must secure the control plane that stores or brokers machine access. A self-hosted secrets vault, authentication service, or password platform is not just an application deployment; it becomes part of the trust fabric for service accounts, API keys, certificates, and automation.
That matters for lifecycle governance. The operator must own patching, key protection, audit coverage, offboarding, and recovery because a failure in the installation can expose many downstream non-human identities at once. NHIMG’s Ultimate Guide to NHIs is a useful reference for the governance realities around lifecycle, visibility, rotation, and offboarding in these environments. When the installation is self-hosted, those responsibilities cannot be assumed to exist by default.
For teams managing machine identities or credential stores, the key question is not whether the software is self-hosted, but whether the organisation can prove ownership of every control that keeps that deployment trustworthy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | Self-hosted installs require local ownership of admin and service accounts. |
| 7 — Continuous Vulnerability Management | Operator-run deployments depend on timely patching and vulnerability handling. | |
| 8 — Audit Log Management | Self-hosted operation requires the operator to collect and retain logs. | |
| Recommendation — Review and remove unnecessary local accounts and privileges on the hosted system. Scan and patch the self-hosted stack on a defined cadence. Enable centralized logging and protect audit trails from tampering. | ||
| NIST Zero Trust (SP 800-207) | 3 — Zero Trust Security Model | Self-hosted services should be treated as untrusted resources requiring verification. |
| Recommendation — Treat the installation as a protected resource and verify access before trust. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Discovery and Inventory | Self-hosted secrets or identity services need explicit ownership and inventory. |
| Recommendation — Inventory every self-hosted identity or secrets component and assign ownership. | ||
Related resources from NHI Mgmt Group
- How should security teams protect self-hosted AI runtimes from memory disclosure?
- How should security teams choose between managed and self-hosted CIAM?
- How do organisations decide between self-hosted open-weight models and hosted APIs?
- What do teams get wrong about choosing a self-hosted authentication framework?
