AliasVault

Last reviewed Sep 13, 2026 · 976 words

AliasVault is two products in one stack, and only one of them is easy. The password vault is a zero-knowledge, end-to-end encrypted store with browser extensions and mobile apps, and it runs fine on 512 MB of RAM with almost no care. The email alias side is a real SMTP server that has to receive mail from the public internet on port 25, which means a domain, MX records, an open inbound port, and a reverse DNS entry your provider may not give you. Decide before you install whether you want the second half, because it determines where this thing can live.

The vault half competes with Vaultwarden and mostly loses on maturity

On encryption AliasVault is doing the right things: the vault is encrypted client-side with a key derived from your master password, the server never sees plaintext, and login uses a password-authenticated key exchange rather than sending a hash. That is the same broad model as Bitwarden. What it does not have is a decade of client polish. Extensions cover Chrome, Firefox, Edge and Safari and apps exist for iOS and Android, but autofill is less reliable on awkward forms than the Bitwarden clients, there is no shared-collection model worth mentioning, and the project only started in 2024. At 3,074 stars it is a young AGPL-3.0 codebase moving quickly, which is a compliment and a warning in the same breath.

If passwords are all you want, Vaultwarden is the safer pick by a wide margin, and the password managers category lists the rest. AliasVault earns its place only when the alias feature matters to you.

The alias half is why you would run it

The pitch is the SimpleLogin one: every sign-up gets its own generated address, mail to that address lands in a mailbox inside your vault, and when a service leaks or spams you, you delete the alias instead of changing your real email everywhere. AliasVault's twist is that the alias and the credential live in the same encrypted record, so the login for a site and its throwaway email are one object. That is nicer than juggling a password manager and a separate alias service, and it is why people who own a domain pick this over the SimpleLogin route.

Two things make the self-hosted version harder than the hosted one. First, you bring your own alias domain, and it needs an MX record pointing at the AliasVault host plus TCP 25 open inbound. Many residential ISPs block 25, and several cheap VPS providers want a support ticket before opening it. Second, aliases are receive-only in the way most people use them: this is not a full mail server with a sending reputation, and replying from an alias is not the polished experience a paid alias service gives you.

Installing is a script, and that script hides a lot

The documented path is a one-line installer from the repository that fetches a docker-compose stack: the web client, the API, an admin panel, a database, and the SMTP listener, all behind a bundled reverse proxy that handles 80 and 443. It works, and it asks the right questions on first run. The thing to understand is that the installer is the supported route; hand-rolling your own compose file from the images is possible but you are then responsible for keeping five services' versions in step with each other on every update.

Before you run it, have ready: a hostname for the web UI with DNS already pointing at the box, the alias domain with its MX record, and a decision on TLS. The installer can fetch Let's Encrypt certificates itself; if you already run Caddy or Traefik you will need to disable that and terminate TLS upstream, and the docs for that path are thinner.

Backups mean the database plus the encryption keys

Because the server stores ciphertext, a backup is only useful together with the master password that decrypts it, and the email side stores received mail in the same database. Dump the database container nightly and copy the volume that holds server keys and configuration; losing the keys while keeping the database gets you an instance that will not accept logins. Test a restore into a scratch stack once before you trust it, the same discipline the Vaultwarden guide preaches. The clients cache the vault locally, so a server outage is inconvenient rather than immediately catastrophic, but alias mail arriving during an outage bounces.

Who should actually run this

You, if you own a spare domain, run a VPS where port 25 is open, are comfortable being your own mail admin at a small scale, and want aliases and credentials in one encrypted place. Not you, if this would be your first password manager, if your server sits behind a home connection, or if you are not prepared to update a fast-moving project every few weeks and read the release notes when you do. Difficulty is honestly rated Medium; the vault alone is Easy, the mail side is what pushes it up.

What I'd do

For most households I would still deploy Vaultwarden for passwords and treat aliases as a separate decision. If aliases are the point, I would put AliasVault on a small VPS with confirmed inbound port 25, a dedicated alias domain rather than my main one, the installer's own TLS handling left alone, and a nightly database dump shipped off-box. I would run it for a month alongside my existing password manager before moving anything important across, and I would not migrate a family onto it yet. Another year of releases may soften that advice; today it is a strong idea with a young implementation.