Run it · 1 of 19
Where each service goes
Where to put the inbuxa server, console and webmail: one machine or three, what each arrangement costs, and how to size them.
On this page
The server, the console and the webmail are separate programs that talk over JMAP and sign in with OAuth. Where each one runs is a decision you make, not one the software makes for you, and every arrangement below is supported.
The decision, in one table
| Mail server | Console | Webmail | |
|---|---|---|---|
| Open | 25, 465, 993, 995, 4190 answer anyone | 443 answers anyone | 443 answers anyone |
| Protected | 25 from the world, client ports allowlisted | 443 behind an IP allowlist | 443 behind an IP allowlist |
| Private | 25 relayed in from a front door you control | on the private network only | behind the VPN |
Port 25 is the one thing that cannot be hidden and still be a mail server: it has to answer strangers, because that is what receiving mail is. Everything else is yours to place.
The front door for port 25 can be a second inbuxa that passes your mail on: see An edge server in front.
Three arrangements that make sense
One machine
Everything on a single VPS, on a private Docker network, with one proxy in front. One thing to back up, one thing to update.
This is the right answer for a home lab or a small organization, and it still keeps the console off the mail server's own listeners — the mail host serves no web interface in any arrangement.
Front ends on their own host
Move the console and the webmail to a second machine. Now a bug in a web front end is a bug on a box that holds no mail, and you can size the two independently: the webmail scales with people reading mail, the server with mail stored and delivered.
The server's API has to be reachable from that machine, and only from it — see Security for how origins are restricted.
Three machines
The server, the webmail and the console each on their own hardware, with the console on an internal network or behind a VPN. This is the arrangement for a multi-tenant host, and the console is the piece that benefits most: it is the one front end nobody outside your operators ever needs to reach.
Sizing
How big each machine should be, when a cluster is worth it, and what local AI adds, are on Sizing.
What does not change
Whatever you choose:
- No web interface is installed on the mail host.
- The server decides every permission, so the two front ends cannot disagree about what someone is allowed to do.
- The console and the webmail sign in as OAuth clients the server registered for itself.