Which open-source password manager fits your team
A team that needs a self-hosted shared vault should choose by two questions at once: how many people will use it, and what the compliance assessment will ask to see. Bitwarden suits teams that want the official server and will buy the Bitwarden-licensed paid modules for production use, because the server code is AGPL 3.0 but the Commercial.Core and SSO modules are source-available and need a paid subscription in production. Vaultwarden suits small organizations that accept community support and want a lighter footprint, since it is an AGPL-3.0 server compatible with the Bitwarden clients, is not associated with Bitwarden, Inc., and its maintainers focus on individuals, families and small organizations. Passbolt suits teams that want OpenPGP end-to-end encryption and AGPL-3.0 code, with LDAP provisioning, SSO and SCIM available in the paid Pro edition.
The verdict depends on compliance needs as much as team size. If an auditor will ask who supports the software and how SSO, directory sync and MFA policies are enforced, the paid tier and its support terms matter more than the license label. Ask Bitwarden and Passbolt for written quotes that list the exact modules, user counts and support level, and confirm with Vaultwarden's community which SSO and policy settings your version supports. Check whether your assessor accepts a source-available license for production, and whether your recovery and backup process covers the database. Vaultwarden's own README recommends regular backups of files and the database, so plan that work before you choose.
Which password manager fits which scenario
This table matches five team situations to the password manager most likely to fit, with the reason and the condition that would change the choice. Read each row against your own directory, compliance evidence needs and team size, then check the condition column before shortlisting.
| Scenario | Best fit | Why | When the choice changes |
|---|---|---|---|
| Solo users and families | Vaultwarden | Vaultwarden is an AGPL-3.0 server that works with the official Bitwarden clients, and its maintainers focus on individuals, families and small organizations. | If you want vendor-backed support or the paid Bitwarden features, a licensed self-hosted Bitwarden installation becomes the better match. Bitwarden lite is for personal use and home labs only. |
| Small organizations without a directory | Vaultwarden or Passbolt Community Edition | Vaultwarden supports organizations, collections, groups and policies. Passbolt Community Edition is free to self-host with unlimited users and uses end-to-end encryption. | Vaultwarden support comes from the community, and its README tells users to report bugs to the Vaultwarden project. Choose Passbolt if you need end-to-end encryption with OpenPGP key pairs for every user. |
| Mid-size teams needing AD or LDAP sync and SSO | Passbolt Pro or self-hosted Bitwarden with paid features | Passbolt Pro lists LDAP user and group provisioning from AD or OpenLDAP and SSO with Microsoft, Google, OpenID and AD FS as Pro features. Bitwarden's Directory Connector syncs AD and LDAP users. | Passbolt Pro features are not in Community Edition, so the paid tier must be in the budget. Confirm with each vendor which SSO and sync options apply to your identity provider and edition. |
| Regulated teams needing audit and support contracts | Passbolt Pro or Enterprise, or Bitwarden with a paid subscription | Passbolt Pro includes syslog activity logs, MFA policies, account recovery and SCIM. Bitwarden paid features require a license file tied to the installation ID. | Vaultwarden offers no vendor support path, so it rarely fits this row. Ask each vendor for written support terms, and confirm that the edition you choose includes the audit logging your assessor expects. DeployOpen prepares evidence but does not issue audit reports. |
| Teams already on Passbolt or Bitwarden cloud | Stay on the current platform unless licensing or hosting rules require a move | Moving between servers means redoing attachments, invitations, enterprise policies and SSO in Bitwarden, and Passbolt users rely on their existing key pairs. | If data residency or licensing requires self-hosting, a Bitwarden cloud to self-hosted migration is documented, but attachments, invitations, policies and SSO must be redone. Plan the migration as a project with its own scope. |
What is open source and what is paid in each product
The Bitwarden server is not uniformly open source. Its main code is licensed under AGPL 3.0, but files in the bitwarden_license directory, including Commercial.Core and the SSO integration modules, fall under the Bitwarden License. That license is source-available and does not qualify as open source under the OSI definition. The vendor's license FAQ allows that code to be used for development and testing, but production use requires a paid subscription. If you plan to run SSO or other paid modules in production, budget for the subscription and read the Bitwarden server license FAQ against the exact modules your deployment will load. Paid features also depend on a license file tied to your installation ID and data region, so confirm the subscription terms and region match before you deploy.
Vaultwarden is AGPL-3.0 throughout, and it has no separate paid edition, so the license cost of the server itself is zero. Since version 1.35.0, Vaultwarden supports single sign-on with OpenID Connect, and releases through 1.37.3 added SSO fixes and settings such as SSO_SIGNUPS_ALLOWED. The trade-off is support: the project is not associated with Bitwarden, Inc., its maintainers focus on individuals, families and small organizations, and bugs go to the Vaultwarden project rather than Bitwarden support. Ask what support you can rely on if you choose it for a team, and treat backups of files and the database as your own responsibility.
Passbolt's server is AGPL-3.0, and the Community Edition is free with unlimited users. Paid functionality sits in Pro, which Passbolt's pricing page lists at $4.9 per user per month billed annually, with a 10-user minimum and volume discounts after 100 users. Features such as LDAP provisioning, account recovery, SSO with Microsoft, Google, OpenID and AD FS, MFA policies and SCIM are listed as Pro-only, so directory integration is a cost decision, not a configuration detail. Pricing and edition boundaries change, so confirm current terms with each vendor, and ask for a written quote that names the user count, billing period and any support included.
Capability across Bitwarden, Vaultwarden and Passbolt
This table compares the three self-hosted password managers on license, paid features, encryption, identity integration, databases, hosting, two-factor methods, import and export, and support. Read each row against your own requirements, and treat any cell marked as a confirm item as an open question for the vendor or project before you shortlist.
| Capability | Bitwarden | Vaultwarden | Passbolt |
|---|---|---|---|
| License | Main server code under AGPL-3.0; bitwarden_license directory under the source-available Bitwarden License, which is not OSI open source | AGPL-3.0, an alternative server implementation of the Bitwarden Client API and not affiliated with Bitwarden, Inc. | AGPL-3.0 for the API server and official Docker and Helm chart repositories |
| Paid features | Paid features require a license file tied to the installation ID; production use of Bitwarden-licensed code requires a paid subscription | No paid edition in the supplied facts; confirm current feature scope with the project before relying on it | Community Edition is free and self-hosted; Pro adds LDAP provisioning, SSO, MFA policies and SCIM; Enterprise is custom priced |
| Encryption model | Server-side vault encryption per Bitwarden's documented design; confirm client-side details with the vendor for your audit scope | Inherits the Bitwarden Client API encryption model used by the official clients; confirm the server's role with the project | End-to-end encryption using OpenPGP; the server stores only ciphertext and clients encrypt and decrypt locally |
| SSO and directory sync | Directory Connector (GPL-3.0) syncs AD, LDAP, Azure, Google Workspace or Okta users; SSO modules fall under the Bitwarden License | SSO with OpenID Connect added in 1.35.0; Directory Connector support is listed; confirm SSO settings for your provider | Pro adds SSO with Microsoft, Google, OpenID and AD FS plus LDAP user and group provisioning from AD or OpenLDAP |
| Databases | MSSQL is the default image database; lite deployment supports MSSQL, PostgreSQL, SQLite and MySQL or MariaDB | SQLite by default; MySQL or PostgreSQL through DATABASE_URL, with PostgreSQL marked as recommended | Hosting guide covers Docker, Kubernetes Helm, AWS AMI and Ansible; confirm the supported database engines with the vendor |
| Client and hosting options | Official Linux install guide, Helm charts and a lite single-container option intended for personal use and home labs | Container images on ghcr.io, docker.io and quay.io; requires HTTPS for the web vault and a reverse proxy is suggested | Installs on Debian 13, Ubuntu 26.04, Red Hat family, openSUSE Leap 15 and SLES 16; virtual appliance is Pro only |
| Two-factor methods | Confirm the full method list for your edition and plan with Bitwarden | Authenticator app, email, FIDO2 WebAuthn, YubiKey and Duo | Pro adds MFA policies; confirm the supported second factor types for your edition |
| Import and export | Migration from cloud to self-hosted is documented; attachments, invitations, enterprise policies and SSO must be redone | Compatible with Bitwarden clients, so client-side import and export follow the official workflow; confirm for your version | Imports from LastPass, 1Password, Bitwarden, Chrome and others; cleartext CSV export is disabled by default since 5.10 |
| Support model | Official Bitwarden support channels; confirm the support tier attached to your subscription | Community project; bugs go to the Vaultwarden project, not Bitwarden support, and backups are strongly advised | Community Edition is supported by the project and community; Pro and Enterprise support terms must be confirmed in writing |
Bitwarden, Vaultwarden and Passbolt in brief
Self-hosted Bitwarden is the official server from Bitwarden, Inc., and it is the option most aligned with the vendor's own cloud feature set. The main server code is AGPL-3.0, but files in the bitwarden_license directory, including Commercial.Core and SSO integration modules, fall under the Bitwarden License, which is source-available and not open source under the OSI definition. Production use of that code requires a paid subscription, and the license file for paid features is tied to the installation ID.
- Architecture: The standard install runs on Docker and uses MSSQL Express as the default database image, which carries a 10 GB database size limit.
- Lite option: A single-container deployment supports MSSQL, PostgreSQL, SQLite and MySQL or MariaDB, but Bitwarden positions it for personal use and home labs, not business use.
- Licensing: A standard self-hosted install needs an installation ID and key retrieved with a valid email address from bitwarden.com/host.
- Support path: Questions about the official server go to Bitwarden's own support channels.
- Who it fits: Organizations that want the official client and admin experience, accept the Bitwarden License for paid modules, and can run Docker or Kubernetes with Helm charts.
Confirm with Bitwarden which paid features your team needs and whether they require the commercial modules before you size the deployment.
Vaultwarden is an alternative server written in Rust that implements most of the Bitwarden Client API, so the official Bitwarden clients can connect to it. It is licensed under AGPL-3.0 and is aimed at self-hosted deployments where the official resource-heavy service is not a good fit. It is not associated with Bitwarden, Inc., and one active maintainer is employed by Bitwarden and contributes on their own time.
- Architecture: It uses SQLite by default and can use MySQL or PostgreSQL through the DATABASE_URL setting, with PostgreSQL marked as recommended in the configuration template.
- Features: The project covers organizations with collections, groups, event logs, policies, Directory Connector support, and SSO with OpenID Connect added in version 1.35.0.
- Licensing: The entire project is AGPL-3.0 with no separate paid edition.
- Support path: Bugs go to the Vaultwarden project, not to Bitwarden support channels, and the maintainers state they cannot be held liable for data loss.
- Who it fits: Individuals, families and small organizations that accept community support and can run HTTPS, a reverse proxy and regular backups of files and the database.
Check which SSO and directory features your version provides and set up backups and restore tests before your users depend on it.
Passbolt is a team password manager built on OpenPGP end-to-end encryption. Each user has a key pair, and each user with access to a shared resource receives their own encrypted copy. The server only receives and stores ciphertext, and encryption and decryption happen locally in the browser extension or mobile app. The API server, official Docker repository and Helm charts are AGPL-3.0.
- Architecture: Passbolt installs on Debian, Ubuntu, Red Hat family systems, openSUSE Leap, SLES, Docker, a Kubernetes Helm chart, an AWS AMI and Ansible, with a virtual appliance available for Pro only.
- Editions: The Community Edition is free for self-hosting with unlimited users. Pro adds features such as LDAP provisioning, SSO with Microsoft, Google, OpenID and AD FS, MFA policies and SCIM, and Enterprise is priced on request.
- Metadata encryption: Metadata such as names and URLs is encrypted only with the v5 format and when the organization enables it.
- Support path: Support follows the edition you buy, so confirm the channel for Community versus Pro before rollout.
- Who it fits: Teams that want per-user key control and a managed directory and SSO path, and that can plan around the Pro features they need.
Confirm which features your target edition includes, since directory sync and SSO sit behind Pro.
How each product protects shared passwords
Passbolt's model is the most specific of the three, because its documentation describes the cryptography directly. Passbolt uses end-to-end encryption based on the OpenPGP standard. Each user holds a key pair, and each user with access to a shared resource receives their own copy of the secret, encrypted with that user's public key. The Passbolt server receives and stores only ciphertext. Encryption and decryption happen in the browser extension or mobile app, and Passbolt states that the browser extension is cryptographically signed. Before rollout, your security team should verify that signature chain and the extension update process as part of its review, using the Passbolt documentation on securing data as the starting point.
Bitwarden and Vaultwarden also rely on client-side encryption, but the supplied sources describe their design differently. Bitwarden's clients and SDK are published under GPL v3.0 and the Bitwarden Software Development Kit License, so the client code can be reviewed. Vaultwarden is a separate server that is compatible with the official Bitwarden clients, which means the encryption you rely on sits in those clients, not in the Vaultwarden server. Vaultwarden also requires HTTPS for its web vault because of the Web Crypto API, so verify your TLS configuration before users log in. The sources do not describe key derivation, the key hierarchy or how shared organization keys are wrapped, so request written design documentation from Bitwarden and the Vaultwarden maintainers before you compare these products on cryptography.
Metadata protection is the detail most often assumed and least often checked. Passbolt states that names, URLs and descriptions are encrypted only when the resource uses the v5 format and the organization enables metadata encryption. Treat this as two settings to confirm, not one default to trust. Ask Passbolt which format your existing resources use, whether metadata encryption applies to them, and how imports from other managers are handled. Also confirm the export policy, since Passbolt disabled cleartext CSV exports by default from version 5.10 unless an administrator allows them again. Test these settings in a non-production organization and record the results as evidence for your security and compliance reviews.
How to choose and pilot a self-hosted password manager
This sequence moves a team from sizing and compliance needs to a tested pilot, so the final choice between Bitwarden, Vaultwarden and Passbolt rests on license terms, directory needs and a restore you have actually run.
Define team size and compliance needs
The security lead and compliance owner write down the number of users, the teams that will share credentials, and the evidence the assessor will expect, such as access logs, recovery procedures and documented backups. Vaultwarden's README says its maintainers focus on individuals, families and small organizations, so a large regulated population changes the shortlist early. Done when the requirements sit in one written note that every later step is checked against.
List required SSO and directory sync
The identity team lists which sign-in path users must use (OpenID Connect, SAML, AD FS or another provider) and whether accounts and groups must be provisioned from AD, LDAP or SCIM. Passbolt lists LDAP provisioning, SSO and SCIM as Pro features, while Bitwarden's Directory Connector is a separate GPL-3.0 tool for syncing AD, LDAP, Azure, Google Workspace or Okta users. Confirm each requirement against the current documentation for the edition you are considering. Done when every required integration is named, with the edition that provides it.
Confirm license terms for production use
The legal or procurement owner reads the license for each server component that will run in production, not only the headline license of the project. Bitwarden's server FAQ says code under the Bitwarden License, including the SSO integration modules, may be used for development and testing, but production use requires a paid subscription. Vaultwarden and Passbolt's API server are AGPL-3.0, so the team should confirm its obligations with counsel. Done when the team holds a written record of which components are open source and which need a paid agreement.
Check paid module needs against the edition list
The platform owner maps each required feature to a paid tier and prices the recurring cost from the vendor's own quote, since no price is set here. For Bitwarden, paid features need a license file downloaded from the cloud web app and tied to the installation ID, whose data region must match the cloud organization's region. For Passbolt, the pricing page lists Pro at a stated per-user rate with a 10-user minimum, while Community Edition is free with unlimited users. Done when the recurring cost of each shortlisted option is written against a named feature list.
Run a pilot on the chosen database and HTTPS
The platform team deploys the shortlisted server in a non-production environment using the database it will run in production. Vaultwarden uses SQLite by default and its template marks PostgreSQL as recommended, Passbolt's hosting guide supports Docker, Kubernetes and several Linux distributions, and Vaultwarden requires HTTPS for the web vault and suggests a reverse proxy. Bitwarden's Linux guide requires Docker Engine 26 or later and ships an MSSQL Express image with a 10 GB database limit. Done when the pilot serves the web vault over HTTPS through the proxy and a test user can sign in with the intended identity path.
Test import from the current password manager
The pilot owner imports a representative sample of the current vault, including shared folders and one entry with an attachment, into the pilot server. Passbolt documents CSV imports from Bitwarden, LastPass, 1Password and others, and KDBX for KeePass. Since Passbolt 5.10, cleartext CSV exports are disabled by default unless an administrator allows them, so plan the export format before the pilot starts. Done when item counts, folder structure and sharing match the source, and the team records any fields that did not carry over.
Set and test backup and restore
The operations owner defines what is backed up (the database, file attachments and configuration, including encryption and secret settings) and restores the backup into a clean environment. Vaultwarden's README says its maintainers cannot be held liable for data loss and highly recommend regular backups of both files and the database, so the team should not assume recovery is handled for it. Done when a restore has been completed, a test user can unlock a restored vault, and the runbook records the steps, owner and frequency.
Document the exit path back to a cloud account
Before committing, the team records how it would move data back to a cloud Bitwarden account. Bitwarden's migration guide says the organization exports its data, downloads its license, creates a cloud account with the same email and imports the data, and that attachments, member invitations, enterprise policies and SSO must be redone. Ask the vendor to confirm any gaps for the edition you choose. Done when the exit steps and manual rework are documented and approved, so the decision can be reversed without surprises.
Questions teams ask before choosing a self-hosted password manager
What does self-hosting cost compared with paid plans?
Self-hosting has no license line for the server software in some cases, but the total cost depends on the people and infrastructure around it. Plan for four components: the server team's time for installs, upgrades and patching, the database and its backups, the hosting itself, and any paid license. Passbolt's pricing page lists a free Community Edition, Pro at $4.9 per user per month billed annually with a 10-user minimum, and a custom-priced Enterprise plan. Bitwarden's paid features need a license file tied to your installation. Pricing and minimums change, so get current terms from each vendor and model both options for your headcount. Ask any implementer for a quote built from a written scope, since DeployOpen does not publish a price list.
How much effort does each option need to run?
The effort follows the resources and platform each option requires, so size them before you choose. Bitwarden's Linux install guide lists a minimum of 2 GB of RAM and 12 GB of storage, recommends 4 GB and 25 GB, and requires Docker Engine 26 or later. A standard installation also needs an installation ID and key from Bitwarden's host portal. Vaultwarden is a lighter Rust server that uses SQLite by default, with PostgreSQL recommended through the DATABASE_URL setting, and it must run over HTTPS behind a reverse proxy. Passbolt installs on several Linux distributions, with Docker, a Kubernetes Helm chart, an AWS AMI and Ansible as options. Confirm supported platforms and upgrade steps with each vendor before you size the environment.
Can our team run a self-hosted password manager without outside help?
Yes, if one or two engineers can own patching, backups, restores and upgrades on a fixed schedule and accept community or vendor support. Vaultwarden's maintainers say they focus on individuals, families and small organizations, ask users to send bug reports to the Vaultwarden project separately from Bitwarden's official support channels, and state they cannot be held liable for data loss. That makes a tested backup and restore routine the first skill to build. Bitwarden and Passbolt offer vendor support tied to paid plans, so confirm what each subscription covers. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside your own infrastructure, and offers ongoing support as a retainer, so you can run it in-house, hand it off, or split the work.
What does migrating from a cloud vault require?
Migration is mostly export, import and rework, and the rework is what teams most often underestimate. Bitwarden's migration guide describes exporting the organization's data, downloading a license, creating a self-hosted account with the same email address and importing the data. Attachments, member invitations, enterprise policies and SSO must be configured again. Passbolt's import documentation covers CSV exports from LastPass, 1Password, Dashlane, Bitwarden and major browsers, plus KDBX for KeePass. Since Passbolt 5.10, cleartext CSV export is disabled by default unless an administrator allows it. Run a test organization first, reconcile item counts and access groups, and scope the rework as its own line item.
Does Vaultwarden support SSO and directory sync?
Vaultwarden supports single sign-on with OpenID Connect, added in version 1.35.0 (released December 27, 2025), and later releases through 1.37.3 added fixes and settings such as SSO_SIGNUPS_ALLOWED. Its README lists Directory Connector support, but the Directory Connector client is a separate GPL-3.0 tool from Bitwarden that syncs AD, LDAP, Azure, Google Workspace or Okta users. Passbolt's directory and SSO features sit in the Pro tier: LDAP provisioning from AD or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, and SCIM. Test your identity provider, group mapping and deprovisioning path against the exact release you plan to run, reviewing the Vaultwarden releases for changes, and confirm the behavior with the vendor.
Which option suits a compliance review?
No password manager is pre-approved for compliance, so choose based on the controls your assessor will test. Passbolt encrypts with OpenPGP in the browser extension or mobile app, so its server stores only ciphertext, and metadata such as names and URLs is encrypted only in the v5 format with metadata encryption enabled. Bitwarden's paid tiers add enterprise policies and SSO, so confirm which controls your license covers. Vaultwarden is an alternative implementation that is not associated with Bitwarden, Inc., so its support and assurance model differs. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Your independent auditor or certification body does, so ask the assessor which evidence they need before you choose.
What should a written scope include?
A useful written scope names the platform, edition and license tier, the number of users and groups, the hosting target and the database. List the identity provider and directory to integrate, the migration source and the data that moves. Add the enterprise policies and features in use, backup and restore expectations, and who owns upgrades after go-live. State which evidence the assessor needs and whether security testing of the deployment is included. DeployOpen engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support available as a retainer. Ask any implementer to list exclusions, the vendor licenses it depends on, and who buys each one.
Risks to weigh before committing
Each of the three products carries a different kind of risk: community support depth, paid gating, and who owns the backups and the licensing outcome. The cards below name the condition under which each risk matters, so you can match them to your team size, compliance needs and the support model you can live with.
Vaultwarden support depends on volunteers
The Vaultwarden README states that one active maintainer is employed by Bitwarden and contributes on their own time, and that the maintainers focus on individuals, families and small organizations. It also tells users to report bugs to the Vaultwarden project, not to Bitwarden support. This matters most when a password manager outage blocks a team's sign-in. Before committing, confirm who answers incidents, what response you can expect in writing, and whether you can staff an internal owner who can debug the stack.
Bitwarden production features need payment
The main Bitwarden server code is AGPL 3.0, but the bitwarden_license directory, including SSO integration modules, is under the Bitwarden License. Production use of that code requires a paid subscription. Teams that plan on SSO or enterprise policies in production should budget for the subscription from day one. Paid features also depend on a license file tied to the installation ID, and the data region of that license must match the cloud organization's region.
Passbolt Pro gates LDAP and SCIM
Passbolt Community Edition is free with unlimited users, but LDAP user and group provisioning from AD or OpenLDAP, account recovery, SSO with Microsoft, Google, OpenID and AD FS, MFA policies and SCIM are listed as Pro features. Pro is priced per user per month with a 10-user minimum, as stated on Passbolt's pricing page. A directory-driven rollout cannot proceed on Community Edition alone. Ask for a written quote that covers user count, Pro seats and any Enterprise needs.
Backups are your responsibility
All three products are self-hosted, so the vault database, attachments and encryption configuration live in your environment. Vaultwarden's README says the maintainers cannot be held liable for data loss and highly recommends regular backups of files and the database. The risk grows with team size, because a failed restore can lock every shared credential at once. Test restores on a schedule and document who owns the backup job, the database and the keys, since Passbolt's keys sit with each user.
License changes over time
Licenses can change after you adopt a product. HashiCorp moved Vault from MPL-2.0 to the Business Source License 1.1 after announcing the change on August 10, 2023, which is why many teams now evaluate forks. In this group, Bitwarden already splits its licensing across directories, and Vaultwarden and Passbolt are AGPL-3.0. Review the license text at each major upgrade and confirm whether any feature you rely on moves into a paid or restricted tier.
Switching later costs time and access
Moving between these products is not a simple export. Bitwarden's documented cloud to self-hosted migration requires attachments, member invitations, enterprise policies and SSO to be redone. Passbolt's CSV exports are disabled by default since version 5.10, so an encrypted KDBX export may be the only route for some data. Choose the product your team can run for several years, and ask each vendor and your own team how a move out would be executed and tested.
How DeployOpen scopes a password manager rollout
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so the password manager you choose runs in your cloud account, data center or air-gapped network. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm which edition, license terms and paid modules your team needs before any build work starts.
- Map user counts, shared vault structure, directory sources and SSO requirements into a written scope.
- Record which compliance evidence the rollout must produce, and agree those deliverables in writing up front.
- Ask the vendor in writing which features your chosen edition includes, since paid features may need a separate license.
How we build
- Deploy the chosen server in your environment, with the database, reverse proxy and HTTPS configured to your standards.
- Connect directory sync and SSO to your identity provider, and test sign-in, MFA and account recovery paths.
- Harden the installation and set backup and restore routines for the database and attachments, then test a restore.
- Run security testing on the deployed service where the agreed scope includes it.
How we hand over
- Document the architecture, configuration keys, upgrade steps and access model in a handover pack your team keeps.
- Walk administrators through user onboarding, vault and collection policies, and the admin console.
- Provide evidence of configuration and testing that your compliance team and independent auditors can review.
- Agree in writing what remains with your team after acceptance, so ownership of the platform is explicit.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan upgrades around the vendor's release cadence, and confirm the release lines your edition supports.
- Schedule periodic restore tests and review backup coverage against the agreed recovery needs.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
