Installing PowerMTA and MailerQ.
A sending server from scratch.

The header of the installation section answers “what do I already have” before you choose anything. It shows how many servers are already running and on which MTA, whether there are free servers, which packages are uploaded and how many installations are running right now. These numbers tell you at once whether you can install an MTA on a server you already have or need a new one. You can install on several servers at once — up to ten installations at the same time — but only one per server. If there are no free servers, the header says so — “nowhere to install — a new server is needed” — and you add a new server further down in the form.

Enlarge

• Nodes with an MTA — how many servers are already running and on which MTA. In the example, 15: 12 PowerMTA and 3 MailerQ.
• Free nodes — connected servers without an MTA that you can install on without adding a new one. In the example there are 0, and the header says so: “nowhere to install — a new server is needed”.
• Packages uploaded — which installation packages are in the Hub, per MTA. In the example, 3: PowerMTA 2 and MailerQ 1.
• Installations running — how many installations are running right now, out of ten possible. You can install on several servers at once, but only one installation per server. In the example, 0 of 10, “queue is free”.
• “Nodes” — the button on the right leads to the server list.

The first installation step is choosing the MTA. The choice decides both what gets installed and in what order: PowerMTA is one package and one service, MailerQ is a three-part cluster. Each MTA card shows how many servers already run it and how long an installation usually takes, based on your own past installations. Below, you choose the package branch for the server's system — DEB for Ubuntu 22.04 or RPM for Rocky Linux 8 — and the Hub matches it against the system before uploading the package. The Hub works out the time from your successful installations — the median of the last twenty — and shows how many measurements it is based on; in the example, PowerMTA installs in about a minute.

Enlarge

• PowerMTA card — one package, one service: installed on the server and ready to accept mail from the Hub right away. In the example it runs on 12 nodes, installs in about a minute (from 12 measurements), deb and rpm branches.
• MailerQ card — “3 components”: the MTA works only together with the cluster database and the broker. In the example it runs on 3 nodes and installs in about 2 minutes (from 3 measurements).
• Installation time — the Hub works it out from your successful installations — the median of the last twenty — and shows how many measurements it is based on.
• Package branch — PowerMTA 6.0r3 as DEB for Ubuntu 22.04 or RPM for Rocky Linux 8. When the server is already connected, the page picks the branch for its system itself.
• Branch vs. system check — the Hub checks it before uploading the package: if the branch is wrong, the installation stops at the check, not halfway through.

The time on the card is based on earlier successful installations in your Hub.

The second step is where to install. For a new server you need a name, an address, an SSH port, a login and the root password. The password is needed only once: the Hub signs in with it, puts its own SSH key on the server and from then on uses only the key. Here the server is also assigned to the right infrastructure and given a purpose — sending, tracking or both. The purpose decides what the Hub installs next: for example, a web stack for tracking. You cannot add the same IP address twice: the Hub shows the server that already has it. If the infrastructure diagram has a slot waiting for such a node, the slot is filled automatically.

Enlarge

• “New server” and “Already connected” — the switch at the top: add a new server or pick one of the connected ones.
• Name, server address, SSH port and login — in the example, mta-11, 192.0.2.21, port 22 and root.
• Root password — needed once: the Hub installs its own key and uses it from then on.
• Infrastructure — which group the server belongs to. If its diagram has a slot waiting for such a node, the slot is filled automatically.
• Purpose — sending, sending and tracking, or tracking only. It decides what the Hub installs next: a web stack for tracking.
• System hint — the Hub learns a new server's system when it connects. If it does not match the package branch, the Hub stops before the upload and tells you which package to take.

You cannot add the same IP address twice: the Hub shows the server that already has it.

The table of all connected servers shows what each one already runs — MailerQ 5.16.2 or PowerMTA 6.0r3 — and its state: running, stopped, failed or being installed right now. It helps you choose where to install a new MTA and shows at once whether there are free servers without an MTA. For MailerQ servers, it also marks where the shared cluster parts — the database and the broker — are running. If there are no free servers, the line at the bottom says so plainly. In the example, the fleet has 15 servers from mq-01 to tx-02, all “running”, and the MailerQ database and broker are on mq-01.

Enlarge

