Self-hosting addy.io (anonaddy/anonaddy): anonymous email forwarding on your own server

What anonaddy/anonaddy actually solves, and for whom

The repository is the source code for self-hosting addy.io, an anonymous email forwarding service. You hand out an alias instead of your real address. Mail sent to the alias is forwarded to your real inbox. When the alias starts receiving unsolicited mail, you deactivate or delete it, and the sender has no path to you anymore.

The README frames the motivation in terms of the alternatives the author tried: proprietary code, adverts, analytics and trackers on the sites, no GPG/OpenPGP encryption option, and no support for multiple recipients. Those four complaints are effectively the feature list. Aliases are per-site, so you can tell who sold your address. Forwarding is reconfigurable, so changing where mail lands does not require updating every account you own. Inbound mail can be encrypted with a GPG/OpenPGP key the recipient controls.

The intended audience splits in two. Most people use the hosted service at addy.io and never open this repository. The second group runs the application themselves, and the top-level layout tells you what that means: app/, config/, database/, postfix/, routes/, tests/, a Laravel artisan entry point, a composer.json, a Vite build for the Vue frontend, and a SELF-HOSTING.md. This is a full web application with a mail server attached, not a script.

How forwarding, aliases and encryption fit together

The moving parts are visible in the repository layout and in .env.example. A Laravel application (PHP) serves the web UI and API, backed by MySQL (DB_CONNECTION=mysql) with Redis handling cache, queues and sessions (CACHE_DRIVER=redis, QUEUE_CONNECTION=redis, SESSION_DRIVER=redis). A postfix/ directory sits at the top level, so inbound mail is handled by Postfix rather than by the PHP process. The data flow is roughly: mail arrives at ANONADDY_HOSTNAME for ANONADDY_DOMAIN, Postfix hands it to the application, the application resolves the alias to its recipient list, optionally encrypts the body with the recipient's public key, and re-sends it through the configured SMTP credentials.

That split matters operationally. The web tier can be restarted or redeployed without dropping mail, because Postfix owns the SMTP conversation. It also means the application is only as reliable as the queue behind it: with QUEUE_CONNECTION=redis, forwarded mail depends on a worker process draining Redis. If the worker stops, aliases accept mail that does not move.

The alias model has two shapes named in the README. A shared domain alias uses a domain the service already operates, so you get an address without touching DNS. A standard alias is the same idea on a domain you have added. Custom domains are supported, and the README addresses the awkward cases directly: adding a domain you already use for email elsewhere, and adding a domain while also using it as a recipient. Multiple recipients per alias are supported, which is one of the stated reasons the project exists.

Encryption is per-recipient. You add your own GPG/OpenPGP public key, and inbound mail is encrypted to it before forwarding. The README's FAQ covers the consequences: whether attachments are encrypted too, whether forwarded mail is signed when encryption is enabled, whether you can reply or send from an alias while using encryption, and whether your public key is removed when you do.

Installing it: from .env.example to a first alias

The repository does not carry the install steps inside README.md. It points at SELF-HOSTING.md at the top level, and the .env.example file is the concrete artefact you can read today. Treat the file below as the shape of the configuration, not a complete recipe: the real values depend on your host, your DNS and your mail provider.

The first block is the application identity and database. APP_URL must be the URL of your instance with no trailing slash, and the example file warns that a non-standard port has to be included.

APP_NAME=addy.io
APP_ENV=production
APP_KEY=
APP_URL=https://app.example.com

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=addy_database
DB_USERNAME=addy
DB_PASSWORD=secret

Redis is not optional in the example configuration. Cache, queue and session all point at the same Redis instance, and REDIS_CLIENT is set to phpredis, which means the PHP extension has to be present.

CACHE_DRIVER=redis
QUEUE_CONNECTION=redis
SESSION_DRIVER=redis
REDIS_CLIENT=phpredis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

The mail and forwarding block is where the project-specific settings live. ANONADDY_DOMAIN is the domain aliases are issued on, ANONADDY_HOSTNAME is the hostname mail is delivered to, ANONADDY_DNS_RESOLVER is the resolver used for domain verification, and ANONADDY_ADMIN_USERNAME lets one account receive catch-all mail at the apex domain.

ANONADDY_DOMAIN=example.com
ANONADDY_HOSTNAME=mail.example.com
ANONADDY_DNS_RESOLVER=127.0.0.1
ANONADDY_ALL_DOMAINS=example.com,example2.com
ANONADDY_ADMIN_USERNAME=johndoe
ANONADDY_ENABLE_REGISTRATION=true
ANONADDY_SECRET=long-random-string

