Running Mirth Connect on Kubernetes without regrets
Putting Mirth Connect in a container is a first-afternoon task. Running it reliably on Kubernetes — where interfaces carry orders and results that cannot be silently dropped — is where the details start to bite. Here is what to get right before you point a hospital feed at it.
Why Kubernetes for an interface engine — and the caveats
Kubernetes gives you repeatable deployments, self-healing pods, rolling updates, and horizontal scale. Those are real benefits for an interface engine. But Mirth is fundamentally stateful: channels have queues, some message flows must stay strictly ordered, and the engine keeps a message store. Kubernetes rewards stateless services; treat Mirth as the stateful exception it is, and most of the pitfalls disappear.
Persist the right things — outside the pod
Do not run Mirth's configuration and message database inside the container. Point Mirth at an external, managed PostgreSQL (RDS, Cloud SQL, or a managed instance) so that pods stay disposable and your data survives a restart, a reschedule, or a node failure. Keep any file-based appdata and custom libraries on a persistent volume or, better, baked into the image and mounted read-only. The rule of thumb: a pod should be able to die at any moment without losing a message.
Respect statefulness and message ordering
This is where teams get burned. If a channel must preserve order (many ADT and result flows do), you cannot simply set a HorizontalPodAutoscaler to three replicas and expect correctness — multiple engines consuming the same source will interleave or double-process. Options that work: run a single active engine with a well-provisioned pod, split high-volume unordered channels onto their own scalable deployment, or put a proper queue (with partitioning by patient or facility) in front. Decide ordering requirements per channel, not for the cluster as a whole. A StatefulSet with a controlled update strategy is usually a better fit than a Deployment here.
Health checks that mean something
A TCP check on the port only proves the JVM is up. Point your readiness and liveness probes at something that reflects the engine actually working — the Mirth API or a lightweight status channel — so Kubernetes doesn't route MLLP traffic to a pod that is still deploying channels or has a stuck database connection. Give the container a generous startup probe; Mirth can take a while to redeploy channels on boot, and an impatient liveness probe will restart it in a loop.
Channels as code, not clicks
Clicking channels together in the Administrator does not survive a pod being rebuilt. Export channels and code templates as XML, keep them in Git, and deploy them through the Mirth CLI or REST API as a step in your CI/CD pipeline. Now a fresh pod comes up with exactly the channels that are in source control, promotion between environments is a pipeline run, and you have an audit trail of every interface change — which your compliance programme will also thank you for.
Secrets, TLS, and certificate rotation
Database credentials, keystore passwords, and API keys belong in Kubernetes Secrets sourced from a real secrets manager (External Secrets Operator or Vault), never in the image or a ConfigMap. Terminate MLLP over TLS for any traffic leaving the cluster, and plan certificate rotation — automated renewal beats a 2 a.m. outage when a cert quietly expires.
See what the engine is doing
The metrics that matter for an interface engine are not CPU and memory — they are queued messages, errored messages, and processing latency per channel. Expose Mirth's metrics, ship logs to a central store (Loki, CloudWatch, or your stack of choice), and alert on a growing error queue rather than waiting for a clinician to phone in that results stopped arriving. Pair that with zero-downtime rolling deploys and a rehearsed disaster-recovery restore of the config database, and you have an interface platform that is genuinely production-grade.
Modernising a Mirth deployment? We run Mirth Connect on Kubernetes across AWS, Azure, GCP, and OVHcloud. See our cloud & DevOps work or talk to an engineer →