A new server¶
This is the path when there is nothing to preserve. It ends with a working mail domain, its certificates and a first mailbox.
The one-command installer is not built yet
inbuxa deploy is specified (SPEC.md §6.1) and still to be written. What
is on this page under Install is the supported path today: build the
server, start it, and let INBUXA Admin's setup wizard complete first boot.
The installer's interface is kept at the bottom of this page so it can be
reviewed before it is built — it is a plan, not a command you can run.
Before you start¶
You need a Linux machine with Docker, a domain whose DNS you control, and a provider that lets the machine send on port 25.
Point the two hostnames at the machine first. They do not have to resolve before you run the installer, but certificates cannot be issued until they do.
Install¶
Build the server from source:
Or build the container image from the same tree:
Then start it with no configuration, which puts it in bootstrap mode, and run INBUXA Admin somewhere that can reach it. The wizard does the rest, in this order:
- Completes bootstrap over JMAP, which returns the permanent administrator. No web interface is involved at any point, and none runs on the mail host.
- Adds your domain and generates its DKIM keys.
- Turns on ACME and gets certificates.
- Creates the first mailbox.
A server that is already configured refuses bootstrap credentials, so the wizard cannot be pointed at a live server by accident.
If you put a proxy in front, tell the server to trust its forwarded addresses — otherwise the automatic IP ban will eventually ban your own front door.
Afterwards¶
Read credentials.txt, then put it somewhere safe. It holds the
administrator and the first user's passwords, and it is the only copy.
Publish the DNS records in example.com.zone. Mail will not be delivered
to you, and what you send will be treated as suspicious, until the MX, SPF,
DKIM and DMARC records are live.
Then sign in to the webmail at https://webmail.example.com, and to the
console at whatever host you gave it.
Planned: the one-command installer¶
Everything in this section describes inbuxa deploy, which does not exist
yet. It is recorded here because the interface is settled and worth
reviewing before it is built, not because you can run it.
| Option | Default | What it is for |
|---|---|---|
--domain |
required | The mail domain |
--mail-host |
mail.DOMAIN |
The server's hostname |
--webmail-host |
webmail.DOMAIN |
The webmail's hostname |
--email |
postmaster@DOMAIN |
The ACME contact |
--local |
off | Evaluate on loopback: no mail ports, no proxy, no certificates |
--dir |
./PROJECT |
Where the deployment lives; must be new or empty |
--webmail-bind |
127.0.0.1:8080 |
Where the webmail's port is published |
--yes |
off | Skip the confirmation |
Trying it first (planned)¶
Will bring the whole stack up bound to loopback with no mail ports, no proxy and no certificates. Nothing is exposed, no DNS is needed, and no certificate authority is contacted. It is the right way to look at the console and the webmail before committing a real domain to anything.
Both routes drive the same API, so the sequence the installer will run is the one the setup wizard already runs. That is why it can be specified this precisely before it is written.
Updating¶
The server, the console and the webmail are released together and carry the same version, so there is never a question of which webmail goes with which server. Updating is one step.
Back up before an update that crosses a store format
Data-format upgrades are one-way. Every INBUXA release names the Stalwart release it is built on, and a release that changes that base may convert your store on first start. Take a snapshot you have actually checked before starting one.