• Name and address — every server in the fleet; in the example, 15 nodes: from mq-01 to tx-02.
• MTA and version — which MTA is installed and which version: MailerQ 5.16.2 or PowerMTA 6.0r3.
• Cluster database and broker — for MailerQ, shows which server runs the cluster parts. In the example, mq-01.
• State — running, stopped, failed or being installed right now. In the example, all servers are “running”. The chosen server's row is highlighted.
• Free nodes — the line at the bottom says whether there are servers without an MTA. In the example: “No free nodes: every connected server already has an MTA”.
• “All nodes” — the link in the corner leads to the full server list.

Before you start, you see exactly what will happen — in the same words the console will use later. A PowerMTA installation always runs in four steps: connection, pre-flight check, MTA installation and base configuration. The list is live: for a server that is already connected, the first step is shorter because the Hub key is already there. If the server does not fit, the installation stops at the check, before the package is uploaded, and the line at the bottom says what to do after installation. After installation, the node's addresses and domains, signing keys and mail intake are set up in the “Configurations” section.

Enlarge

• Connection — sign-in with the password and the Hub key installed on the server — after that the password is no longer needed.
• Pre-flight check — system and package branch, permissions, free ports, port 25 from outside and outbound mail. If the server is unfit, the installation stops before the package is uploaded and names the reason.
• MTA installation — package upload, installation and service start with start at boot.
• Base configuration — a base config with Hub access and telemetry intake, a health check and reverse DNS check.
• What comes next — the node's addresses and domains, signing keys and mail intake are set up in the “Configurations” section.

The last check before work begins: everything chosen above, on one line. You see which package is installed, on which server and how the Hub will sign in, how many steps there are and how long they usually take. If something is missing in the form, a red line says so before the start, not in the middle of the installation. The “Install” button creates the task and opens its console, after which you can leave the page: the installation runs on the Hub side. A closed tab will not stop it, and you can open the task console later from the server's card. In the example, PowerMTA 6.0r3 is installed on the new mta-11 with root password sign-in, and it will take about a minute.

Enlarge

• MTA — the chosen package and its branch. In the example, PowerMTA 6.0r3 (Ubuntu), DEB; the system is checked on connect.
• Server — where the MTA goes and how the Hub signs in. In the example, mta-11 · 192.0.2.21, new, root sign-in with a password.
• Order — 4 steps and how long they take based on your installations: in the example, about a minute (from 12 measurements).
• “Install” — creates the task and opens its console. A closed tab will not stop the installation.
• Form check — if something is missing, a red line says so before the start, not in the middle of the installation.

The same first step, but with MailerQ chosen — an MTA that works only together with a PostgreSQL cluster database and a RabbitMQ broker. Its card shows how many servers already run it and how long its installation takes based on your measurements. There is one branch — the MailerQ 5.16.2 package for Ubuntu 22.04. Next to it in the Hub are the MailerQ web panel and a ready set of RabbitMQ packages, so the broker installs without reaching out to third-party repositories. The branch vs. system check is the same as for PowerMTA: if the branch does not fit the server, the installation stops at the check, before the package is uploaded. In the example, MailerQ runs on 3 nodes and installs in about 2 minutes.

Enlarge

• MailerQ card — the MTA works only together with the cluster database and the broker — they are installed here too or connected from servers where they already run.
• Runs on and installs in — in the example, MailerQ runs on 3 nodes and installs in about 2 minutes (from 3 measurements).
• Package branch — MailerQ 5.16.2 (Ubuntu), DEB, for Ubuntu 22.04.
• RabbitMQ bundle — the broker is installed from a prepared set of packages, without reaching out to third-party repositories.
• Branch vs. system check — as with PowerMTA, before the upload: wrong branch — the installation stops at the check.

When there is no database or broker anywhere yet, all three parts are installed on one server, and the page offers this option itself. This creates the foundation of a MailerQ cluster: the MTA, a shared PostgreSQL database and a RabbitMQ broker. The counter at the top shows “3 here · 0 outside” — everything goes on the chosen server. Later servers get only the MTA, connected to this database and this broker, so there is no need to install the database and broker again. The MTA gets a management panel on port 8486 right away, and the credentials for all three parts — database, broker and panel — are set on the next screen, with the Hub generating the passwords itself.

Enlarge

