When self-hosting Passbolt fits and when the cloud edition fits
Choose self-hosting when your rules require the Passbolt server, its database and its metadata to stay inside your own infrastructure, whether that is your cloud accounts, a data center or an air-gapped network. Choose Passbolt Cloud when you would rather the vendor run the service and you accept that the hosting sits outside your estate. The advantage of self-hosting only matters if a regulator, a customer contract or an internal policy names where the data must live. If none of those apply, the operating work of self-hosting is a cost without a matching benefit.
Both models use the same OpenPGP end-to-end encryption. Each user holds a key pair, each person with access to a shared resource receives their own encrypted copy, and encryption and decryption happen in the browser extension or mobile app rather than on the server. The server stores ciphertext in both cases. The difference is who controls the machines holding that ciphertext and the metadata around it. Passbolt's documentation says metadata such as names, URLs and descriptions is encrypted only with the v5 format and when the organization enables metadata encryption, so confirm that setting before deciding where metadata risk sits. Ask your team to verify this in the Passbolt docs on securing your data.
Self-hosting also shifts upgrade and backup duties onto your team. Passbolt's hosting guide covers several Linux distributions, Docker, a Kubernetes Helm chart, an AWS AMI and Ansible, and a virtual appliance for Pro only, so the installation target you pick decides much of the work. Check that your platform team can apply each release, back up the database, and restore it into a test environment before go-live. Cloud subscribers hand these tasks to Passbolt, which means you must instead confirm the vendor's backup, recovery and support terms in writing before you sign. Neither path removes the need to govern who is an administrator of the vault.
Passbolt Cloud and self-hosted Passbolt factor by factor
This table sets Passbolt's published editions and self-hosting facts against the duties that stay with your team in each model. Read it by first confirming the edition you need, then checking which upgrade, backup and data-location duties sit with you and which sit with Passbolt. Where the supplied material is silent on cloud operations, the cell tells you what to confirm before you decide.
| Factor | Passbolt Cloud | Self-hosted Passbolt |
|---|---|---|
| Editions and published price | Cloud-managed edition offered alongside Community, Pro and Enterprise; confirm which features and per-user terms apply to cloud hosting on the pricing page | Community Edition is free and self-hosted with unlimited users; Pro is $4.9 per user per month billed annually with a 10-user minimum (Passbolt pricing page) |
| Pro-only features | Confirm with Passbolt which Pro features (LDAP provisioning, account recovery, SSO, MFA policies, syslog, SCIM) are included in the cloud edition | Pro features such as LDAP provisioning, account recovery, SSO, MFA policies, syslog logs and SCIM are listed as Pro-only in the pricing comparison |
| Installation targets | Not applicable; Passbolt operates the service, so confirm hosting location and regions with Passbolt | Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux, Oracle Linux 9, openSUSE Leap 15, SLES 16, Docker, Kubernetes Helm chart, AWS AMI and Ansible; virtual appliance for Pro only (Passbolt hosting guide) |
| Ciphertext and metadata | Server receives and stores ciphertext; confirm with Passbolt whether metadata encryption is enabled for your organization and which format applies | Server still stores only ciphertext; metadata such as names, URLs and descriptions is encrypted only with the v5 format and when the organization enables metadata encryption |
| Where decryption happens | Encryption and decryption happen in the user's browser extension or mobile app, not on the server, in both models | Same client-side model; the browser extension is cryptographically signed, so verify the extension build your users install |
| Import behavior | CSV imports from LastPass, 1Password, Dashlane, Bitwarden and others are documented for the Cloud edition; confirm current support | Same import list documented for Community, Pro and Cloud editions, including CSV and KDBX sources |
| Export behavior | Confirm with Passbolt how the export policy is set for cloud tenants, including whether cleartext CSV is allowed | Since Passbolt 5.10, cleartext CSV export is disabled by default and encrypted KDBX is offered unless an administrator re-enables CSV in export policies |
| Upgrades | Passbolt schedules and applies upgrades; confirm release timing, maintenance windows and notice periods in writing | Your team plans and applies upgrades, for example from the v5.16.0 release published September 17, 2026, and tests them before rollout |
| Backups and recovery | Confirm with Passbolt backup frequency, retention, restore testing and who can request a restore | Your team owns database and configuration backups and restore tests; ciphertext remains useless without user keys, so plan key recovery too |
Where ciphertext and metadata live and what that means for compliance
Passbolt is built so the server handles ciphertext rather than readable secrets, which changes what a hosting decision controls. The cards below separate what is encrypted, where it is encrypted, and what evidence each model can give an assessor.
Server stores ciphertext only
Passbolt's documentation states that the server only receives and stores ciphertext. Each user has an OpenPGP key pair, and each user with access to a shared resource receives their own encrypted copy. Whether you run the server yourself or use the cloud-managed edition, the database holds encrypted secrets. Check with Passbolt which fields remain in plaintext in your installed version, and confirm where database backups and replicas are stored.
Encryption happens on the client
Passbolt encrypts and decrypts locally in its browser extension or mobile app, never on the server. The browser extension is cryptographically signed. For a self-hosted deployment, your team controls how the extension is distributed to managed devices, so verify the signature and version on each endpoint. For the cloud-managed edition, confirm how the client software is updated and who can push changes to your users.
Metadata encryption depends on settings
Names, URLs and descriptions are encrypted only with the v5 format and only when the organization enables metadata encryption. Until both conditions hold, an administrator or anyone with database access may see more context than the secret itself. Ask for a written statement of the metadata fields covered by your version and confirm the setting in your tenant or server before loading sensitive records.
Access control and offboarding
Access to a shared resource is granted by creating an encrypted copy for each recipient, so access and key material are tied together. Removing a person from a group does not automatically make every past copy unreadable to that person. Ask how revocation, key rotation and re-sharing work in each model, and document the procedure your offboarding process will follow.
Audit logs and export controls
Syslog activity logs are a Pro feature, so confirm the logging tier you need before choosing an edition. Since Passbolt 5.10, cleartext CSV exports are disabled by default, and KeePass KDBX formats are offered instead, unless an administrator re-enables CSV in the export policies. Record who may change export policies, and where your logs are forwarded and retained.
Evidence for assessments
DeployOpen prepares controls, configuration and evidence for compliance assessments, including the records an assessor will ask for about key handling, access and logging. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. Agree the evidence list in writing before implementation, and confirm with your assessor which artifacts they accept from each hosting model.
How the encryption model works in either hosting model
Hosting location does not change who holds the decryption keys. In Passbolt, each user has an OpenPGP key pair, and the private key stays with that user. When a resource is shared, Passbolt creates a separate copy of the resource for each user with access, encrypted to that user's public key. The Passbolt server receives and stores only ciphertext, so whether the server runs in Passbolt's cloud-managed edition or on your own servers, the server holds encrypted copies it cannot open. Encryption and decryption happen on the user's device, in the browser extension or mobile app. Moving the server into your own infrastructure changes who operates the database, the backups and the TLS endpoint, not who can read a password.
Metadata needs a separate check. Passbolt's documentation says that names, URLs and descriptions are encrypted only with the v5 format and only when the organization enables metadata encryption. Before you assume metadata is protected, confirm the format your instance uses and whether metadata encryption is switched on in your organization settings. Ask Passbolt to confirm how each setting behaves in the edition you are considering, because the answer determines what a database dump or a server-side log reveals in either model.
The browser extension is cryptographically signed, which matters most for self-hosting teams. Whoever distributes the extension to your staff is a trust decision. Verify the signature on the package you deploy, pin the version you approved, and decide whether extensions are pushed through your endpoint management tooling or installed from the vendor store. Record the same check for the mobile app. In either hosting model, a tampered client is the most direct route to your users' secrets, so the client supply chain belongs in your threat model alongside the server.
Which teams gain from self-hosting Passbolt on their own servers
Teams with residency rules, customer contracts that restrict where credentials may sit, or internal policies requiring control over the server hosting shared vaults often gain the most from self-hosting. Passbolt's documentation states that the server only receives and stores ciphertext, and that encryption and decryption happen in the browser extension or mobile app. Metadata such as names, URLs and descriptions is encrypted only with the v5 format and when the organization enables metadata encryption, so the team should confirm that setting before deciding what the server can see.
- Placement control: Self-hosting lets you choose the cloud account, data center or air-gapped network where the database and API server run.
- Installation targets: The hosting guide lists Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux, Oracle Linux 9, openSUSE Leap 15 and SLES 16, Docker, a Helm chart, an AWS AMI and Ansible. Pick the one your audit scope already covers.
- Metadata encryption: Turn on the v5 format and metadata encryption if the server should not read resource names or URLs.
- Backup and key custody: Your team owns database backups, and the server holds only ciphertext, so recovery planning must include user key material.
- Evidence: Auditors will ask who can reach the host, how patches are applied and where logs go. Those answers belong to your environment.
Confirm with Passbolt which metadata and export settings apply to your edition before writing the control narrative.
Platform teams that already run Linux fleets, patch on a schedule and manage configuration with Ansible usually find Passbolt straightforward to fold into existing operations. The hosting guide lists Ansible alongside the supported distributions, so a team can express the install, upgrade and configuration in the same code it uses for other services. The effort is still real: someone owns the operating system, the database, TLS and the upgrade cycle.
- Distribution fit: Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux, Oracle Linux 9, openSUSE Leap 15 and SLES 16 are listed targets, so match the host to your standard image.
- Configuration as code: Ansible is listed in the hosting guide, which lets the install and later changes live in version control.
- Upgrade duty: Passbolt ships releases such as v5.16.0 (September 17, 2026), so plan a regular upgrade window rather than waiting for a crisis.
- Supporting services: Your team maintains the database, reverse proxy, certificates and monitoring that the server depends on.
- Virtual appliance: The virtual appliance is listed for Pro only, so check your edition before assuming it is available.
Ask Passbolt which Ansible roles and versions it recommends for your target distribution, and confirm the upgrade path between releases.
Teams that run workloads on Kubernetes often prefer to deploy password infrastructure the same way, with the official Helm chart and their existing cluster controls. The Passbolt Helm chart is maintained in a public repository under AGPL-3.0, which makes its source inspectable. Running it in your cluster keeps the server inside the same network policies, secrets handling and observability stack as your other services.
- Helm deployment: The chart is listed in the hosting guide and published in the charts-passbolt repository, so review it before adopting it.
- Container option: Docker is also listed, which suits teams that want a simpler single-host footprint before moving to a cluster.
- Cluster responsibilities: Your team owns persistent storage, ingress, certificates, backup of the database and pod security settings.
- Upgrade discipline: Chart versions and application versions move separately, so pin both and test changes in a non-production namespace.
- Scaling questions: Confirm with Passbolt how the chart handles high availability and database replicas for your size of deployment.
Verify the chart version against the application release you intend to run and document who approves Helm upgrades.
Some teams have no appetite for running a password server and want vendor-operated hosting with a clear division of duties. For them the cloud-managed edition removes the need to own the host, patching and database. The trade-off is that the server runs in the vendor's environment, so the team relies on the vendor's operating controls and on the encryption model rather than on physical placement.
- Operational load: The team does not install the operating system, database or application server, which removes those recurring tasks.
- Data placement: The server sits outside your infrastructure, so confirm where the cloud service stores ciphertext and metadata.
- Edition scope: Check which features your plan includes, since Passbolt's pricing comparison lists LDAP provisioning, SSO, MFA policies and SCIM among Pro features.
- Exit planning: Ask how exports work, noting that cleartext CSV exports are disabled by default since Passbolt 5.10 and encrypted KDBX formats are offered.
- Support terms: Get the service levels, backup retention and incident process in writing before signing.
Compare the managed plan's written terms with the self-hosted requirements from your compliance owner before choosing.
What your team runs in each model
Who installs and patches self-hosted Passbolt?
Your team does. In a self-hosted deployment you choose the installation target, which the hosting guide lists as Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux, Oracle Linux 9, openSUSE Leap 15, SLES 16, Docker, a Kubernetes Helm chart, an AWS AMI or Ansible, and you then own the operating system, the web server, the database and the Passbolt application itself. Each of those layers needs its own patch cadence. The Passbolt API server is AGPL-3.0 and the current line is v5.16.0, published September 17, 2026, so your change process should track releases such as that one. Effort rises with the number of layers you maintain and with how many environments you run. Ask Passbolt what the cloud edition patches on its side and how it notifies you of changes that touch your users.
How do version upgrades differ between cloud and self-hosted Passbolt?
Self-hosted upgrades are scheduled by your team, and cloud upgrades are scheduled by the vendor. Under self-hosting you decide when to move from one release to the next, test the upgrade against a copy of your data, and roll back if something fails. Passbolt publishes releases on its GitHub page, so a version you are not running is visible to everyone. Effort grows with the gap between your running version and the current line, because a larger jump means more changes to review. Confirm with the vendor how cloud upgrades are staged, what notice you receive, and whether you can pin a version or delay a release for a period you agree on.
Who owns database and server backups for Passbolt?
In self-hosted Passbolt, your team owns backups of the server and its database, and a restore is only as good as the last test you ran. Passbolt's documentation states that the server only receives and stores ciphertext, so a backup of the database holds encrypted resources and user keys, not cleartext passwords. That lowers the impact of a leaked backup, but it does not remove your duty to protect it, keep it recoverable and document the restore path. Recovery of a lost user key is a separate matter from restoring the server. Ask the cloud vendor what it backs up, how often, where copies are stored, how long they are kept, and how a restore is requested and tested.
What does TLS and availability mean for a self-hosted Passbolt server?
Self-hosted operators issue, install and renew the TLS certificates, and they design the availability layer around the server. Passbolt users reach the server through the browser extension, the mobile app and the web interface, so an expired certificate or a failed node blocks access to shared credentials. Teams often add a load balancer, a second application node or a managed database to reduce downtime, and each addition is another component to operate. The Helm chart route moves some of this into Kubernetes configuration. Confirm with the cloud vendor its availability targets, its maintenance windows and any service level terms in writing, since none are supplied here.
Which monitoring and logging duties stay with the team running Passbolt?
Self-hosted teams own monitoring of the host, the web tier, the database and the Passbolt application logs. The Pro edition includes syslog activity logs, which means that forwarding those events to your own log platform is a configuration task you must complete and test. Without that forwarding, investigating an access question depends on whatever the server keeps locally. Alerting for failed logins, certificate expiry and disk pressure also falls to your team. In the cloud edition, confirm which activity logs you can export, the retention period, and whether you can send them to your own SIEM.
Can self-hosted Passbolt use LDAP and SSO features?
Yes, but those features depend on your server configuration and on the edition you hold. Passbolt's comparison lists LDAP user and group provisioning from AD or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, account recovery and SCIM as Pro features that are not in Community Edition. Self-hosted operators must reach the directory from the server, set the identity provider callbacks, and keep those settings in step with certificate and DNS changes. Each directory or identity provider change becomes a change to test. Before you buy, confirm which of these your chosen cloud edition connects to, and whether the vendor can reach your internal directory or needs a federation path you run.
What drives the effort of running Passbolt yourself?
The main drivers are the number of users, the number of environments, the directory and SSO integrations you enable, and how often your change board requires testing. Effort rises when you add high availability, separate staging copies, or a custom Kubernetes or Ansible pipeline that someone must maintain. It falls when you standardize on one supported operating system and one installation method, and when a documented runbook covers upgrades and restores. Passbolt's Community Edition has unlimited users and no license fee, but staff time, infrastructure and any support contract are still costs you carry. The Pro price is published at $4.9 per user per month billed annually with a 10-user minimum, per Passbolt's pricing page, and it is a recurring cost in either model.
What should I confirm with Passbolt before choosing the cloud edition?
Ask for written answers on these points: which Community and Pro features the cloud edition supports, how LDAP, SSO and SCIM connect to your directory, and where your ciphertext and any encrypted metadata are stored. Also ask how metadata encryption is configured for your organization, since Passbolt documents that metadata is encrypted only with the v5 format and when the organization enables it. Request the upgrade notice period, backup and restore terms, the availability commitment and the exit process for exporting your data. Under the self-hosted model, the matching questions go to your own team and to whichever implementation partner you engage, and DeployOpen can scope that work in a written, fixed-scope plan.
Moving a Passbolt vault between self-hosted and cloud
This sequence gives you a verified inventory of users, groups and shared resources, a confirmed edition match, and a populated target instance where every user can reach the credentials they used before the source is retired.
Inventory users, groups and shared resources
The team lead and the Passbolt administrator list every user, group membership, folder and shared resource on the source instance, and note which resources have multiple owners or restricted access. Export this list to a document outside Passbolt so it stays available during the move. The step is complete when the inventory matches the admin console counts and each group has a named owner who agreed to the plan.
Confirm edition and feature parity
Compare the source and target editions against Passbolt's published pricing comparison, focusing on features your team already depends on, such as LDAP provisioning, SSO, MFA policies, account recovery, SCIM and logging. Ask Passbolt which features the cloud-managed edition supports and whether any policy you rely on must be recreated. The step is complete when you hold a written list of gaps, and each gap has an owner and an agreed workaround or a decision to accept it.
Agree the migration procedure with Passbolt
Ask Passbolt to confirm the supported procedure for moving data between a self-hosted instance and the cloud-managed edition, including what can be carried across, what must be recreated by hand, and whether metadata encryption settings affect the transfer. Record the agreed plan, the cutover window and the rollback conditions in writing. The step is complete when the plan is signed off by the data owner, the security lead and the Passbolt contact.
Export or re-import using supported formats
Run the export from the source using a format the procedure allows, and import it into the target using a supported import format. Passbolt's export documentation states that cleartext CSV exports have been disabled by default since Passbolt 5.10 unless an administrator re-enables them in the export policies, so confirm the policy first and prefer encrypted KeePass KDBX where it fits. Store any export file in restricted, encrypted storage and delete it after import. The step is complete when the import report shows the expected count of resources and no unexplained errors.
Re-verify user key pairs and access
Because Passbolt encrypts with OpenPGP and each user holds their own key pair, every user should sign in to the target, confirm their key works, and open a sample of shared resources they previously accessed. Check that group permissions and resource owners match the inventory from the first step. Passbolt's documentation describes the browser extension or mobile app as the place where decryption happens, so test with the clients your staff actually use. The step is complete when each user has signed off on access to their own resources.
Retire the old instance
Once access is verified, announce a read-only period, take a final backup of the source as your retention policy requires, and then disable user access and decommission the old server or cloud tenant. Remove the export files and any copies of the inventory that contain sensitive detail, and update your backup and monitoring configuration to remove the retired instance. The step is complete when the source is shut down, its backup is stored under your retention rules, and the change record is closed.
What drives the cost of each hosting model
The cost of a cloud-managed Passbolt deployment is mostly a recurring subscription, while the cost of self-hosting is split between recurring staff time and infrastructure and a smaller set of one-time setup costs. The only published Passbolt price is for Pro, at $4.9 per user per month billed annually, with a 10-user minimum and volume discounts after 100 users, according to Passbolt's pricing page. Community Edition has no listed license fee, but it still carries the same infrastructure and labor duties as any self-hosted service. Enterprise and cloud-managed pricing are not published, so ask Passbolt for them directly.
On the self-hosted side, the recurring costs are the people and servers that keep the platform running: patching the operating system and Passbolt releases, maintaining the database and TLS certificates, testing backups and restores, and monitoring availability. Infrastructure choice changes this bill. Passbolt documents installs on several Linux distributions, Docker, a Kubernetes Helm chart, an AWS AMI and Ansible, and a virtual appliance for Pro only, so a team with an existing Kubernetes or Ansible practice will carry a different labor load than one starting from scratch. One-time costs include the initial build, hardening, integration with your directory, and migration of existing credentials.
When you request a quote, ask Passbolt to separate Pro or Enterprise licensing from cloud hosting, state the seat count and the minimum billed, and confirm whether volume pricing applies at your user count. For a self-hosted option, ask for the scope of installation, directory integration, backup and upgrade support, and whether the price is one-time or a retainer. Then model your own internal costs: the hours each month for upgrades and restore tests, the servers in your own accounts, and who on call covers an incident. A quote that leaves these out understates the true cost of self-hosting.
Questions buyers ask before choosing a Passbolt hosting model
Can our team self-host Passbolt without outside help?
Yes, a team with Linux and container skills can install Passbolt itself, because Passbolt documents installation on Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux, Oracle Linux 9, openSUSE Leap 15 and SLES 16, plus Docker, a Kubernetes Helm chart, an AWS AMI and Ansible. The Community Edition is free and lists unlimited users, so licensing alone does not block an in-house install. Outside help is most useful for the work around the install: email delivery, reverse proxy and TLS design, directory or single sign-on integration, tested backups and a written upgrade runbook. Pro features such as LDAP provisioning and SSO add integration work, so scope them before you start. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, under a fixed scope agreed in writing. Check the Passbolt hosting guide against your exact operating system version before you commit to a target.
What drives the effort and cost of self-hosting Passbolt?
Cost falls into one-time work and recurring duties. Software licensing is the first line item: Community is free, while Pro is listed on Passbolt's pricing page at $4.9 per user per month billed annually, with a 10-user minimum and volume discounts after 100 users. Infrastructure, backup storage, patching and upgrade testing recur every month, and staff time is usually the largest ongoing cost. The main drivers are user count, the edition you license, the number of integrations you need, the number of operating systems you support, and how often you upgrade. For the Cloud edition, ask Passbolt for its per-user price and terms in writing, since this page does not state them. For a DeployOpen quote, ask for a written scope that covers installation, integrations, hardening, backup restore testing, upgrade support, documentation, and whether ongoing support is a retainer. DeployOpen does not publish prices, and a quote follows from the written scope.
How long does a Passbolt migration take to complete?
No migration duration is published for Passbolt, so any timeline stays unknown until the work is scoped. Duration depends on how many users and shared resources move, which password manager you import from, how much cleanup the data needs, and whether SSO or LDAP must be ready before go-live. Passbolt's import documentation lists CSV imports from LastPass, 1Password, Dashlane, NordPass, LogMeOnce, Bitwarden, several browsers, and KDBX for KeePass and Keeper, across the Community, Pro and Cloud editions. Since Passbolt 5.10, cleartext CSV exports are disabled by default, so plan an encrypted export path for any future move out of the tool. Ask Passbolt to confirm its current import behavior for your source system. For a DeployOpen timeline, ask for a fixed-scope plan built from a data inventory, a pilot group and a cutover checklist, agreed in writing before work starts.
What does self-hosting Passbolt require from our IT staff?
Self-hosting needs named people who can run a Linux server, manage containers or Kubernetes if you choose those targets, and handle the database, TLS certificates and host patching. Passbolt releases arrive often: v5.14.0 on July 28, 2026, v5.15.0 on August 21, 2026 and v5.16.0 on September 17, 2026, so someone must own upgrade testing and rollout. Backup duties cover the server database and configuration, and restores should be tested on a schedule rather than assumed. Security duties include patching the host operating system, reviewing who holds administrative roles, and monitoring release notes for security fixes. Before go-live, assign a named owner, schedule a restore drill and set a standing upgrade window. If your team lacks this depth, DeployOpen offers ongoing support, upgrades and continuous testing as retainers, under written scope. Release history is available on the Passbolt API releases page.
Does the Passbolt cloud edition still provide end-to-end encryption?
Passbolt's published design describes end-to-end encryption based on OpenPGP, and that design is the baseline to verify for any hosting model. Each user has a key pair, and each shared resource is encrypted separately for every user who has access. Encryption and decryption happen in the browser extension or mobile app, and the server only receives and stores ciphertext. The browser extension is cryptographically signed, which lets you verify what runs on user devices. For the Cloud edition specifically, confirm in writing that the same client-side encryption applies. Also confirm whether metadata encryption is enabled for your organization, since Passbolt's documentation says metadata such as names, URLs and descriptions is encrypted only with the v5 format and when the organization enables it. Ask how key recovery works and which operational data, such as logs, Passbolt holds.
Does self-hosting Passbolt change which features are available?
Feature access follows the edition you license, and the pricing comparison lists paid features separately from hosting. Passbolt's pricing comparison lists these as Pro features that Community Edition does not include:
- LDAP user and group provisioning from AD or OpenLDAP
- Account recovery
- SSO with Microsoft, Google, OpenID and AD FS
- MFA policies
- Syslog activity logs
- Tags, passphrase and password policies, password expiry policy and SCIM
Community Edition is free with unlimited users, while Pro is listed at $4.9 per user per month billed annually with a 10-user minimum. Before you choose a model, confirm with Passbolt whether each Pro feature works the same way in your chosen deployment, and whether the Cloud edition includes the same Pro set. Ask for that answer in writing, along with the terms for self-hosted Pro licensing, so your scope and budget reflect the exact feature list you need.
Where do ciphertext and metadata live in each hosting model?
In self-hosted Passbolt, you choose where the server and database run, so ciphertext and any operational data stay in infrastructure you control. In the Cloud edition, Passbolt runs the server, so the question becomes where it stores the same data and who can reach the hosts. In both models, Passbolt's documentation states that the server only receives and stores ciphertext. Metadata such as names, URLs and descriptions is encrypted only with the v5 format and when the organization enables metadata encryption, so check that setting before you import any credentials. For each option, ask for the storage location, backup location and retention period, the people with administrative access to the host, and how logs are kept. For a self-hosted build, add disk encryption, backup encryption and access logging to your own control list. Those answers form the core of a data flow diagram your security team can review.
How DeployOpen scopes, delivers and supports self-hosted Passbolt
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so self-hosted Passbolt is the case we work on directly. We agree scope, deliverables and timelines in writing before work starts, and the steps below follow that written scope.
How we scope
- Confirm which installation target you run, such as a Debian, Ubuntu, RHEL-family or SUSE host, Docker, Kubernetes or AWS.
- Record who owns the database, mail relay, TLS certificates, backups and the directory connection before any work starts.
- Agree in writing whether the scope includes LDAP provisioning, SSO, MFA policies and metadata encryption settings.
- Ask the quote to name each deliverable and the acceptance test for it, so the boundary of the work is clear.
How we build
- Deploy Passbolt in your cloud account, data center or air-gapped network using the installation path agreed in scope.
- Configure the server, database, reverse proxy, email delivery and directory integration against your own standards.
- Test user enrollment, key generation, sharing, recovery and the import and export policies your teams will actually use.
- Harden the host and web tier, and document the configuration that governs where ciphertext and metadata are stored.
How we hand over
- Deliver runbooks for upgrades, backups, restores and rotation of server-side keys in your own environment.
- Walk your administrators through the admin console, the policy settings and the procedures that affect user key material.
- Provide written documentation of the architecture, data flows and evidence your compliance team can reuse in assessments.
- Confirm with your team which operational tasks stay in-house and which move to a retainer after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Plan upgrades against the Passbolt release notes on the official releases page before each change window.
- Review backup and restore results on a schedule agreed in the retainer, so recovery is tested rather than assumed.
- Ask any provider, including DeployOpen, to state in writing which versions, hosts and tasks the support covers.
