Documentation

Install the gateway

One installer, one prompt, then a five-step wizard in the browser.

The installer deploys native systemd services. It asks a single question and defers every application setting — hostname, domains, routing, filtering — to the web setup wizard, so nothing is silently baked in at install time.

Run the installer

# Unpack the release you downloaded, then:
cd securemail-appliance
sudo ./install.sh

It prompts once:

? Install method - 'metal' (native systemd) or 'docker' (container) [metal]:

Press Enter. Metal is the supported path — it is what runs in production and what these docs describe. Container deployment exists in the tree but is not yet supported; see Container deployment below before considering it.

Unattended install

The installer reads exactly two environment variables. Every other setting is configured afterwards in the browser, so there is no larger answer file to prepare.

sudo SECUREMAIL_NONINTERACTIVE=1 ./install.sh
VariableEffect
SECUREMAIL_NONINTERACTIVE=1Skip the prompt. Also implied when stdin is not a terminal.
SECUREMAIL_INSTALL_METHODmetal (default) or docker. Only read in the non-interactive path.

What it does

Roughly ten minutes, most of it apt and the Python virtualenv:

  1. Installs Postfix, PostgreSQL, nginx, OpenDKIM, ClamAV, certbot and the build toolchain. Output is captured to /tmp/securemail-apt.log.
  2. Creates the system user securemail, adding it to systemd-journal and adm so the console’s log viewer can read service logs.
  3. Creates /opt/securemail (code), /etc/securemail (config, mode 0750), /var/lib/securemail/store (encrypted messages), …/backups (0700) and /var/log/securemail.
  4. Builds a virtualenv at /opt/securemail/venv and installs pinned dependencies.
  5. Generates the master encryption key at /etc/securemail/secret.key, mode 0400, and writes /etc/securemail/securemail.env with the generated database and session secrets.
  6. Creates the PostgreSQL role and database and applies the schema, which is idempotent.
  7. Wires Postfix: sets content_filter and adds a managed block to master.cf between explicit markers, backing the file up first.
  8. Installs a validated sudoers rule so the console can apply Postfix, DKIM and TLS changes.
  9. Installs and starts the systemd services and timers, and the HTTP-only nginx site.
  10. Runs the smoke test and prints the console URL.

Back up /etc/securemail/secret.key now, somewhere off this host. It encrypts every stored message body, the archive and all stored credentials. There is no key escrow and no recovery path: lose it and the encrypted data is gone, even with a full database backup.

Create the first administrator

The installer prints the address it detected. Open the console:

http://<host-or-ip>/admin

There is no default account. Until one exists, every console URL redirects to /admin/setup/welcome, where the first visitor creates the superadmin — minimum ten characters. Once created, that page stops being reachable.

This window is open to anyone who can reach port 80. Do it immediately after install, or restrict the console first: set admin_allowlist to your management networks, which gates the whole console including the bootstrap page. Enable administrator MFA straight after under Account.

The setup wizard

Five steps, in order:

  1. Identity — organisation name, appliance hostname (the FQDN from the previous page) and the email address for Let’s Encrypt. One hostname serves the portal at / and the console at /admin.
  2. Mail flow — the domains you are protecting, whether to accept inbound mail, and where to deliver it afterwards (your existing mail server, as host or host:port). Optionally a smarthost for outbound; blank means direct MX delivery.
  3. Notifications — the From name and address recipients see, and a support contact.
  4. Review — applies the Postfix configuration. This is the point the gateway starts handling mail.
  5. TLS — requests the certificate and switches the site to HTTPS. Covered in DNS, TLS & mail records.

Nothing here is one-shot; every value remains editable afterwards on its own page. If applying Postfix fails at step 4 — usually DNS not yet resolving — the wizard says so and you can retry from Mail flow → Apply.

Verify

sudo /opt/securemail/scripts/smoke_test.sh

Checks that PostgreSQL, Postfix, nginx and the admin and portal services are active, that the master key and environment file exist, that the expected tables are present, that both health endpoints answer and that port 25 accepts a connection. It reports OpenDKIM and ClamAV as warnings rather than failures, since both are only needed once you enable the features that use them.

sudo /opt/securemail/venv/bin/python /opt/securemail/scripts/preflight.py

The deliverability check: public IP, reverse DNS and forward-confirmed reverse DNS, the hostname’s A record, MX, SPF, DKIM and DMARC per domain, reachability of your downstream and smarthost, every expected local listener, certificate expiry, and whether your IP is on a public blocklist. Run it again after publishing DNS.

Preflight expects port 443 to be listening, so it reports a failure on an appliance still in the pre-TLS setup phase. That one is expected until step 5 has run.

Apply your licence

Go to System → License. The Appliance ID shown there is your node ID — 32 hex characters, derived from the machine ID and DMI product UUID and then persisted to /etc/securemail/node_id, so it survives reboots and upgrades. Enter it with your activation code at Activate to receive the licence key, then paste the key into the same page.

Without a key the gateway runs in the Community tier. Clearing the field returns it to Community rather than disabling anything.

Upgrades

Re-run the same installer over the top. It detects the existing install, preserves the master key, database credentials, configuration and stored mail, replaces the code, and re-applies the schema.

cd securemail-appliance-<new-version>
sudo ./install.sh
  • Admin and portal session secrets are regenerated, so everyone is signed out. Expected.
  • Hard-refresh the console afterwards (Ctrl/Cmd+Shift+R) to clear cached assets.
  • Re-apply DKIM from Mail flow → DKIM. The installer truncates the OpenDKIM signing tables on every run; the private keys survive, but signing stays off until the tables are rebuilt. Skip this and outbound mail is delivered unsigned.

The appliance can also check for updates itself against the Rubix Hub hourly, verifying the package’s Ed25519 signature and SHA-256 before applying. Automatic application is off by default. A valid licence key is required to receive updates.

Container deployment

Not yet supported — use the native install. A Dockerfile and compose file exist in the tree and are being worked on, with two known gaps: the send API does not run in the container although nginx still routes to it, so /api/v1/* returns 502; and because services run under supervisord rather than systemd, the console’s Apply Postfix, DKIM keygen and certbot actions have limited support. Container support will be announced when those are resolved.

Uninstall

sudo ./uninstall.sh                                # remove the app, keep data and packages
sudo ./uninstall.sh --purge-data                   # also drop the database, store, key and config
sudo ./uninstall.sh --purge-data --purge-packages  # also remove Postfix, PostgreSQL, nginx, ClamAV

Every prompt defaults to no. Reverting Postfix, removing the nginx site and units, and deleting /opt/securemail happen in all cases. --purge-data is irreversible: it deletes the master key along with the database and store, which makes any surviving encrypted message permanently unreadable. Issued certificates under /etc/letsencrypt are always left in place.