• MailerQ MTA — receives and sends mail, management panel on port 8486.
• Cluster database — PostgreSQL: the queue, statistics and settings of all MTAs in the cluster.
• Broker — RabbitMQ: exchange between the cluster's MTAs.
• “install here” and “on this server” — each part shows that it will go on the chosen server. The counter at the top: “3 here · 0 outside”.
• “The first server of the cluster” — the line at the bottom: the MTA, database and broker go in together, and the cluster then grows one node at a time.

The first server of a cluster has the most credentials: for the database, the broker, the MailerQ panel and SMTP mail intake. They all go into the node's config, and the Hub fills them in itself — you only need to check the values. The passwords are generated at once, in a form that does not break the connection address: the broker password never contains @, a colon, a slash, % or spaces. You can view the credentials later in the “Configurations” section, on the MTA card. In the example, the database name and user are mailerq, the panel login is mqconsole, and the SMTP intake port is 25251; the “Copy all” button puts all credentials on the clipboard in one click.

Enlarge

• Cluster database — database name, user and password. In the example, the name and user are mailerq.
• Broker — user, password and vhost. In the example, user mailerq and vhost “/”.
• MailerQ MTA — panel port 8486, panel login mqconsole, panel password and SMTP intake port 25251.
• Passwords — the Hub generates them itself; the ↻ button next to a field creates a new one.
• “Copy all” — puts all credentials on the clipboard in one click.
• Password note — the Hub stores them, and you can view them in “Configurations” on the MTA card. The broker password never contains @ : / % or spaces: it goes into the connection address as is.

Future MTAs of the cluster will connect to the database and broker on the first server, so they need open ports. The table shows which port is for what and who opens it. On its own servers the Hub opens the database and broker ports itself, while management panels are opened by hand — only from your address. This way the database and broker are reachable for future cluster nodes, while the broker and MTA panels are not exposed to the internet. On a third-party machine that the Hub does not set up, the rules are opened by hand. When a new node later joins the cluster, the Hub opens access to the database and broker on this server for it automatically.

Enlarge

• 5672 — the broker on this node — exchange between MTAs. Opened by the Hub.
• 5432 — the database on this node — for future MTAs of the cluster. Opened by the Hub.
• 15672 — the broker panel, only from your address. Opened by hand.
• 8486 — the MTA panel, only from your address. Opened by hand.
• Line at the bottom — the Hub sets up its own servers itself; on someone else's machine, the rules are opened by hand.

The second option for MailerQ is a new server joining a cluster that is already running. Each of the three parts is either installed here or taken from outside: in the example, only the MTA goes on the new server, while the PostgreSQL database and the RabbitMQ broker come from node mq-01, where the Hub has already set them up. The counter at the top shows “1 here · 2 outside”. You can pick the database and broker from the Hub's servers — then it fills in the credentials itself — or enter your own, in which case you open access for the new node's addresses yourself. This is how a MailerQ cluster grows: each next node is added the same way, without installing the database and broker again.

Enlarge

• MailerQ MTA — “install here”, on this server: receives and sends mail, management panel on port 8486.
• Cluster database — “outside”: in the example, picked from the list — mq-01 (198.51.100.21) · mailerq.
• Broker — “outside”: in the example, mq-01 (198.51.100.21) · vhost “/”.
• “on a Hub node” or “your own address” — you can pick the database and broker from the Hub's servers or enter your own. For your own, you need to open access for the new node's addresses yourself.
• Counter at the top — how many parts are installed here and how many are taken from outside. In the example, “1 here · 2 outside”.
• “A complete set” — MTAs sharing one database and one broker work as a single cluster. The Hub fills in the credentials for the other servers' parts itself and opens their ports to this node's addresses.

A shared database and broker unite MTAs into one cluster.

Everything that goes into the new MailerQ node's config is gathered here. For parts on another server you do not need to enter anything — one line says the Hub will fill in the mq-01 credentials. For the MTA itself, you set the management panel and the SMTP mail intake port: in the example, panel port 8486 with login mqconsole and intake port 25251. The Hub generates and stores the passwords, and you can view them later in the “Configurations” section. If the database and broker run on a third-party server rather than a Hub node, you need to open access to them for the new node's addresses yourself: on someone else's machine, the rules are opened by hand.

Enlarge

