Self-Hosting Passbolt: Open Source Password Management for Teams

Most password managers are designed for individuals. You pick one, store your passwords, and that's it. But when you're managing shared credentials across a team — staging server passwords, API keys, shared service accounts — individual vaults don't cut it.

Photo by Mamur Saitbaev on Unsplash

Passbolt is an open source, self-hosted password manager built specifically for team credential sharing. It uses GPG encryption end-to-end, meaning the server never sees plaintext passwords, and sharing is cryptographically enforced per-user.

Passbolt vs. Vaultwarden vs. Bitwarden: When to Use What

When to choose Passbolt

• You need team credential sharing with real end-to-end encryption. Passbolt's GPG model means sharing a password with a teammate encrypts it specifically for their key. The server is a relay, not a trust boundary.
• Your team needs audit trails. Who accessed what, when, and who shared which credential — Passbolt tracks this.
• You're in a compliance-sensitive environment. The GPG model is easier to explain to auditors than "we trust the server."
• You don't need mobile apps. Passbolt Community Edition's main limitation is the lack of official mobile apps.

When to choose Vaultwarden instead

• You're a single user or small family. Vaultwarden with the Bitwarden client apps is simpler for personal use.
• You need mobile apps. Bitwarden's mobile apps are mature and well-tested.
• You want the Bitwarden ecosystem. Desktop apps, CLI, browser extensions — the Bitwarden client ecosystem is larger.

How Passbolt's Encryption Works

Passbolt doesn't rely on a master password that the server validates. Instead:

1. Each user generates a GPG keypair during account setup.
2. The private key is encrypted with the user's passphrase and stored on the server (encrypted).
3. When you save a password, it's encrypted with your public key.
4. When you share a password, Passbolt re-encrypts it with the recipient's public key.
5. The server never sees plaintext. Even a compromised database only contains GPG-encrypted blobs.

This is a fundamentally different trust model from Bitwarden/Vaultwarden, where the server handles key derivation. In Passbolt, you could theoretically replace the server and still decrypt your data with your GPG key.

Self-Hosting Passbolt: What You Need

Server requirements

• CPU: 1+ core (2 recommended for larger teams)
• RAM: 1 GB minimum, 2 GB recommended
• Storage: 1 GB for the application, plus database
• Database: MySQL 8.0+ or MariaDB 10.4+
• Web server: Nginx or Apache (Passbolt ships with its own config)
• PHP: 8.1+ with required extensions
• HTTPS: Required (Passbolt refuses to run without TLS)

Docker setup

The easiest way to deploy Passbolt is with Docker Compose:

version: "3.9"
services:
  db:
    image: mariadb:10.11
    environment:
      MYSQL_DATABASE: passbolt
      MYSQL_USER: passbolt
      MYSQL_PASSWORD: your-db-password
      MYSQL_ROOT_PASSWORD: your-root-password
    volumes:
      - db_data:/var/lib/mysql

  passbolt:
    image: passbolt/passbolt:latest-ce
    depends_on:
      - db
    environment:
      APP_FULL_BASE_URL: https://pass.yourdomain.com
      DATASOURCES_DEFAULT_HOST: db
      DATASOURCES_DEFAULT_DATABASE: passbolt
      DATASOURCES_DEFAULT_USERNAME: passbolt
      DATASOURCES_DEFAULT_PASSWORD: your-db-password
      EMAIL_DEFAULT_FROM: [email protected]
      EMAIL_TRANSPORT_DEFAULT_HOST: smtp.yourdomain.com
      EMAIL_TRANSPORT_DEFAULT_PORT: 587
      EMAIL_TRANSPORT_DEFAULT_USERNAME: your-smtp-user
      EMAIL_TRANSPORT_DEFAULT_PASSWORD: your-smtp-password
    volumes:
      - gpg_data:/etc/passbolt/gpg
      - jwt_data:/etc/passbolt/jwt
    ports:
      - "443:443"
      - "80:80"

volumes:
  db_data:
  gpg_data:
  jwt_data:

After starting the containers, create your first admin user:

docker exec passbolt su -m -c \
  "/usr/share/php/passbolt/bin/cake passbolt register_user \
   -u [email protected] -f Admin -l User -r admin" -s /bin/sh www-data

This outputs a URL to complete registration in your browser, where you'll generate your GPG key and install the browser extension.

Email is not optional

Unlike many self-hosted tools where email is a nice-to-have, Passbolt requires a working SMTP configuration. Account invitations, password sharing notifications, and account recovery all go through email. Make sure your SMTP is configured before inviting team members.

Day-to-Day Usage

Browser extension (required)

Passbolt uses a browser extension for all cryptographic operations. The extension:

• Stores your encrypted private key locally
• Handles GPG encryption/decryption client-side
• Auto-fills credentials on websites
• Lets you generate and save new passwords

This is different from Bitwarden, where the extension is convenient but optional (you can use the web vault). In Passbolt, the extension is the primary interface.

Sharing credentials

To share a password with a teammate:

1. Open the password entry
2. Click "Share"
3. Select users or groups
4. Choose permission level (read-only, update, or owner)

Behind the scenes, Passbolt re-encrypts the secret with each recipient's GPG public key. The recipient's extension decrypts it with their private key.

Folders and tags

Passbolt supports:

• Folders for organizing credentials by project, team, or service
• Tags for cross-cutting categorization
• Groups for bulk sharing (e.g., share everything in "Production" with the ops team)

What Passbolt Can't Do (Yet)

• No official mobile apps in Community Edition. The Pro edition has mobile apps, but CE users are limited to the browser extension.
• No offline access. You need connectivity to the server to decrypt passwords.
• No TOTP/2FA storage. Passbolt stores passwords, not TOTP tokens. Use a separate app for 2FA codes.
• No file attachments in Community Edition. Pro supports encrypted file attachments.
• No emergency access. If a user loses their private key and recovery isn't set up, their passwords are gone.

Backups

Passbolt backups need three things:

1. Database dump — All metadata and encrypted password blobs
2. GPG server keys — The /etc/passbolt/gpg/ directory
3. JWT keys — The /etc/passbolt/jwt/ directory (for API authentication)

# Database backup
docker exec passbolt-db mysqldump -u root -p passbolt > passbolt-backup.sql

# Volume backup
docker run --rm -v passbolt_gpg_data:/data -v $(pwd):/backup \
  alpine tar czf /backup/gpg-backup.tar.gz -C /data .

Because passwords are GPG-encrypted, a database dump alone is useless without the corresponding private keys. This is a security feature, but it means your backup strategy needs to account for key material.

Bottom Line

Passbolt is the right choice when you need cryptographically-enforced credential sharing across a team. The GPG model is more complex than Bitwarden's approach, but it provides stronger guarantees about who can access what.

For personal use, Vaultwarden is simpler. For team use where you want real end-to-end encryption and audit trails, Passbolt is the better fit.

The Community Edition is genuinely usable — the main limitation is the lack of mobile apps. If your team primarily works from laptops with browser extensions, that's not a dealbreaker. If mobile access is critical, look at the Pro edition or consider Vaultwarden with Bitwarden organizations as an alternative.