# AliasVault: a self-hosted password manager that generates email aliases > AliasVault combines a password vault with a built-in email server so every account can get its own random address. It is AGPL-3.0, Docker-based, and aimed at people who would rather run the server than trust a cloud host. **aliasvault/aliasvault** — Privacy-first password manager with built-in email aliasing. Fully encrypted and self-hostable. - Repository: https://github.com/aliasvault/aliasvault - Website: https://www.aliasvault.com - Stars: 3,146 · Forks: 108 - Language: TypeScript - License: AGPL-3.0 - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/aliasvault-aliasvault ## The problem AliasVault solves: one address per account Signing up for a service normally hands over two things you cannot take back: a password you might reuse, and an email address that becomes a permanent identifier. AliasVault attacks both at once. The README describes it as a "privacy-first password and email alias manager" that creates "unique identities, strong passwords, and random email aliases for every website you use." The audience is narrower than a general password manager's. Anyone can use a vault. AliasVault is for people who want the alias to be generated and received by the same system that stores the credential, rather than stitching together a password manager plus a separate forwarding service. The README states the project has "zero third-party dependencies," which is the design claim doing the most work here: no external alias provider sees your mail, and no external identity provider sees your vault. The trade-off is immediate. A cloud password manager asks you to trust one company. AliasVault asks you to run a mail server. That is a different category of operational commitment, and it is the first thing to weigh. ## How the encryption and the built-in email server fit together The repository is a multi-service stack rather than a single binary. docker-compose.yml defines five services: postgres, client, api, admin, and reverse-proxy. The client and api containers are only exposed internally on ports 3000 and 3001; the admin container sits on 3002; only reverse-proxy publishes ports to the host, mapped from ${HTTP_PORT:-80} and ${HTTPS_PORT:-443}. That layout tells you the intended topology: everything behind one TLS terminator. The api and admin containers both depend on postgres with condition: service_healthy, and the postgres service runs pg_isready -U aliasvault as its healthcheck on a 5s interval. Data persists through bind mounts: ./database/postgres for the database, ./database and ./logs for the application containers, and ./secrets mounted read-only at ${SECRETS_PATH:-/secrets}. The topics list names argon2id and srp, which points at how credentials are handled: SRP for the authentication exchange and Argon2id for key derivation. The README says sensitive data is "encrypted end-to-end," and points to a security architecture diagram under docs/static/assets/diagrams/security-architecture/. That diagram is where the actual key hierarchy lives. The README itself does not spell out the derivation path, so if you are evaluating the cryptography rather than the feature list, the diagram and ARCHITECTURE.md are the documents to read, not the README. The email side is the part with no equivalent in most vaults. AliasVault ships its own SMTP container, which is why .env.example exposes SMTP_PORT=25 and SMTP_TLS_PORT=587 alongside the HTTP ports. Aliases are not forwarded through a vendor; the stack receives the mail itself. ## Installing AliasVault with the install script or Docker Compose The README documents two paths. The install script is described as the "Managed solution with automatic SSL (recommended for VPS/cloud)"; Docker Compose is the "Single container with manual setup for use with existing SSL infrastructure (NAS, homelab)." Stated requirements are 1 vCPU, 1GB RAM, 16GB disk, Docker 20.10 or later, and 64-bit Linux. The quick start downloads the script, marks it executable, and runs the install subcommand. According to the README, this creates the .env file, pulls the Docker images, and starts the containers. ```bash curl -L -o install.sh https://github.com/aliasvault/aliasvault/releases/latest/download/install.sh chmod +x install.sh ./install.sh install ``` If you go the manual route, .env.example is the configuration surface. The file's own header recommends the script instead, noting that it "will automatically set all of the following variables for you and allow you to easily change them later via the CLI." The keys you are most likely to touch are the ports and the secrets location. ```bash HTTP_PORT=80 HTTPS_PORT=443 SMTP_PORT=25 SMTP_TLS_PORT=587 FORCE_HTTPS_REDIRECT=true SECRETS_PATH=/secrets ``` FORCE_HTTPS_REDIRECT defaults to true, so plain HTTP on port 80 is redirected. SECRETS_PATH is documented as something to change only on a duplicate mount conflict, which is the kind of problem Docker orchestrators produce. The file also notes that after changing settings you must restart all AliasVault containers. A first real use is unglamorous: after the stack is up, open the web app through your reverse proxy, create the account, and add one site. The alias is generated as part of that entry, and mail sent to it arrives through the SMTP container rather than a forwarding provider. The README does not walk through this flow step by step; the docs site does. ## Where AliasVault is the wrong tool Running your own inbound mail is the limitation that matters most, and it is structural rather than a missing feature. Port 25 is blocked outbound by a large number of VPS and residential providers to limit spam. If yours is one of them, the built-in email server cannot receive aliases, and you have taken on the operational weight of the whole stack for a vault you could have run far more cheaply. The README lists no fallback to an external SMTP relay, so this is not something you configure around within the documented surface. The hardware floor is modest but real: 1GB RAM and 16GB disk, with five containers including PostgreSQL. On a NAS or a small homelab box that is fine. On a shared host where you do not control the firewall, it is not. The project is also committed to a single deployment shape. The Compose file is opinionated: fixed internal ports, a bundled PostgreSQL image from ghcr.io/aliasvault/postgres, and secrets read from a directory on disk. If your organisation requires an external managed database or an existing identity provider for admin access, there is no documented path to substitute either. Finally, the README does not document rollback. There is an install script with an install subcommand, and the .env.example header mentions updating to a newer version through the CLI, but downgrade behaviour and database migration reversibility are not described. Anyone running this in front of real accounts should establish that themselves before upgrading. ## AliasVault compared with Vaultwarden, Bitwarden and SimpleLogin The comparison people actually search for is Vaultwarden, and the difference is architectural rather than a feature checklist. Vaultwarden is a lightweight reimplementation of the Bitwarden server API. You run it, point the official Bitwarden clients at it, and you get a password vault with an existing client ecosystem. It does not generate email aliases and it does not receive mail. Bitwarden itself is the managed version of that same protocol, with the server run by someone else. It offers an alias integration in some tiers, but the alias provider is a separate service and the vault is not yours to host in the same way. SimpleLogin is the inverse trade. It is an email alias service, not a password manager. You get aliases and forwarding, and you keep your existing vault. AliasVault's claim is that combining the two removes a third party from both halves: the vault is on your hardware, and the alias mail lands on your hardware. That combination is the whole pitch, and it is also the whole cost. Choosing Vaultwarden means you never think about SMTP. Choosing SimpleLogin means you never think about PostgreSQL. Choosing AliasVault means you think about both, and in exchange no vendor holds either your credentials or your alias traffic. If you are not prepared to operate a mail-receiving container, the comparison resolves against AliasVault regardless of how the vault itself performs. ## Licence, maintenance and what an upgrade costs you AliasVault is licensed under AGPL-3.0. If you self-host it for yourself, the practical effect is close to any other open source licence. The network copyleft matters if you modify the code and let other people interact with it over a network: the AGPL's source-availability obligation attaches to that use. Running the published container images unmodified is the ordinary case and does not raise that question. This is a description of the licence text, not legal advice; if you plan to embed AliasVault in a product, read LICENSE.md and TRADEMARKS.md, the latter being a file most projects do not ship. Maintenance looks current. The repository is not archived, and the last push was on 2026-09-23. Releases are frequent and small: 0.30.5 on 2026-09-05, 0.30.6 on 2026-09-15, 0.30.7 on 2026-09-16. That cadence is a signal about release process, not about security, and it cuts both ways. Frequent patch releases mean fixes arrive quickly, and they also mean you are expected to upgrade often. The install script is the documented mechanism for that, which is one reason the .env.example header pushes you toward it over hand-editing the file. The upgrade cost is mostly the database. The api and admin containers mount ./database read-write and depend on a healthy postgres, so a version bump that changes schema is a migration against your live vault. Back up the ./database and ./secrets directories before running an update. The secrets directory holds the postgres password, the JWT key and the data protection certificate password according to .env.example, and losing it is not a recoverable state documented anywhere in the README. ## Conclusion Adopt AliasVault if you want password storage and alias generation behind one Docker stack you control, and you accept running an SMTP container on port 25. Skip it if you want a managed service with no mail infrastructure, or if you only need a browser extension talking to someone else's backend. Before committing, verify that your host allows outbound port 25 and that the install script's generated secrets are backed up, because the postgres password, JWT key and data protection certificate live in the secrets directory that docker-compose.yml mounts read-only. ## FAQ ### Is AliasVault safe to use? The README states that all sensitive user data is encrypted end-to-end and that the project has zero third-party dependencies, and the repository topics list argon2id and srp for credential handling. The detailed key architecture is published as a diagram under docs/static/assets/diagrams/security-architecture/ rather than in the README, so that is the document to review if you are judging the cryptography. ### How does AliasVault compare with Bitwarden? Bitwarden is a password manager with clients and a server that someone else operates, while AliasVault is self-hosted and adds a built-in email server that receives aliases. The README positions AliasVault as a privacy-first alternative to traditional and closed-source password managers, and its Compose file runs the vault, the database and the mail path on your own hardware. ### What is the best free email alias service? AliasVault is not a standalone alias service; it bundles alias generation with a password vault and its own SMTP container, so aliases are received by the stack you host rather than forwarded by a vendor. The README lists no pricing for the self-hosted version, and the cloud version at app.aliasvault.com is a separate offering. ### What are the risks of using an alias? The README does not discuss alias-specific risks. What it does state is that alias mail is received by AliasVault's own SMTP container rather than a third-party forwarder, so the address and the messages stay inside the stack you operate. Any risk beyond that is not addressed in the README. ### Which password managers have never been hacked? The README makes no claim about breach history for AliasVault or any other manager, and it lists no independent audit. What it does describe is the security model: sensitive data encrypted end-to-end, argon2id and srp among the repository topics, and a published security architecture diagram. That is a design description, not a track record. ## Sources - [aliasvault/aliasvault on GitHub](https://github.com/aliasvault/aliasvault) - [License: AGPL-3.0](https://github.com/aliasvault/aliasvault/blob/main/LICENSE) - [Project website](https://www.aliasvault.com) - [README](https://github.com/aliasvault/aliasvault/blob/main/README.md) - [Releases](https://github.com/aliasvault/aliasvault/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aliasvault-aliasvault