Skip to content
BurnerByte
Self-hosting

Get it running, properly.

Five guides that take a fresh machine to a deployment receiving real mail on your own domain. They are written against this codebase rather than against email hosting in general, so where BurnerByte has a sharp edge — and it has several — it is named rather than skipped.

Start with DockerSource
In order

Read them in sequence, or jump to the one you are stuck on.

  1. 01Docker ComposeStart here · ~10 minThe supported path. Covers what the reference does not: the two secrets that decide whether the deployment is defensible, why the public URLs are build args and not runtime config, upgrades, backups, and the failures that look like something else.
  2. 02Proxmox VE LXCHomelab · ~20 minA Debian 13 container with nesting and keyctl enabled, Docker inside it, and the storage, backup and port-25 decisions that a homelab actually runs into.
  3. 03DNS recordsRequired · ~15 minNot the record formats — those are in the reference — but the decisions around them: the exact-match rule that decides whether verification ever succeeds, why a subdomain beats your apex, and what Cloudflare does to mail records.
  4. 04Reverse proxy and TLSProduction · ~20 minNginx Proxy Manager click by click and Traefik as labels, neither of which the reference covers — plus why the forwarded headers matter enough that rate limiting, the audit trail and the metrics guard all depend on getting them right.
  5. 05Cloudflare Tunnel and WireGuardZero-trust · ~25 minPublish the web UI with no inbound ports open at all, put admin surfaces behind an identity check, and reach the box over WireGuard — while SMTP, which cannot tunnel, stays on a path of its own.
Before you start

What the machine needs, and the one thing that stops people.

CPU
2 coresTwo Go binaries and a Node server. Four if you are also hosting Postgres on the same box.
Memory
4 GBComfortable with the bundled Postgres, Redis and MinIO. 2 GB works against managed services.
Disk
20 GBImages and the database. Attachments are the variable — size for the retention you intend.
Network
Port 25 inboundNon-negotiable for receiving mail. Many residential ISPs and some VPS providers block it.
Check port 25 first
Everything else in these guides is recoverable. An ISP that blocks inbound port 25 is not — no amount of configuration will let mail reach you. Test it from another network before you build anything:
from a machine that is not the server
# Does anything answer on 25? (nc is on almost every box)$ nc -vz your-server-ip 25 # Or send a real test message once smtpd is up$ swaks --to anything@your-domain.com --server your-server-ip:25
If it times out, your options are a VPS whose provider permits it, a relay that forwards inbound mail to a port you can reach, or accepting that the instance receives only from inside your network.
The short version

If you only want to look at it, this is the whole thing.

A clean checkout runs with no configuration at all. Every value has a working default, the bundled Postgres, Redis and MinIO come up alongside the app, migrations apply themselves, and the storage bucket is created on first boot. The Quick Start walks through the setup wizard from there.

localhost only — see the warning below
$ git clone https://github.com/AmJaradat01/burnerbyte.git$ cd burnerbyte$ docker compose up -d # then open http://localhost:3000 and the setup wizard takes over
Careful
Those defaults are development-grade, and the project says so. Before this is reachable by anything other than your own machine you need a real JWT_SECRET and ENCRYPTION_KEY; without the second one, stored SSO, SMTP and storage credentials sit in the database in plain text. The Docker guide covers both.

These guides cover getting deployed. The full documentation goes further — the complete configuration reference, RBAC, webhooks, SSO, the settings cascade, monitoring and troubleshooting.