• Cluster database and broker — “the Hub will fill in the mq-01 credentials” — the details come from the server where they already run.
• Panel · port and login — in the example, port 8486 and login mqconsole.
• Panel · password — generated automatically; the ↻ button creates a new one.
• SMTP · port — the mail intake port, in the example 25251.
• “Copy all” — puts all credentials on the clipboard in one click.
• Password note — the passwords go into the node's config; you can view them later in “Configurations” on the MTA card.

The MailerQ installation order is the same — four steps — but the third one opens into sub-items, one for each part of the cluster. The set of sub-items changes along with your choice in “Cluster parts”. In the example, the server joins a ready cluster, so the plan includes access to the database and broker on mq-01. The MailerQ config is already written in the third step; the fourth is a summary, and the MTA starts accepting mail after you set it up in the “Configurations” section. If you choose in “Cluster parts” to install the database and broker on this server, their installations replace the mq-01 access in the plan.

Enlarge

• Connection and pre-flight check — the same first two steps as for PowerMTA.
• Cluster installation — uploading packages to the node, access to the database and broker on mq-01 for this node's addresses, the MailerQ packages and management panel, the MTA config and a connection check.
• Base configuration — a summary: the MTA panel, mail intake, the cluster database and broker, a reverse DNS check.
• What comes next — the MTA starts accepting mail after you set it up in the “Configurations” section.

When the cluster parts are spread across different servers, they need open ports to talk to each other. The table shows which port leads where and who opens it. On its own servers the Hub opens the database and broker ports itself, and only for the new node's addresses; on a third-party machine, the rules are opened by hand. The MailerQ panel port is opened by hand and only for your own address: a management panel should not be exposed to the internet. In the example, these are 5672 and 5432 on mq-01, which the Hub opens, and 8486 for the MTA panel, which you open yourself. Without access to the shared database and broker, the new node will not become part of the cluster.

Enlarge

• 5672 — the broker on mq-01 — exchange between MTAs. Opened by the Hub.
• 5432 — the database on mq-01 — the cluster's queue and statistics. Opened by the Hub.
• 8486 — the MTA panel, only from your address. Opened by hand.
• Line at the bottom — the Hub sets up its own servers itself; on someone else's machine, the rules are opened by hand.

The last check before launching MailerQ. Besides the package, the server and the number of steps, it shows what goes on this server and where the other cluster parts live: in the example, only the MTA is installed on mq-04, while the database and broker stay on mq-01. The installation will take about 2 minutes — the Hub works out the time from your past installations. The “Install” button creates the task and opens its console, and you can leave the page after that. If something is chosen wrong, go back up: everything shown here is put together from your choices on the previous screens, and the server's system is checked on connect.

Enlarge

• MTA — MailerQ 5.16.2 (Ubuntu), DEB; the system is checked on connect.
• Installing here — in the example, only the MTA, with “database — on mq-01 · broker — on mq-01”.
• Server — in the example, mq-04 · 198.51.100.24, new, root sign-in with a password.
• Order — 4 steps and about 2 minutes based on your installations (from 3 measurements).
• “Install” — starts the installation and opens the task console.

Instead of a new server, you can pick one that is already connected — the quick route when the server is already in your fleet and you only need to put an MTA on it. Servers are shown as tiles: name, address, system and what runs on the server now. The Hub key is already on them, so no root password is needed and the connection step is shorter. Servers with another MTA stay in the list but are marked: installing a second MTA on such a server replaces the first rather than running alongside it. In the example, all servers run Ubuntu 22.04, and mta-01 (192.0.2.11) is selected. If it already has another MTA, the next screen warns you what exactly will be interrupted.

Enlarge

• “Already connected” — the switch at the top shows the fleet's servers instead of the new server form.
• Server tile — name, address and system. In the example, all servers run ubuntu 22.04, and mta-01 (192.0.2.11) is selected.
• State label — what is on the server now: “no MTA”, “PowerMTA installed”, “MailerQ installed” or “task running”.
• Server with an MTA — stays in the list, but installing a second MTA on the same server replaces the first rather than running alongside it.

If an MTA is already running on the chosen server, the summary line changes. The Hub names which MTA will be replaced and what exactly will be interrupted: a running warm-up, the last day's mail or simply the previous MTA. In the example, warm-up is running on mta-01: the replacement will cut off sending and break the ramp-up, and the volume will have to be built up again. The button reads “Replace the MTA”, and before the start the Hub asks for confirmation once more, in words — so a replacement never happens by mistake. The package branch is already checked here — “branch fits the system” — because the Hub already knows the server's system. The order is the same: 4 steps, about a minute based on your installations.

