Why a self-hosted password manager for engineering and DevOps teams is a different problem
Engineering teams hold more shared secrets than most departments: root and admin logins for cloud consoles, API keys for SaaS tools, recovery codes for identity providers and the break-glass accounts that on-call engineers use when automation fails. A password manager is for credentials that people hold and share, such as console logins, vendor portal accounts and recovery codes. It is not the right place for secrets that CI pipelines, containers and services read at runtime. Before choosing a platform, list every shared credential, mark who uses it, and mark whether a human types it or a process retrieves it. That split decides which tool owns each item.
For human-held and shared credentials, Passbolt fits best when the team needs API and CLI access with OpenPGP-based sharing, because each user holds a key pair and each shared resource is encrypted to the people allowed to see it. Bitwarden or Vaultwarden suit teams that want developer-friendly clients and a familiar browser and mobile experience. For machine secrets such as database passwords, signing keys and service tokens, OpenBao is the stronger candidate, since it issues dynamic secrets and leases them with automatic revocation. These are starting points, not decisions. The right platform depends on whether your directory, audit, recovery and hosting constraints can be met by each option, and those constraints are covered in the sections that follow.
Treat the platform decision as a constraint exercise rather than a feature comparison. Confirm with each vendor which features require a paid edition, how the server handles metadata, and how API access is authenticated and logged in your environment. Ask whether the team can run the tool on infrastructure you control, how backup and restore are tested, and who patches the server after go-live. Engineering teams often underestimate how much of their sharing depends on the folder and group structure, so plan that structure before importing anything.
Requirements engineering teams inherit from HIPAA, the FTC Safeguards Rule and SOC 2
This table maps the access, authentication, logging and control expectations from HIPAA, the FTC Safeguards Rule and SOC 2 onto concrete vault configuration choices for engineering teams. Read each row as a requirement, what it means for the vault, and what to confirm before go-live. Most rows point to a design decision you make in the first week, not a feature you can add later.
| Requirement | What it asks for | What it means for the vault |
|---|---|---|
| HIPAA 45 CFR 164.312 unique user identification | Access control in systems holding ePHI, with each user identified uniquely | Create one vault account per engineer. Do not share a login for admin consoles, CI tools or vendor portals, and keep shared items in folders with named group access. |
| HIPAA 45 CFR 164.312 audit controls | Mechanisms that record and examine activity in systems containing ePHI | Confirm which vault events are logged and where they go. Passbolt lists syslog activity logs as a Pro feature, so plan for that edition before scoping audit evidence. |
| HIPAA 45 CFR 164.312 person or entity authentication | Verify that a person or entity seeking access is who they claim to be | Enforce SSO or MFA on vault login, and document how account recovery is approved so a reset does not bypass identity checks. |
| FTC Safeguards 16 CFR 314.4 MFA for any individual | Multi-factor authentication for any individual accessing any information system | Apply MFA to every engineer and contractor account, including automation users only where a human-operated fallback exists. Confirm whether MFA policies are available in your edition. |
| FTC Safeguards 16 CFR 314.4 monitoring and logging | Monitor and log the activity of authorized users | Forward vault activity to the same log platform used for other systems, and set retention that matches your examination period. |
| FTC Safeguards 16 CFR 314.4 encryption | Encrypt customer information in transit and at rest | Serve the vault only over TLS, and confirm the database and backup encryption design. Note that Passbolt encrypts secrets client-side with OpenPGP, while metadata encryption depends on the v5 format and organization setting. |
| SOC 2 security common criteria CC1 to CC9 | Security controls that apply to every SOC 2 examination, covering the control environment, communication, risk, monitoring and logical access | Document who can create, share and delete vault items, review group membership on a schedule, and keep evidence of offboarding removals. Auditors will test these records in a Type 2 period. |
| SOC 2 report scope | Type 1 covers control design at a date, Type 2 adds operating effectiveness over a period | Expect a Type 2 examination to sample access reviews and logs over months. Confirm with your auditor which vault evidence they will request before you configure reporting. |
Which password manager fits which engineering team
Engineering and DevOps teams hold three kinds of shared secrets: human logins, API and CLI access, and machine credentials used by pipelines and services. The options below separate a team password manager from a secrets manager, and show what to verify in each product before committing. Pricing and edition limits change, so confirm them against the current vendor documentation.
Passbolt Community for small teams
Passbolt Community is the free self-hosted edition, with AGPL-3.0 licensing and OpenPGP end-to-end encryption. Each user holds a key pair, and the server stores only ciphertext, so a DevOps lead can host the vault in the company's own cloud account. Use it to store shared admin logins and API keys in folders by service. Before rollout, confirm which identity and audit features your use case needs, since several sit in Pro.
Passbolt Pro for directory-managed teams
Pro adds the controls that engineering leaders usually ask for: LDAP user and group provisioning from AD or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, syslog activity logs, password expiry and SCIM. Passbolt publishes Pro at $4.9 per user per month billed annually, with a 10-user minimum and volume discounts after 100 users. Ask the vendor how group membership maps to folder access before you build the structure.
Self-hosted Bitwarden for mixed clients
Self-hosted Bitwarden suits teams that already use Bitwarden clients across desktop, mobile and browser, and want organization collections for shared engineering credentials. Confirm with Bitwarden which features, such as directory sync, SSO, event logs and policy controls, are available in the edition and license you plan to run. Ask how the server is supported and upgraded inside your own infrastructure before you choose it over Passbolt.
Vaultwarden as a lightweight vault
Vaultwarden is a community server that implements the Bitwarden client API, and it is commonly run by small teams that want a light footprint. It is not an official Bitwarden product, so confirm with the project and your auditors how it handles directory sync, event logging and support before you rely on it for shared production credentials. Plan backups and client-side policy enforcement carefully, since the server is only one part of the control set.
OpenBao for machine credentials
OpenBao is an MPL-2.0 secrets manager, forked from Vault and hosted under the OpenSSF, that stores key/value secrets encrypted before storage and issues dynamic secrets for databases and Kubernetes. Use it for pipeline tokens, service credentials and database passwords that software reads at runtime, not for human logins. Its auth methods include AppRole for servers and Userpass for developer machines, so map each credential type to the method that fits before migration.
Which credentials belong in a password manager and which belong in OpenBao
The split comes down to who or what uses the credential. Human logins to cloud consoles, administrator accounts, break-glass logins and recovery codes belong in the password manager, where a person opens them, shares them with a named group and leaves an activity trail. Service accounts, CI tokens, database credentials and certificates that software reads at runtime belong in OpenBao. Keeping a database password in a shared Passbolt folder so a deploy job can copy it is the pattern to avoid, because the vault has no way to rotate that secret, lease it for a short period or revoke it when one pipeline is compromised. Before go-live, inventory every shared credential and tag it as human or machine, then confirm with each owning team which of the two categories it truly falls into.
OpenBao gives engineering teams the controls a password manager does not provide. Its dynamic secrets issue short-lived database or cloud credentials on request, leasing with automatic revocation ends them when the lease expires, and encryption as a service lets applications encrypt data without holding key material. The auth method is the decision that determines who gets access. OpenBao's documentation recommends Userpass for developer machines and AppRole for servers, so engineers sign in with their own identity while pipelines and services authenticate with a role ID and a secret ID that the platform delivers and can rotate. Confirm which login methods your identity provider and CI system can support before you choose the auth methods, since the choice shapes how each workload is onboarded.
Passbolt and Bitwarden are the right home for the credentials engineers type. They are not the right home for values that a pipeline must read on every run. A practical test: if a credential is pasted into a configuration file, an environment variable or a CI variable, it should move to OpenBao and the vault should hold only a reference or the owner's access path. Document this rule in the team's security standard so that new shared accounts are classified at creation, not after an incident.
How to design folders and groups for product, platform and on-call teams
Grouping by team ownership gives each product or platform team a shared folder that holds the credentials it operates day to day, such as a service account for its staging database or the API key for its payment integration. Access follows the team, so membership changes are rare and the folder reads clearly to anyone looking for an owner. In Passbolt, each user with access to a shared resource holds their own copy encrypted with their public key, so a departing engineer's copy must be removed and the secret should be rotated if they had access to it.
- Offboarding is a rotation task: Removing a user from a team folder does not undo copies they already decrypted, so rotate every credential they could read.
- Group per team: Map each team to one group so that adding a new engineer is a single membership change.
- Naming rule: Use a pattern such as the team name, then system, then environment, for example
platform-billing-staging-db. - Owner field: Record a named owner for each folder and review ownership whenever a team reorganizes.
- Directory mapping in Pro: Confirm with the vendor how LDAP or AD groups or SCIM provisioning create and remove group memberships in your edition before relying on them.
Check whether any credential is shared across two teams, because duplicated ownership is where stale access tends to accumulate.
Grouping by environment separates production, staging and sandbox credentials into different folders with different membership. Engineers can work freely in sandbox, a smaller set of people can reach staging, and production access is limited to named operators. This design makes the highest-risk secrets easy to find and easy to restrict, and it keeps a sandbox compromise from exposing live systems.
- Production folder with few members: Keep membership small and review it on a fixed schedule set by your own policy.
- Environment in the name: Put the environment in every credential name so a copy-paste error is visible.
- Separate sandbox from production: Never store a production key in a folder that many developers can read.
- Mirror the directory: If you use groups in your directory, create one per environment and map it to the matching folder.
- Secrets that belong elsewhere: Machine credentials that services read at runtime are usually better kept in OpenBao, with only human-facing copies in the vault.
Confirm with your security team whether production shared accounts must also appear in your privileged access tooling.
Grouping by role collects emergency and on-call access in its own folders, such as break-glass administrator logins, root credentials for network devices, and the recovery codes for the identity provider. These credentials are used rarely, and each use should be visible to the security team. Role-based folders keep the membership short and make it obvious who can reach the emergency path.
- Separate break-glass folder: Hold emergency accounts apart from routine team folders, with a small, named membership.
- On-call group: Grant on-call engineers access through a rotation group, so the list changes as the schedule changes.
- Alerting and rotation: Rotate any break-glass secret after each use, and confirm how your edition records access events, since activity log features differ across Passbolt editions.
- Test the path: Rehearse retrieval while SSO is unavailable, because a vault that only works with the identity provider is not a break-glass control.
- Recovery ownership: Decide who can run account recovery and document the approval step.
For a fuller procedure, see the page on managing shared and break-glass credentials with a self-hosted password manager.
Rollout phases for an engineering team migrating off shared spreadsheets and chat
This sequence moves an engineering team from credentials scattered across spreadsheets, chat and wikis into a vault on company infrastructure, with each phase ending in a checkable output that the next phase depends on.
Inventory and classify every shared credential
The team lead and a security owner list where credentials live today, including chat threads, wiki pages, spreadsheets, CI variables and admin notes. Each item is classified as a human-used login for the password manager, a machine secret for OpenBao, or a credential to retire by deleting or replacing it. The output is a signed-off inventory with an owner and a classification for every entry, and a list of the systems that will need rotation after migration.
Design folders, groups and sharing rules
The security owner and team leads define groups that match real duties, such as platform admins, on-call engineers and service owners, and decide which folders each group can read, edit or manage. Sharing is granted to groups rather than individuals wherever the product allows it. The output is a written access model with a named owner for each folder and a rule for who may grant access, checked against the inventory from the previous step.
Deploy the vault on company infrastructure
The platform engineering team installs Passbolt on servers or in a cluster the company controls, using a path listed in the vendor's hosting guide such as Docker, the Kubernetes Helm chart, Ansible or a supported Linux distribution. They confirm TLS, backups and the server's network placement before any user data exists. The output is a reachable test instance with a documented build, a tested restore of the database, and a record of the exact version deployed, checked against the current release notes.
Import existing entries using supported formats
Once the instance is stable, an administrator imports entries from the current tool using a format the vendor documents for that tool, such as CSV from a supported password manager or KDBX for KeePass. Imported data is checked against the inventory so that duplicates and orphaned entries are removed. The output is a reconciliation report showing counts per folder and any entries that failed to import. Confirm the export policy in the vendor settings before exporting anything, because cleartext CSV exports may be disabled by default in recent versions.
Pilot with one engineering team
A single team with a clear on-call and deployment workload uses the vault for its real credentials for a fixed period agreed in advance. Members are asked to report friction with browser extensions, CLI access, recovery and sharing, and the platform owner logs each issue. The output is a pilot report that lists which workflows work, which need a change in folder design or policy, and which credentials should move to OpenBao rather than remain in the vault.
Enforce MFA, password policies and recovery
Before the wider rollout, the security owner turns on multi-factor authentication, password and passphrase policies, and account recovery if the chosen edition supports them. Edition-specific features should be confirmed against the pricing comparison, since several controls are listed for paid editions. Recovery and key-loss procedures are tested with a test account. The output is a documented policy baseline, a screenshot or export of each setting, and a test record showing that recovery works without granting one person unilateral access to shared secrets.
Retire secrets in chat and wikis
Engineers remove credentials from chat channels, wiki pages, tickets and shared documents, and replace each one with a link to its vault entry. Any credential that appeared in plain text in those locations is rotated, because it should be treated as exposed. Chat search and wiki history are checked for residual copies. The output is a removal log per source with the rotation status of each item, and a short standard telling engineers where credentials now live.
Schedule rotation and recurring access review
The security owner sets a rotation schedule for shared human credentials and asks each folder owner to review group membership on a recurring basis. Machine secrets are scheduled for rotation in OpenBao, and offboarding steps are linked to the identity provider. The output is a published calendar of reviews and rotations, a named owner for each recurring task, and a first completed review that closes the rollout.
Integration points and deployment patterns for DevOps environments
Does Passbolt support SSO and directory sync without a paid edition?
Not in the free Community Edition. Passbolt's pricing comparison lists LDAP user and group provisioning from Active Directory or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, SCIM and syslog activity logs as Pro features. Pro is priced per user per month with a 10-user minimum, so the license decision belongs in the scope before you design the directory mapping. Confirm with Passbolt which identity provider versions and group attributes the Pro edition supports in your environment, and ask how group membership changes deprovision vault access.
How do engineers use the Passbolt and Bitwarden browser extensions and CLI?
Engineers mostly use browser extensions and mobile apps for day-to-day retrieval, since Passbolt performs encryption and decryption locally in the browser extension or mobile app and never on the server. Command-line access is a separate capability that varies by product and edition, so confirm the supported CLI tool, its authentication method and whether it can be used non-interactively before you write it into a runbook. Test the extension update path on your fleet, because extension versions must match the server release.
Should CI runners pull secrets from the password manager or from OpenBao?
Pipelines should read machine secrets from OpenBao, not from the password manager. OpenBao is built for secrets distribution, with dynamic secrets, leases and automatic revocation, and it documents AppRole for servers and JWT/OIDC for workload identity, so a runner can receive short-lived credentials tied to a pipeline identity. The password manager remains the place for humans to hold shared logins and recovery material. Keep the bootstrap credential that a runner uses to reach OpenBao in the password manager, and rotate it on a schedule you can prove.
How do I back up a self-hosted Passbolt or Vaultwarden instance safely?
A complete backup has three parts: the application database, the server configuration and the keys that the server uses. Passbolt stores only ciphertext, but a backup without the server key material and the matching database cannot be restored, and a backup of the database alone can expose metadata. Store backups encrypted and off the application host, restrict who can read them, and test a full restore to a separate server before you rely on it. Ask your implementation partner which restore time and recovery point your organization needs, because those choices drive backup frequency and storage.
Can Passbolt run on Kubernetes, and what install options does the hosting guide list?
Yes, Passbolt provides an official Kubernetes Helm chart, maintained in the charts-passbolt repository. The hosting guide also lists installation on Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux and Oracle Linux 9, openSUSE Leap 15 and SLES 16, Docker and Ansible, plus an AWS AMI. A virtual appliance is available for Pro only. Choose the target based on your existing platform standards and who will patch it. Confirm with Passbolt how the chart handles database persistence, secrets injection and upgrades before you commit to a cluster.
Where should a self-hosted password manager sit on the network?
Place the server inside the company perimeter on a segment reachable only from managed devices, with HTTPS terminated on an internal certificate authority that your endpoints trust. Limit database access to the application host, and do not expose the admin interface to the internet. Consider whether engineers working from outside the office need a VPN or zero trust access path, and whether vault access should require MFA at the identity provider. Confirm with the vendor which outbound connections the server and extension require, since some features depend on them.
What should I confirm with the vendor before designing DevOps integrations?
Confirm which integrations are in your edition, not just which exist in the documentation. Ask about SCIM provisioning and group mapping, SSO protocols supported for your identity provider, CLI capability and authentication, API tokens and their scope, audit log export to your SIEM via syslog, and whether the metadata encryption setting applies to your version. Also ask how the vendor's upgrade cadence affects extension and API compatibility, and what support covers when a Helm chart or OpenBao integration breaks after an upgrade.
Evidence auditors ask engineering teams to produce from the vault
This table maps the records an assessor typically asks engineering teams to produce from a self-hosted vault to the component that generates each one. Read it as a checklist: where a row names Passbolt Pro or OpenBao, that is the system of record, and where it names company records, the team must keep them itself. DeployOpen prepares these systems and evidence for assessment, but auditors and certification bodies issue the opinions and certifications.
| Evidence | What to produce | Where it comes from |
|---|---|---|
| User list and access by folder | Named users, groups and the folders or resources each can reach, with a dated export | Passbolt folder and group permissions, exported through the admin interface and reviewed on a set cadence |
| Activity logs | Records of shares, secret views, edits and deletions tied to a named user and timestamp | Passbolt Pro syslog activity logs forwarded to the company SIEM; confirm retention with the log platform |
| MFA policy settings | Screenshot or config record showing MFA is enforced for vault login and the date it changed | Passbolt Pro MFA policy settings, plus the SSO provider's MFA configuration for SSO users |
| Password and passphrase policy settings | Current policy values and change history for complexity and expiry rules | Passbolt Pro passphrase, password and expiry policy settings; keep dated exports of each change |
| Export policy settings | Evidence that cleartext CSV export is disabled or restricted to approved administrators | Passbolt export policy configuration; since Passbolt 5.10, cleartext CSV is off by default unless an administrator re-enables it |
| Machine secret access | Who or what read, wrote or leased secrets, with paths and timestamps | OpenBao audit device output for machine and dynamic secrets, shipped to central storage; confirm the audit device setup for your version |
| Offboarding records | Ticket showing access removal, group removal and any shared credential rotation, with dates | Company HR and ticketing records, cross-checked against Passbolt user state and SSO deprovisioning logs |
| Backup test records | Restore test results for the database and encryption material, with date and tester | Company operations records and backup tool logs; the vault does not produce this on its own |
Questions to ask an implementation partner before a DevOps password manager rollout
Start by asking how the partner draws the line between the password manager and OpenBao. Ask who will decide, for each credential type, whether it lives in Passbolt or Bitwarden as a shared login or in OpenBao as a dynamic or leased secret, and ask to see that decision written as a table with a named owner for each row. Ask how service accounts that a pipeline reads at runtime will be handled, since a partner that cannot answer this without a whiteboard is likely to leave API keys sitting in shared folders. Ask whether OpenBao is in scope at all, and if it is, which auth method the partner proposes for developer machines and which for servers. OpenBao's documentation recommends Userpass for developer machines and AppRole for servers, so the partner should be able to explain why it differs from that guidance if it does.
Ask how credentials will move from the current tool without cleartext appearing on a laptop or in a shared drive. Passbolt disables cleartext CSV export by default since version 5.10, and the export list offers encrypted KeePass KDBX formats unless an administrator re-enables CSV in the export policies. Ask the partner to state who holds the export policy during migration, where the import file is stored, how it is deleted afterward, and whether the old vault is retired or kept read-only. Ask which Passbolt version the partner will install and how it will be pinned, given the 2026 cadence of v5.14.0 on July 28, v5.15.0 on August 21 and v5.16.0 on September 17.
Ask which features the team needs before anyone commits to an edition. Passbolt's comparison lists account recovery, MFA policies, syslog activity logs, SCIM, LDAP provisioning and password expiry as Pro features absent from Community Edition, and Pro is priced per user with a 10-user minimum on the public pricing page. Ask the partner to show the audit trail a security reviewer would need for shared engineering secrets and to confirm which edition provides it. For break-glass and offboarding, ask how emergency accounts are split, how use is alerted, how each credential is rotated after use, and how a departing engineer's personal folders and shared group memberships are removed in one step. Ask how often the partner will test that procedure and who signs off the result.
What engineering teams ask before hiring help for a self-hosted password manager
What drives the cost of a self-hosted password manager for engineering teams?
The cost is mostly people time and recurring infrastructure, with license fees only if you choose a paid edition. Passbolt's Community Edition is free to self-host with unlimited users, so the main line items are server and backup infrastructure, the implementation and configuration work, migration of existing credentials, and staff time for training and administration. Passbolt's pricing page lists Pro at $4.9 per user per month billed annually with a 10-user minimum, and Enterprise at custom pricing, so ask any partner to separate license cost from services cost in the written quote. Ask what is one-time (design, import, hardening) and what recurs (licenses, hosting, upgrades, support retainers).
How long does a self-hosted password manager rollout take?
The duration depends on the number of teams, how many credentials need migrating, whether SSO and directory sync are required, and how much of the folder and group design is settled before go-live. No duration figure is supplied for this, so ask any partner for a phased plan with a written timeline tied to a defined scope. A typical sequence is a pilot with one engineering team, a review of which secrets belong in the vault versus a secrets manager, bulk import, then staged onboarding. Engagements of this type are fixed-scope, so the timeline should be agreed in writing before work starts.
Can our team deploy and run a password manager without outside help?
A capable platform or DevOps team can deploy Passbolt Community or Vaultwarden from published installation methods, but the harder work is operational design. Passbolt's hosting guide lists installation on several Linux distributions, Docker, a Kubernetes Helm chart and Ansible, so the install path is well documented. What teams often underestimate is backup and restore testing, TLS and reverse proxy setup, upgrade planning, folder and group permissions, offboarding procedures and logging. If nobody on the team owns those tasks after go-live, outside help may cost less than the incidents it prevents.
What does the engineering team need to provide during implementation?
The engineering team provides the inputs that determine the design and the people who make decisions about it. Expect to supply a list of shared credentials by type (admin logins, service accounts, API keys, recovery codes), the identity provider and directory details if SSO is needed, hosting targets and network constraints, and named owners for each folder or group. Engineers also need time for a pilot and for validating imports and client setup. Ask any partner to document these prerequisites in the written scope so that delays are visible early.
Do we need Passbolt Pro or is the Community Edition enough for engineering teams?
The Community Edition is free to self-host and covers shared storage with end-to-end encryption, so many engineering teams start there. Passbolt's comparison lists several features as Pro only, including LDAP user and group provisioning, account recovery, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, syslog activity logs, passphrase and password policies, a password expiry policy and SCIM. If your team needs directory-driven group membership, enforced MFA, or logs forwarded to a SIEM, price Pro against those requirements. Confirm current feature lists on Passbolt's pricing page before deciding.
Is OpenBao required alongside a password manager?
No, OpenBao is not required for a password manager, but it covers a different job. A password manager holds human-shared credentials such as admin logins and recovery codes, while OpenBao manages secrets that applications and pipelines read at runtime, with dynamic secrets, leasing and automatic revocation. OpenBao's documentation recommends Userpass for developer machines and AppRole for servers, which suggests the two tools can coexist. Teams that run CI/CD and many services should plan for a secrets manager, and should decide the boundary in writing so credentials are not duplicated across both systems.
How does support work after go-live for a self-hosted password manager?
After go-live, your team owns or contracts for operations, including upgrades, backups, monitoring and incident response. Passbolt releases new versions regularly, for example v5.16.0 on September 17, 2026, so a patch and upgrade routine is necessary. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope with terms agreed in writing. Ask any partner what response targets they will commit to in writing, who holds administrator credentials, how restore tests are scheduled, and what happens to the vault if the engagement ends.
How DeployOpen scopes and supports a DevOps password manager
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and supports self-hosted open-source platforms inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. For an engineering password manager, that means the vault server, its database and backups, the SSO connection, the client rollout and the folder and group model all run where your security team already controls access. DeployOpen does not resell or hold partner status with any vendor, so the choice of Passbolt, Bitwarden or Vaultwarden stays a decision you make on the requirements, not on a reseller relationship.
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts. For this use case, the written scope should name the platform and edition, the hosting method, the list of teams and shared folders to migrate, how credentials will be imported and which exports are allowed, and who approves the design of groups and roles. DeployOpen does not publish a price list. A quote follows from that written scope, so the more precisely you define the number of users, the systems in scope and the integrations such as directory sync or SSO, the more comparable the quotes you receive will be. Ask each bidder to separate one-time work from recurring charges.
Ongoing support, version upgrades and scheduled testing are available as retainers. Engineering teams should plan for recurring work on the vault itself: applying security releases to the server and clients, restoring backups on a schedule, reviewing activity logs and reconciling group membership after team changes. Confirm in the scope which of these your own platform team keeps and which a retainer covers, and agree who responds when the vault or its SSO integration fails outside working hours. Those answers matter more to an on-call engineering team than the initial installation.
