Docker deployment gives Mirth Connect consistent environments across dev/staging/production, easier horizontal scaling, and faster disaster recovery from a known image. A production-ready setup needs persistent volumes for the database and configuration, externalized configuration via environment variables, real health checks, and logs shipped outside the container. The single most damaging mistake is running the database inside the container without a persistent volume — a restart or redeploy can silently wipe message history and configuration entirely.
Quick answer
Mirth Connect Docker deployment offers real advantages over a traditional installation, but it also introduces specific pitfalls that catch teams off guard when they treat a container deployment exactly like a traditional server install without accounting for what's genuinely different underneath. Getting the setup right the first time avoids common issues like lost data on container restart or resource limits that quietly throttle performance under real load.
Below is why teams choose Docker for Mirth, how to build a genuinely production-ready setup, and the pitfalls that trip up new deployments most often. Our free Mirth Health Check can review your container setup — part of the Mirth Connect support work we do for US healthcare teams.
Why Run Mirth Connect in Docker at All
Docker deployment offers genuine operational advantages over a traditional installation, particularly for teams already running other infrastructure in containers or needing to reproduce identical environments reliably across development, staging, and production.
Consistent Environments Across Every Stage
A containerized Mirth deployment behaves identically across development, staging, and production, eliminating the "it worked on my machine" class of problems that plague traditional installs with subtly different configurations between environments.
Easier Horizontal Scaling When Needed
Container orchestration platforms make it more straightforward to scale Mirth horizontally by running multiple container instances, compared to manually provisioning and configuring additional traditional servers each time you need more capacity.
Simplified, More Predictable Upgrades
Upgrading a containerized Mirth deployment often means simply deploying a new image version, which is more predictable and easier to roll back than an in-place upgrade on a traditional server installation.
Faster Disaster Recovery From a Known Image
Since the container image itself defines the application environment precisely, rebuilding a failed deployment from that same image is faster and more consistent than manually reinstalling and reconfiguring a traditional server from scratch.
Building a Genuinely Production-Ready Docker Setup
A Docker deployment that works in initial testing can still have serious gaps that only surface once real production data and load hit it, so building the setup correctly from the start matters considerably.
Configure Persistent Volumes for All Critical Data
Mount persistent volumes for the database, configuration, and any other data that must survive a container restart, since anything written inside the container's own filesystem without a volume is lost the moment the container restarts.
Use Environment Variables for Configuration
Externalize configuration through environment variables rather than baking settings into the image itself, which keeps the same image portable across environments and avoids rebuilding the image just to change a configuration value.
Implement Proper Health Checks for the Container
Configure container health checks that genuinely verify Mirth is functioning correctly, not just that the process is running, so your orchestration platform can detect and respond to a genuinely unhealthy container appropriately.
Send Logs to a Destination Outside the Container
Configure logging to write to a location outside the container itself, or to a centralized logging system, since container logs can be lost entirely if the container is destroyed and recreated without proper log persistence. See our log file locations guide for what to persist.
Common Docker Deployment Pitfalls to Avoid
Several specific mistakes account for most of the problems teams encounter running Mirth in Docker, and knowing about them in advance saves significant troubleshooting time down the road once you're already in production.
Forgetting Persistent Storage for the Database
The single most damaging mistake is running the database inside the container without a persistent volume, which means a container restart or redeployment can wipe out message history and configuration entirely without warning.
Setting Resource Limits Too Low for Real Load
Container resource limits configured based on light testing can throttle performance badly once real production message volume hits the deployment, so size memory and CPU limits based on realistic, not idealized, load testing.
Not Externalizing the Database From the Container
Running the database inside the same container as the Mirth application couples their lifecycles together unnecessarily, making it harder to scale, back up, or maintain either component independently of the other.
Ignoring Container Security Updates Over Time
A container image that's never rebuilt with updated base layers can accumulate known security vulnerabilities over time, so establish a regular process for rebuilding images with current, patched base layers rather than leaving them static indefinitely.
When to call for help
If your Docker deployment isn't behaving as expected, the cause is almost always one of the four pitfalls above rather than something exotic. Our free Mirth Connect health check reviews your container setup as part of the standard diagnostic.
Troubleshooting something specific? Send us the log, or check pricing for ongoing support plans.
Docker deployment not behaving as expected? Free Mirth health check — a written 12-point audit report in 48 hours, no cost.