Enlarge

• MTA — in the example, PowerMTA 6.0r3 (Ubuntu), DEB — “branch fits the system”, because the server's system is already known.
• Server — in the example, mta-01 · 192.0.2.11, “will replace PowerMTA”.
• Order — 4 steps, about a minute based on your installations.
• Warning — in the example: mta-01 runs PowerMTA and a warm-up is in progress; the replacement will cut off sending and break the ramp-up, and the volume will have to be built up again.
• “Replace the MTA” — starts the replacement, which you must confirm separately.

This is how the console looks at the end of a PowerMTA installation: all four steps are done and the progress bar is green. The last lines show the version check, removal of the installation package, the base configuration and the reverse DNS check. In the example, PowerMTA 6.0r3 is running and listening on ports 1000, 25 and 2525, and the forward and reverse records of both addresses match. The final line says the server is managed by the Hub, and the buttons lead to the next stage — DNS and signing keys. If the installation had stopped earlier, you would see here the step where it stopped and the reason. The console stays with the task — you can open it later from the node card.

Enlarge

• “done” and “step 4 / 4” — the task state and the progress bar above the log.
• Version and status check — PowerMTA v6.0r3 is running and listening on ports 1000, 25 and 2525.
• Node registered in the Hub — in the example, PowerMTA 6.0r3.
• Reverse DNS — for each server address: forward and reverse match. In the example, “2 of 2”.
• Final line — “Done. The server is managed by the Hub, MTA 6.0r3. Next — DNS and signing keys”.
• “DNS and signing keys”, “To nodes” and “To the node card” — the buttons lead to the next stage, the server list and this server's card.

The screen shows an example of a completed PowerMTA 6.0r3 installation.

The start of the log: what is being installed and where, then the first two steps. In the first, the Hub connects, learns the server's system and resources, installs its key and matches the package branch against the system. In the second — eleven server checks, each with its own answer: permissions, system, resources, DNS, host name, time, port 25 and the link to the Hub. If any check fails, the installation stops before the package is uploaded. In the example, a server on Ubuntu 22.04 with 4 cores and 8192 MB of memory passed everything. If a check fails, fix the cause on the server — for example, ask the hosting provider to open outbound port 25 — and run the installation again.

Enlarge

• Header — what is installed and where: in the example, PowerMTA 6.0r3 (Ubuntu) on root@192.0.2.11:22.
• Step 1/4: connection — OS ubuntu 22.04, 4 cores and 8192 MB of memory; key access is set up — the root password is no longer needed; the package fits: DEB for ubuntu.
• Permissions, system and architecture — root access confirmed, ubuntu 22.04 supported, x86_64 processor.
• Resources — processor, memory and disk with free space: in the example, 4 vCPU, 8192 MB RAM, 160 GB disk, 151 GB free.
• DNS, host name and time — name resolution works, host name mta-01.mailrelaygrid.net, NTP synchronized.
• Port 25 and an existing MTA — port 25 on the server is free, no MTA installed yet, outbound connections on port 25 get through.
• Link to the Hub over HTTPS — the server reaches the Hub, so telemetry will flow.

Step 3 starts by uploading the PowerMTA package to the server and checking that the file is not corrupted. Then the Hub waits until the server releases the package manager and installs the dependencies. A fresh server is often busy with automatic updates, so the installation waits up to ten minutes instead of failing with an error. Command output goes into the console as is, as it is produced, not in one piece at the end: yellow is the command itself, white is the server's response. Integrity is checked before installation: in the example, 153,077,708 bytes were uploaded and the check confirmed the file is intact. A green tick at the end of a line marks a sub-step that finished successfully.

Enlarge

• Package upload and check — in the example, 153,077,708 bytes uploaded, integrity confirmed.
• Waiting for the package manager — a fresh server is often busy with automatic updates — the installation waits up to ten minutes. In the example, the manager was free right away.
• Installing dependencies — perl and unzip; the yellow line is the apt-get command itself.
• Command output — white lines are the server's response, as is.
• Green tick — marks a sub-step that finished successfully.

