DEV Community

Cover image for I Replaced Proton Pass with a Self-Hosted Password Manager + Private Email Aliases
PyHackSecGP
PyHackSecGP

Posted on

I Replaced Proton Pass with a Self-Hosted Password Manager + Private Email Aliases

Why I wrote this: Every "privacy guide" online ends with "use a password manager." None of them tell you what to do when your email address itself is the breach vector. This is how I fixed both.


The Problem Nobody Talks About

Every breach notification I've ever received had one thing in common: my real email address was in the dump.

Password reuse is the obvious villain — but your email address is the silent one. It's your username on 40 sites. It's how attackers correlate your accounts across breaches. It's permanent.

I wanted a setup where:

  • Every new account gets a unique alias that routes to my real inbox
  • Every new account gets a unique password generat
  • Nothing is stored on someone else's server
  • The whole thing costs under $5/month

Here's what I built.


The Stack

Layer Tool Cost
Password vault Vaultwarden (self-hosted) ~$0 (ru
Email aliasing Addy.io ~$1/month (Lite plan)
Custom domain Your registrar ~$1-2/month amortiz
Email receiving Proton Mail Free tier

Architecture

New signup →
Bitwarden browser extension generates alias via Addy
Bitwarden generates unique password
Alias routes: yourname+shop123@yourdomain.com → secr
You never expose your real address

Every account gets:

  • A unique alias (adjective-noun-1234@yourdomain.com
  • A unique 20+ char password
  • Zero connection to your real email

Step 1 — Set Up Addy.io with a Custom Domain

  1. Register a cheap domain (.com works, .io is ove
  2. Add it to Addy.io as a custom domain
  3. Point the domain's MX records to Addy.io's mail ser
  4. Add SPF, DKIM, and DMARC records for email authentication

The DNS records matter. Without DMARC enforcement, your aliases can be spoofed. Set p=quarantine initially, then move to p=reject once
you confirm legitimate mail flows correctly.


Step 2 — Configure the Catch-All

In Addy.io, enable a catch-all on your custom doma

  • anything@yourdomain.com routes to your Proton inbo
  • You don't need to pre-create aliases — just use shop-name@yourdomain.com and it works immediately
  • You can block or delete any alias that starts gettin

Set your catch-all recipient to a **dedicated Proton i Keep the real address completely out of the loop.


Step 3 — Connect Bitwarden to Addy.io

In Bitwarden (or Vaultwarden) settings:

`Settings → Generator → Username generator → Forwarded

Paste your Addy.io API key. Set your custom domain.

Now when you create a new login in Bitwarden, hit the he username field — it calls the Addy.io API, creates areal alias on the fly, and populates the field. No copy-paste. No manual alias creation.


Step 4 — Self-Host Vaultwarden

Vaultwarden is an open-source Bitwarden-compatible server. Docker Compose setup:

`yaml
services:
vaultwarden:
image: vaultwarden/server:latest
restart: unless-stopped
environment:
DOMAIN: "https://vault.yourdomain.com"
SIGNUPS_ALLOWED: "false"
volumes:
- ./vw-data:/data

Put it behind a reverse proxy (Traefik, Caddy, or nginowser extension connects to it identically to the cloudversion.


What I Got

  • Alias per site — when shop-abc123@yourdomain.com getich site sold my data
  • Zero email exposure — my real address doesn't exist in any vendor's DB
  • Auto-generation — alias + password created in one cl
  • Full self-hosted control — vault on my hardware, no subscription for the vault itself

Cost breakdown:

  • Domain: ~$15/year
  • Addy.io Lite: $12/year
  • Vaultwarden: $0 (already running homelab)
  • Total: ~$27/year (~$2.25/month)

What Would You Add?

I'm debating two upgrades:

  1. Webhook on new alias creation → log to my SIEM for
  2. Auto-disable aliases that receive breach notification emails

What's your aliasing/vault setup? Running something similar, or a totally different approach? Drop it in the comments — genuinely curious
what the tradeoffs look like for different threat mode


Running a homelab-first security stack. Posts on practical defensive security, self-hosting, and building tools that actually get used.


Top comments (0)