I’ve been working on an open-source web-based management GUI for Mailcow called MOCA (Mail Operations Centre AI), designed specifically for home lab operators and small teams running Mailcow in a stand-alone or hot/cold high-availability configuration. The goal was simple: make it possible for a non-technical person to diagnose and recover mail service(s) through a browser interface, without needing to SSH into a server or understand Docker. MOCA runs as a lightweight Flask application on a dedicated management host, communicates with your mail nodes through a hardened SSH wrapper architecture, and presents a clean real-time dashboard showing cluster health, container status, certificate expiry, mail sync freshness, and VRRP state across both nodes simultaneously.
The HA architecture is intentionally pragmatic. Rather than requiring shared storage, synchronous replication, or a quorum witness node (complexity that’s disproportionate for a two-node home lab), MOCA implements a bounded asynchronous model with a deliberate recovery point objective. SQL dumps sync hourly and maildir syncs every five minutes (configurable) via cron-driven rsync with a dual-signal safety gate (both VIP presence and role file must independently agree before any data is pushed outward, protecting against VRRP timing races and GUI desync). Automatic failover is keepalived-driven with a configurable bounce-protection window, and optional ntfy.sh alerting at three severity tiers, as well as a strict rule that promotion back to the original primary is always a deliberate (manual) human action, never automatic. A built-in mailbox reconciliation tool performs a bidirectional union merge after recovery, on the principle that a duplicate email is always preferable to a missing one.
The security model was designed with community deployment in mind. All automation communicates with mail hosts through whitelisted SSH wrapper commands, i.e. no raw shell access from the web application. The wrapper architecture distinguishes read-only status commands from write operations, and reserves promotion and demotion scripts as Level 4 human-only actions with no automation path. (Optional) NAS integration supports three modes (TrueNAS REST API, SSH/rsync, or NFS mount) for heartbeat and backup storage, with API tokens read inline at call time and never exported to the process environment. The Flask service is intended to run as a dedicated non-root service account, and the Settings UI masks all credentials at rest.
Before I publish, I want to be transparent about scope: MOCA is designed and tested for a two-node home lab or small-scale deployment where the operator already trusts everyone with network access to the management host. It is not hardened for internet-facing or multi-tenant deployment without additional work (authentication layer, production WSGI server, further privilege separation). I’m planning to share this in the spirit of “this solved my problem and might solve yours,” with honest documentation about the tradeoffs made. If there’s interest from the community, I’d love feedback on the architecture, help testing against different Mailcow versions, and contributions toward the items still on the roadmap, particularly the keepalived auto-failover hardening and the community release prep items like sanitizing the default configuration and writing proper setup documentation.
Let me know what you think.