Step 3 then goes sub-step by sub-step, each with a one-line result. The Hub installs the package, sets the system language for MTA messages, opens ports, and sets up log rotation, permissions and services. At the end, it checks the MTA version and that it works, removes the installation package and registers the node in the Hub. The distribution with the license inside does not stay on the server, and the pmta and pmtahttp services start at boot. The log rotates daily with 14 copies kept, and ports 25, 2525 and 1000 are opened in ufw. The service limits are raised to 16,384 processes and 32,768 open files, and the /etc/pmta directory is owned by root.

Enlarge

• Installing the PMTA package — in the example, dpkg --install PowerMTA-6.0r3.amd64.deb; on Rocky Linux, an RPM package.
• Locale and ports — en_US.UTF-8 locale added; ufw opens 25 (incoming reports), 2525 (submission) and 1000 (monitor).
• Log rotation — daily, 14 copies, cut at 100 MB, compressed.
• Permissions and DNS resolver check — 755 on the binaries, /etc/pmta owned by root; resolver OK, name servers: 2.
• Starting the PMTA services — pmta and pmtahttp are running, start at boot is on, service limits — 16,384 processes, 32,768 files.
• Version and status check — PowerMTA v6.0r3 is running, ports 1000, 25 and 2525.
• Removing the installation package — the distribution with the license inside does not stay on the server. Node registered in the Hub: PowerMTA 6.0r3.

Step 4 makes the server manageable from the Hub. The Hub writes the settings, checks them for errors, reloads them and makes sure the MTA is running and reachable from outside: it connects to port 25 itself and receives the server's greeting. Management access is allowed only for the Hub, and the previous configuration is saved as a copy. At the end — a check of the reverse DNS (PTR) of every server address: in the example, forward and reverse records match for 2 of 2 addresses. The telemetry token and the main config are written to /etc/pmta/mtahub-headers.txt and /etc/pmta/config, and the syntax is checked with pmta test config before the reload.

Enlarge

• Management access — allowed only for the Hub, in the example from address 198.51.100.250.
• Config snapshot and certificate — the previous configuration is saved as a copy, the certificate for STARTTLS submission is ready.
• Telemetry token and main config — written to /etc/pmta/mtahub-headers.txt and /etc/pmta/config.
• Syntax check and reload — pmta test config passed, the configuration was reloaded, the web monitor restarted with new access rules.
• Health check — the MTA answers and listens on its ports, and port 25 is reachable from outside: the Hub connects to it itself and receives the server's greeting.
• Reverse DNS — forward and reverse records of every address match — in the example, 2 of 2.

The end of the installation of a MailerQ cluster's first server. Three installations ran in one log — the database, the broker and the MTA itself — and all four steps are complete. MailerQ 5.16.2 is running, the panel works on port 8486, and the node API answers with the token; mail intake on port 25251 is not up yet. At the bottom — a summary for the next stage and the final line “Done”. The console stays with the task, so you can open it after the installation, and the installation files have already been removed from the server. The step 4 summary says where the database and broker are, the panel's address and login, and when mail intake opens.

Enlarge

• REST token — issued for the Hub and saved in the node's credentials.
• Service start and check — MailerQ 5.16.2 is running, panel on port 8486, broker connected, the node API answers with the token. Mail intake on port 25251 is not up yet.
• Removing the installation files — the MailerQ and web panel packages and the RabbitMQ bundle are removed from the server.
• Step 4 summary — placed on the server: MTA, cluster database, broker; the panel address and login; when mail intake opens; where the database and broker are.
• Reverse DNS and result — in the example, 2 of 2, then “Done. The server is managed by the Hub, MTA 5.16.2. Next — DNS and signing keys”.

For MailerQ, step 3 starts by uploading all the packages it needs to the server — in the example, 20 files: the MailerQ 5.16.2 package, its web panel and the RabbitMQ bundle. Then the chosen cluster parts are installed: first PostgreSQL with the cluster database and its user, then RabbitMQ from the ready bundle, its panel, the cluster administrator and permissions on the vhost. The installation output goes into the console as is — you can see which packages the server installs and how much space they will take. After the database and broker, the same step installs the MailerQ packages and the PostgreSQL client; PostgreSQL itself comes from the Ubuntu repository.

Enlarge

