A self-hosted alternative to Mailinator, Temp-Mail and 10 Minute Mail.
Those services hand you a throwaway address in one click and keep the mail on their infrastructure. BurnerByte is the other trade: you point a domain’s MX record at a server you run, and every address on that domain becomes a disposable inbox — with the mail, the database and the retention policy staying on your side of the network.
When a hosted service is the better answer.
If you need one address for two minutes to get past a signup form, use one of them. There is nothing to install, nothing to keep running, and nothing about that job that rewards owning infrastructure. The same goes for a one-off test on a machine that is not yours, or anything where the mail genuinely does not matter after you have read it.
Self-hosting is worth it when the mail does matter — when it carries customer data you would rather not hand to a third party, when the addresses need to be on a domain that is yours, when more than one person needs access under different permissions, or when someone will eventually ask where the data went and “a free service we found” is not an acceptable answer.
The two models, compared.
Drawn against hosted disposable-email services as a category rather than against any one of them: their feature lists are theirs to state and change. Everything in the right-hand column is described in the documentation and backed by the source.
| Compared on | Hosted services | BurnerByte |
|---|---|---|
| Where the mail lands | Their servers, under their domain | Your server, under a domain you own |
| Who can read it | Depends on the service; public inboxes are common on free tiers | Only the inbox creator, enforced in the service layer rather than the UI |
| Retention | Their policy | A TTL you set, from ten minutes to twenty-four hours, deleted by a worker you run |
| Addresses | One at a time, from their domain | Every address on every domain you point an MX record at |
| Teams and access control | Generally a paid tier, if offered | 34 permissions over 5 built-in roles, plus custom roles and an audit log |
| API | Varies; usually rate-limited by plan | 162 operations across 122 paths, with a served OpenAPI document |
| Time to first inbox | Seconds | A Docker Compose file, a DNS record, and a setup wizard |
| What it costs | Free tier, then per-seat or per-volume | Apache 2.0, plus whatever the server and domain cost you |
| Who operates it | They do | You do — including Postgres, Redis, backups and the upgrade path |
Running it yourself is the cost.
A server, a domain, PostgreSQL, Redis and an S3-compatible store — all of which Docker Compose brings up, and all of which are then yours to back up and upgrade. Mail has to reach port 25 or 2525, which some networks and some hosts make awkward. One API process, not several: every replica runs the same seven background workers and there is no leader election yet, so the API scales up rather than out while the SMTP daemon scales freely.
None of that is hidden in the documentation either — see production deployment, backup and restore and background workers for what that actually involves.