How it works
DPVault is a zero-knowledge password manager: the server stores your data, syncs it across your devices, and backs it up — but it holds no key that can open it. Everything is encrypted on your device before it is sent, and decrypted only after you unlock.
Signing in runs your master password through Argon2id on your device to derive two keys: an encryption key that never leaves the device, and an authentication value sent to the server that cannot be turned back into your password. The server never sees the password itself.
Every item is encrypted with XChaCha20-Poly1305 under a random vault key, which is itself wrapped by your encryption key. What reaches the server is opaque ciphertext. Changing your master password re-wraps that one key — your items are never re-encrypted or exposed.
Your vault lives in an encrypted store on each device and works fully offline. Changes sync by a monotonic sequence when you reconnect, with conflicts surfaced rather than silently overwritten.
A shared folder's key is sealed individually to each member's public key with X25519 sealed boxes. Only that member's device can open their copy; the server relays the sealed key but can never read it.
Unlock and recovery
Beyond the master password, a vault can be opened with a hardware security key (YubiKey) or built-in biometrics — Face ID, Touch ID, Windows Hello, or a fingerprint reader — over the FIDO2 / WebAuthn standard. A secret that never leaves the authenticator wraps a second copy of the vault key; the server keeps only public handles it cannot use. If an organisation opts in, a nominated recovery administrator can issue a one-time code to restore access to a forgotten password.
One core, every client
The desktop apps (macOS, Windows, Linux), the web app, the browser extension, iPhone, and the separate admin console all run the same cryptography core — so an item written by one client is always readable by the others, and the security model is identical everywhere.
Record types
Every record is stored the same way — encrypted end to end — but each type has a purpose-built editor. All processing happens on your device; the server only ever sees ciphertext.
Username, password, website, and a built-in TOTP authenticator. Superseded passwords are kept as history, and each record has its own access activity.
Rich markdown notes and code snippets with syntax highlighting, sanitised so a shared note can never run code in your app.
Application secrets and access tokens, with the endpoint, environment, and expiry alongside the generated secret.
Card details rendered as a virtual card, with automatic brand detection and masked number, CVV, and PIN.
Account and routing numbers, IBAN, and SWIFT/BIC — the sensitive fields masked by default.
Store the certificate, private key, and chain; validate a certificate's details, and convert between PEM, DER, PFX/P12, and CA bundle — all on your device, with each reveal, download, and conversion recorded for chain-of-custody.
Single sign-on & SCIM
One OpenID Connect connector serves both Microsoft Entra ID (Microsoft 365) and Okta, and SCIM 2.0 handles automatic provisioning. You configure both per organisation in the admin console's Identity tab.
Because the server never holds a key that can open a vault, an identity provider cannot hand one over. After signing in with SSO, the vault still opens with your master password or an approved passwordless method. SCIM therefore provisions shell accounts that gain a vault at first sign-in; deprovisioning withdraws access immediately.
How sign-in resolves
Each organisation claims one or more email domains. A sign-in is routed by the user's email domain to that organisation's provider, so several organisations can use different identity providers on one deployment. An organisation can also enforce SSO, which blocks master-password login for its members entirely.
The values DPVault gives you
Wherever a provider asks for a redirect URI or a SCIM endpoint, use these. The admin console shows the exact URLs for your deployment — the forms below use <your-server> as a stand-in.
Microsoft 365 (Entra ID)
Connect Microsoft 365 sign-in and provisioning through Microsoft Entra ID (formerly Azure AD).
Single sign-on
- In the Entra admin centre, go to App registrations → New registration.
- Add a Web redirect URI using the callback URL DPVault shows in the Identity tab.
- Copy the Application (client) ID into the Client ID field in DPVault.
- Certificates & secrets → New client secret, then copy the value into DPVault.
- From Overview → Endpoints, copy the OpenID Connect metadata document URL and paste it as the issuer — without the trailing /.well-known/openid-configuration.
- Set the provider to Microsoft Entra ID, enable single sign-on, and save.
Automatic provisioning (SCIM)
- In Enterprise applications, open your app and go to Provisioning.
- Set Provisioning Mode to Automatic, then set the Tenant URL to the SCIM base URL and the Secret Token to a token you generate in DPVault's Identity tab.
- Test the connection, then assign the users and groups that should be provisioned into the organisation.
Okta
Connect Okta sign-in and provisioning through an OIDC web application.
Single sign-on
- In the Okta admin console, go to Applications → Create App Integration → OIDC → Web Application.
- Add the Sign-in redirect URI DPVault shows in the Identity tab.
- Copy the Client ID and Client secret into DPVault.
- Use your Okta org URL (e.g. https://your-org.okta.com) as the issuer, or a custom authorization server's issuer URL.
- Set the provider to Okta, enable single sign-on, and save.
Automatic provisioning (SCIM)
- On the application's Provisioning tab, choose Configure API Integration and enable it.
- Paste the SCIM base URL and a token generated in DPVault's Identity tab as the API token.
- Enable Create, Update, and Deactivate users, then assign people to the app.
DPVault normalises the differences between providers — such as how each formats SCIM operations, and how Entra sometimes omits the email attribute (falling back to the user principal name). You don't need to special-case anything.
Admin console operations
A separate desktop application for operators and organisation administrators. It signs in with its own account (single sign-on supported) and manages everything below.
The console manages tenants, users, groups, folders, policies, and single sign-on — but it cannot read anyone's vault. A vault opens only with a key administrators do not hold. Managing an organisation and reading its secrets are deliberately two different things.
Run a tree of organisations — the operator root, child organisations beneath it, a Public catch-all for unaffiliated and personal accounts, and lightweight family organisations. Each standard organisation owns one or more email domains that route its signups; you can claim a domain's Public accounts and move users between organisations you manage.
Four roles — Root Admin, Tenant Admin, Admin, User — plus delegated per-resource permissions for non-admins. Suspend or reactivate accounts, approve new devices, and issue account-recovery codes where recovery is enabled.
Manage directory groups per organisation and create shared folders, assigning each member a role — read, write, or manager — with typeahead search that scales to thousands of users.
Set organisation policy: minimum master-password length, a password-generator floor, an auto-lock cap, and who may create shared folders. Clients fetch and enforce these at sign-in.
Opt in to a nominated recovery administrator (members escrow a spare copy of their vault key to that admin), and allow single sign-on alone to open the vault via an approved device key. Both are off by default and stated plainly to the people affected.
An append-only audit of security-relevant events — sign-ins, account and folder lifecycle, membership changes, and client-reported password reveals/copies and certificate operations — filterable and newest-first. It records labels and counts, never decrypted secrets.
Hosting options
DPVault is a small Go server backed by PostgreSQL. Because the design is zero-knowledge, whoever hosts it stores only ciphertext — the operator can run it without ever being able to read a vault.
| Option | What it is | Best for |
|---|---|---|
| Self-hosted | The server + PostgreSQL in Docker, behind your own TLS reverse proxy. | Full control, on your own infrastructure. |
| Azure | Container Apps + Azure Database for PostgreSQL Flexible Server + Key Vault, provisioned by infrastructure-as-code. | A managed cloud footprint that scales. |
| Managed | The hosted instance at vault.dpnex.us. | Trying it out with nothing to run. |
Self-hosted with Docker
Run the server container alongside PostgreSQL 16 and put a reverse proxy (Caddy, Traefik, or Nginx) in front to terminate TLS. Database migrations apply automatically on boot. Configure it entirely through environment variables:
The first configured admin email becomes a Root Admin on first sign-in, from which you create organisations and appoint other administrators.
Azure
An infrastructure-as-code definition (Azure Developer CLI + Bicep) provisions Azure Container Apps for the server, Azure Database for PostgreSQL Flexible Server for storage, Key Vault for secrets, and a container registry — with economical defaults and redundancy toggles you can turn up for production.
The server stores wrapped key material and encrypted item blobs. It cannot derive a master password, unwrap a vault key, or read an item — no matter who operates it. Hosting choice is about availability and control, not about who can read your data.