KumoMTA gives you the data. A panel gives you somewhere to stand.

# 1. Bind the engine HTTP listener to localhost, never 0.0.0.0 (init.lua)
kumo.start_http_listener { listen = '127.0.0.1:8000' }

# 2. Confirm nothing is listening on a public interface
$ ss -tlnp | grep 8000
LISTEN 0 1024 127.0.0.1:8000 0.0.0.0:* users:(("kumod"))

# 3. Panel reached only via the authenticated Nginx proxy (TLS + 2FA upstream)
location / { proxy_pass http://127.0.0.1:8000; auth_request /2fa; }

# 4. Port closed at the firewall; every action lands in the audit log
$ ufw status | grep 8000
8000  DENY  Anywhere

What feeds the panel

A panel is not magic layered over the engine; it is a reader of interfaces KumoMTA already exposes, which is worth understanding because it shapes what a panel can and cannot do. The engine runs an HTTP listener — conventionally bound to localhost on a port such as 8000 — that serves both its metrics and a JSON API. The metrics endpoint is the same one Prometheus scrapes; the API is how a panel reads queue state and issues actions like reloading policy or flushing a queue. Live logs are streamed separately, typically from the system journal, into the browser so an operator sees events as they happen.

This architecture has two consequences worth knowing. First, a panel works with any standard KumoMTA install without modifying the engine, because it consumes endpoints that are already there — which is why one can be added to an estate already in production rather than requiring a rebuild. Second, the panel is only ever as current and as capable as those endpoints allow; it reflects the engine’s real state rather than keeping its own, so there is no risk of the panel and the engine disagreeing about what is actually happening. Building a panel is largely the work of reading these interfaces faithfully, presenting them clearly, and — critically — securing the path between the browser and that localhost listener, which is the point the next sections keep returning to.

Quick actions, and the danger in them

The feature that makes a panel genuinely operational rather than merely informative is the quick action: a button that reloads policy after a config change, flushes or pauses a backed-up queue, or rests an IP that is drawing complaints. In an incident those actions are the difference between resolving something in seconds from a browser and assembling an SSH session under pressure. They are the reason a panel earns its place in the workflow rather than just decorating it.

They are also the reason a panel demands respect. A button that flushes a queue is a button that can dump mail; one that rotates IPs can reshape your reputation in a click; one that reloads policy can push a broken config to production instantly. The convenience and the danger are the same capability seen from two sides. So the actions a panel exposes have to be scoped to the role using it and wrapped in confirmation and audit logging, because the easier an action is to take, the more it matters that only the right person takes it, and that there is a record of who did.

Is a web panel safe to run on a production MTA?

Because a control panel can take those actions, an exposed one is among the more dangerous things you can put on a production MTA. A panel reachable from the public internet is a control surface for your entire sending operation handed to anyone who finds it \u2014 the ability to read queue metadata, flush mail, rotate IPs and alter policy. This is not a theoretical concern; it is the single most important thing to get right about running a panel at all.

The discipline is well established and we apply it without exception. The engine’s HTTP listener is bound to localhost rather than exposed, so it is reachable only from the machine itself. The panel sits behind an Nginx reverse proxy that terminates TLS and enforces authentication, with two-factor on the accounts that can take actions. The panel’s own port is kept off the public internet and closed at the firewall. And every administrative action is written to an audit log, so there is a record of who reloaded policy or rested an IP and when. A panel built and run this way is a safe, powerful tool. The same panel stood up carelessly \u2014 a port left open, no auth, no proxy \u2014 is a back door, which is exactly why we treat the securing of it as part of the build rather than a later hardening pass.

Community panels, honestly

Because the gap is real and KumoMTA is open, a small ecosystem of community control panels has grown up around it \u2014 React-and-Go projects, MailerQ-style admin UIs, lightweight dashboards that expose queues and shaping. Some are genuinely good, and for many estates the right answer is to take a solid one, harden it and integrate it rather than commission something bespoke. We would rather build on good work that exists than reinvent it.

The honesty the situation calls for is about maturity and trust. These projects vary widely in how actively they are maintained, how carefully they handle authentication, and how safely they expose the engine’s actions, and a control panel is precisely the kind of software where a security weakness is severe. So our role is selection and judgement as much as installation: evaluating which panel is sound enough to put in front of a production MTA, closing the gaps it has, securing it the way the previous section describes, and integrating it with your specific queues, shaping and metrics. The alternative \u2014 a team finding a panel, deploying it unreviewed and exposing it \u2014 is how a convenience becomes the incident. Choosing and hardening the right one is most of the value.

Can one panel manage a multi-tenant or clustered estate?

For an ESP or a platform sending on behalf of many customers, a panel is not only an operator tool — it can be part of the product. KumoMTA’s queues are already organised by tenant, so the data exists to show each customer their own sending without exposing anyone else’s. That opens two distinct kinds of panel, and they have very different requirements.

The operator’s panel is internal: full visibility across every tenant, every queue and every IP, with the powerful actions, locked behind authentication and used by your own team. A customer-facing panel is the opposite — scoped tightly to a single tenant’s data, with actions limited or removed, designed to be seen by people outside your company. Conflating the two is a serious mistake: a customer must never see another customer’s queues, and certainly must never reach an action that touches shared infrastructure. Building a multi-tenant panel is therefore as much about strict data scoping and permission boundaries as about the views themselves. We design the separation deliberately — what each role sees, what each role can do, and the hard walls between tenants — because at this level a leak between tenants becomes an incident with your customers’ names on it. Done right, the same engine that powers your sending can also give your customers a window into their own, without ever compromising the isolation multi-tenancy depends on.

A panel is not set-and-forget

One last honest point: a control panel is itself a piece of software, and like the engine beneath it, it needs tending. It has dependencies that get security updates, an authentication layer that has to stay current, and an integration with the engine that can drift as KumoMTA releases new versions. A panel deployed once and forgotten becomes, over time, the least-patched and most-exposed thing in the stack — the opposite of what it was installed to be. So running a panel properly includes keeping it updated and re-checking its security alongside the estate it watches. When we operate the panel that is simply part of the job; when we hand it over, it goes on the runbook we leave, because an unmaintained control surface is a risk wearing the costume of a convenience. There is a design decision worth making explicit here, because it shapes how a panel is built rather than just how it is maintained: which actions each role is trusted with. A deliverability manager might be allowed to read every queue and shaping decision but not to flush mail or rotate an IP; an on-call engineer might hold those powers behind two-factor and an audit trail. Scoping the doing separately from the showing, role by role, is what lets a panel be widely useful without widening the blast radius of a mistake or a compromised account.

How do you build or set up a KumoMTA panel?

We start from how your team works and what it needs to see and do, because that decides whether an existing panel fits or a tailored one is warranted, and which actions should be exposed to whom. Then we select or build, secure it to the standard above \u2014 localhost binding, reverse proxy, authentication, two-factor, firewalling, audit logging \u2014 and integrate it with your estate, wiring the queue, shaping and metrics views to your actual configuration and, for a cluster, aggregating across nodes.

From there it is yours to use, and ours to operate if you would rather not. Some teams want the panel handed over with documentation and run it themselves; others fold it into a managed engagement where we are watching the same views and acting on them as part of operating the estate. Either way the outcome is the same: the people responsible for your sending can see what the engine is doing and act on it, safely, without the command line being the only door in.

The result, when it is right, is a kind of quiet competence. The people who own your sending can answer the only two questions that matter in the moment — what is happening, and what do I do about it — from one screen, safely, whether or not they live in a terminal. That is the whole ambition of a panel: not to make KumoMTA look like something it is not, but to make the power it already has reachable by the people responsible for it, without trading away the security a control surface over production sending absolutely requires. The engine was built to be operated by experts. A good panel, run properly, quietly widens who gets to count as one.