• Uploading packages to the node — the MailerQ 5.16.2 package, its web panel and the RabbitMQ bundle — 20 files.
• PostgreSQL + cluster database — PostgreSQL is installed from Ubuntu, then the cluster database and its user are created.
• Command output — white lines show which packages the server installs and how much space they will take.
• Later in the step — RabbitMQ from the bundle, the broker management panel, the cluster administrator and permissions on the vhost, the MailerQ packages and the PostgreSQL client.

The console shows exactly what is written into the MailerQ config, with passwords hidden behind asterisks. The config holds the database and broker addresses, the management panel, mail intake, the license and safe defaults: downloads from local networks are forbidden and message preview is off. In the example, the database and broker run on this same server, and the panel is on port 8486. The mail intake addresses are left empty on purpose for now: they are chosen on the node configuration page. This output makes it easy to check that the credentials were filled in correctly without logging in to the server. The path to the MailerQ license file is also visible in the config.

Enlarge

• Database and broker — connection addresses for PostgreSQL and RabbitMQ; in the example, both are on this same server.
• Management panel — port 8486, login mqconsole and the panel address.
• SMTP intake — port 25251; intake addresses (smtp-ip) are not chosen yet.
• Safe defaults — downloads from local networks are forbidden, message preview is off.
• License — the path to the MailerQ license file.

The end of step 3 and step 4 for MailerQ. The Hub prepares the database structure with mailerq --repair-database, issues a REST API token so the node API works from the first minute, starts the MTA and checks every part, and then removes the installation files. The summary explains where the components are and why SMTP is not accepting mail yet: port 25251 is not up by design — until sending addresses are chosen. The reverse records of the server's addresses are checked here too; in the example, 2 of 2 match. The REST token is saved in the node's credentials, so the Hub works with the MTA through the API right after installation.

Enlarge

• Database schema — mailerq --repair-database; MailerQ replies that the database structure is compatible with version 5.16.2.
• REST token for the Hub — so the node API works from the first minute.
• Service start and check — MailerQ is running, the panel listens on 8486, the broker is connected, the API answers with the token. Mail intake (25251) is not up — by design, until sending addresses are chosen.
• Removing the installation files — the MailerQ packages and the RabbitMQ bundle are removed from the server.
• Summary — what is placed on the server, the panel address and login, why the SMTP monitor in the panel is off, when mail intake opens, where the cluster database and broker are.
• Reverse DNS — forward and reverse records of every address match, in the example 2 of 2.

SMTP mail intake turns on when you choose addresses in the server configuration.

This is what step 3 looks like for a server joining a ready MailerQ cluster. There is no database or broker installation here: the Hub itself signs in to the server where they run and opens access there for the new node's addresses. Only the MailerQ 5.16.2 package and its web panel are uploaded to the server, without the RabbitMQ bundle. The REST token is not issued a second time — it is already in the shared cluster database, and nothing has to be done by hand on the neighboring server. Access is opened only to the new node's addresses, for the broker with vhost “/”; in the example, the database and broker run on mq-01 (198.51.100.21).

Enlarge

• Uploading packages to the node — only the MailerQ 5.16.2 package and its web panel — without the RabbitMQ bundle.
• Access to the remote database — node mq-01 (198.51.100.21) allows connections from the new server's addresses.
• Access to the remote broker — the same for the broker, with vhost “/”.
• REST token — not issued a second time: it is already in the shared cluster database, and the new node uses the same one.

The summary of a joined MailerQ node. Only the MTA runs on the new server, while the database and broker stay on the cluster server — in the example, on mq-01 (198.51.100.21). The main line confirms that the node works on the shared database and broker — so it is in a cluster with everyone who uses the same ones. Mail intake on port 25251 opens once sending addresses are chosen in the node configuration, and the final line “Done” confirms that the server is managed by the Hub. The reverse record of the new node's single address matches — in the example, 1 of 1. From here, the node is set up the same way as the first: addresses, domains and DNS.

Enlarge

• Placed on the server — the MTA only.
• MTA panel — the new node's panel address and login mqconsole.
• Mail intake — port 25251 opens once sending addresses are chosen on the node configuration page.
• Cluster database and broker — in the example, database 198.51.100.21/mailerq and broker 198.51.100.21, vhost “/” — that is, on mq-01.
• Node in the cluster — “The node works on the shared database and broker — so it is in a cluster with everyone who uses the same ones”.
• Reverse DNS and result — in the example, 1 of 1, then “Done. The server is managed by the Hub, MTA 5.16.2”.