Summary
Add official Kubernetes support for Mailcow, including a maintained Helm chart and deployment documentation. Currently Mailcow is exclusively supported via Docker Compose, leaving Kubernetes users without an official path to deploy and operate Mailcow on their clusters.
Motivation
Docker Compose ties the entire Mailcow stack to a single machine with no native high-availability, automatic rescheduling, or resource management. Teams already running Kubernetes face a hard choice: maintain a fragmented, community-translated deployment that lags behind upstream, or run a separate dedicated server outside their existing infrastructure just for email.
There are currently several community Helm charts for Mailcow, which demonstrates real demand — but none are officially maintained, they diverge from upstream quickly, and users have no confidence they reflect the correct configuration. An official Helm chart would:
- Allow teams to manage email alongside the rest of their stack using the same GitOps tooling (ArgoCD, Flux, etc.)
- Enable proper resource limits, liveness/readiness probes, and pod disruption budgets per service
- Support horizontal scaling for stateless components (Rspamd, nginx, SOGo)
- Integrate with existing cluster infrastructure — ingress controllers, cert-manager, external secrets, persistent volume claims
- Remove the need for a dedicated server and separate operational runbook just for email
Additional context
The Mailcow stack maps naturally to Kubernetes primitives — each service (Postfix, Dovecot, Rspamd, ClamAV, SOGo, MySQL, Redis, nginx) already runs as an isolated Docker container, which translates directly to individual Deployments or StatefulSets. The main complexity is in the service interdependencies and volume mounts for mail storage and DKIM keys, which are well-understood Kubernetes patterns.
Mailu, a comparable open-source email stack, ships an official Helm chart and has demonstrated that this is achievable and sustainable for a project of this size. It has become the default recommendation for Kubernetes users specifically because of the lack of official Kubernetes support in Mailcow.
Summary
Add official Kubernetes support for Mailcow, including a maintained Helm chart and deployment documentation. Currently Mailcow is exclusively supported via Docker Compose, leaving Kubernetes users without an official path to deploy and operate Mailcow on their clusters.
Motivation
Docker Compose ties the entire Mailcow stack to a single machine with no native high-availability, automatic rescheduling, or resource management. Teams already running Kubernetes face a hard choice: maintain a fragmented, community-translated deployment that lags behind upstream, or run a separate dedicated server outside their existing infrastructure just for email.
There are currently several community Helm charts for Mailcow, which demonstrates real demand — but none are officially maintained, they diverge from upstream quickly, and users have no confidence they reflect the correct configuration. An official Helm chart would:
Additional context
The Mailcow stack maps naturally to Kubernetes primitives — each service (Postfix, Dovecot, Rspamd, ClamAV, SOGo, MySQL, Redis, nginx) already runs as an isolated Docker container, which translates directly to individual Deployments or StatefulSets. The main complexity is in the service interdependencies and volume mounts for mail storage and DKIM keys, which are well-understood Kubernetes patterns.
Mailu, a comparable open-source email stack, ships an official Helm chart and has demonstrated that this is achievable and sustainable for a project of this size. It has become the default recommendation for Kubernetes users specifically because of the lack of official Kubernetes support in Mailcow.