Once the application is running, the first real use is the same as on the hosted service: create an alias, point a site's signup form at it, and confirm the forwarded message arrives in your inbox. The README's FAQ list covers the questions that come up at that point, including what to check when you are not receiving any emails and what happens if you mark forwarded mail as spam. The repository also ships dev.Dockerfile, docker-bake.hcl and a .dockerignore, so a container-based development path exists, but the README does not document a production Docker deployment.

Where self-hosting addy.io gets expensive

The honest limitation is that this is a mail server, and mail servers are judged by everyone else's spam filters. Nothing in the repository changes that. You are responsible for the DNS records that make your domain deliverable, for the reputation of whatever address forwards the mail onward, and for the Postfix instance in postfix/ staying up. A misconfigured instance does not fail loudly; it fails as mail that quietly never arrives.

The second constraint is the reply and send flow. The README's FAQ includes a cluster of questions about it: how to reply to a forwarded email, why a reply keeps coming back to you, why a send is rejected, and what the red spoofing warning banner means when it appears on forwarded mail. Those are the symptoms of envelope and header handling that depends on your outbound provider cooperating. If your SMTP relay rewrites the sender, the alias reply path breaks in ways the application cannot fix.

The third is scale of effort. A single-user instance needs MySQL, Redis, PHP with the phpredis extension, a Postfix setup, a queue worker, a scheduler and TLS. That is a reasonable weekend for someone who already runs mail. For someone who does not, it is a small ongoing operation. The README's own FAQ list includes questions like whether the application is tested and how to host it yourself, which is a fair signal that the maintainer expects self-hosters to bring their own operational knowledge.

anonaddy vs SimpleLogin, and the real difference in approach

The comparison people search for is anonaddy vs SimpleLogin, and the difference is not the feature list. Both forward mail to an alias and both let you disable an alias later. The difference is where the alias-to-inbox mapping lives and who operates it.

SimpleLogin is a hosted product with its own client apps and its own operational team. You sign up, you get aliases, and the infrastructure is someone else's problem. addy.io works the same way if you use the hosted service. The fork in the road is this repository: it is AGPL-3.0, so the code is available, and SELF-HOSTING.md exists so you can run the whole thing on hardware you control. That is the actual distinction. Choosing anonaddy/anonaddy over a hosted-only service means choosing to own the mail path, including the Postfix instance, the DNS records and the queue worker.

There is a second difference worth naming. The README lists GPG/OpenPGP encryption of inbound mail and multiple recipients per alias as gaps the author saw in other services. If those two are what you need, the repository is the argument. If you only need throwaway addresses and never intend to touch a config file, the self-hosted version is strictly more work for the same outcome, and the hosted addy.io is the better fit.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-02. The most recent tag in the release list is v1.7.2, dated the same day, following v1.7.1 on 2026-07-30 and v1.7.0 on 2026-07-15. That cadence suggests releases are cut regularly, but the README does not document an upgrade procedure, a migration path between versions, or a rollback step. Laravel applications normally carry database migrations in database/, and composer.lock pins the PHP dependency tree, so an upgrade means pulling the tag, running Composer, running migrations and rebuilding the frontend with the Vite scripts in package.json. None of that is spelled out in the self-hosting documentation, so verify it against SELF-HOSTING.md before you upgrade a live instance.

The licence is AGPL-3.0. The practical implication for a self-hoster is that the network-use clause applies to modified versions you let other people interact with over a network, which is a different obligation from a permissive licence. If you only run it for yourself, this is unlikely to matter. If you fork it and offer it to others, read the licence text in LICENSE.md rather than a summary. This is not legal advice.

The bigger maintenance cost is not the code. It is the mail infrastructure the code sits on: Postfix configuration, DNS records, TLS certificates, and the queue worker that drains Redis. Those need attention on their own schedule, independent of how often the application is tagged.

Editorial conclusion

Self-host anonaddy/anonaddy if you already run a mail server or are willing to learn Postfix, MySQL, Redis and Laravel deployment, and if your reason for self-hosting is that you do not want a third party holding the alias-to-inbox mapping. Do not self-host it if you want alias forwarding as a utility rather than a project: the hosted addy.io exists precisely so you never touch .env, DNS or Postfix, and the repository's own README treats that as the normal path. Before committing, verify three things against your own setup: that your host can run MySQL, Redis and a Postfix instance that the application can write to, that the ANONADDY_* values in .env.example map onto real DNS records you control, and that the reply and send flow survives your outbound SMTP provider's rules. If those three checks pass, the last push on 2026-09-02 and the v1.7.2 tag are the version you are building from.

Frequently asked questions

Official sources

1. anonaddy/anonaddy on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases