Deployment
Postfix Insights does two things: it serves a web UI for search and stats, and it runs a background scanner that rolls your logs into the stats database. Where you put each of those pieces is the only real deployment decision. This page walks through the supported topologies and the one rule that holds for all of them.
Single node
Section titled “Single node”The default, and the right choice for most installs. Run Postfix Insights on the mail server itself and point it at the host’s /var/log, mounted read-only. Nothing leaves the box, there is nothing to mount, and the logs are already local.
The trade-off is availability. The tooling shares the fate of the mail server: if the box goes down, search and stats go down with it. For a single mail server that is usually fine, because when the mail server is down you have a bigger problem than the dashboard being offline.
A single node is not limited to its own logs. When you run a pool of mail servers that act as one system, the same Postfix configuration, reached through a VIP or round-robin so any of them may handle a given message, their logs are really one mail stream split across boxes. Mount the other servers’ logs onto this node over SSHFS and they join the same search and stats. That is the only way to see the pool’s true volume, bounce rate, and SLA, because any single box is a partial view. The pool members share no queues or logs, so each message lives out its whole lifecycle on the one server that handled it; pooling the logs gathers complete messages rather than fragments to stitch back together, and queue-ID correlation stays intact. The local host’s logs are already there; only the remote servers are mounted. One node, one scanner, the whole pool in one view.
Aggregate only servers that belong together. Mail systems that are genuinely separate, with different senders, domains, and customers, stay clearer kept apart: run a standalone instance against each rather than mixing unrelated streams into one set of stats. A combined bounce rate or SLA across systems that have nothing to do with each other is an average of apples and oranges. Postfix Insights is light enough to run one instance per system, and each stays a focused view of the mail it owns.
Dedicated box with remote logs
Section titled “Dedicated box with remote logs”The same idea, but with the app on a machine of its own rather than on a mail server. Run the app and its sqld database on a separate box and mount every mail server’s logs onto it over SSHFS. Nothing runs on the mail servers themselves.
Reach for this when you would rather keep Postfix Insights off the mail servers entirely, or when no single mail server is the obvious place to host it. The dedicated box becomes the single point of failure for the tooling, but not for mail itself: the mail servers keep delivering whether or not that box is up, and the scanner simply resumes where it left off when it comes back.
Containers
Section titled “Containers”Each tagged v3.1.x release publishes a container image to ghcr.io/xodus-co/postfix-insights. The app container runs next to the sqld sidecar (the stats database) on a private Docker network, so the database is never exposed beyond the app.
Pin the image tag rather than tracking latest, so a deploy is reproducible and an upgrade is a deliberate change of tag. To upgrade, pull the new tag and restart. The docker-compose.prod.yml in the repository wires up the app and the sqld sidecar together and is the fastest way to stand up any of these topologies.