For the past decade, most Mirth Connect deployments lived on a single Windows server in a hospital data center. A dedicated VM, maybe a physical server, running Mirth with an embedded Derby database or a local PostgreSQL instance. This approach works until it does not: the server fails at 2 AM, the database fills up over a holiday weekend, or the hospital merges with another health system and suddenly needs to process three times the message volume with zero downtime.
Cloud deployment solves these problems, but it introduces new ones. AWS, Azure, and containerized deployments offer scalability, high availability, and disaster recovery that on-premise installations struggle to match, but they also require different expertise, different security models, and different cost structures. According to a HIMSS survey, over 80% of healthcare organizations are now using or planning to use cloud infrastructure for clinical applications, and integration engines are a natural fit for this migration.
This guide covers the complete spectrum of cloud deployment for Mirth Connect: from a simple Docker Compose setup for development to production-grade Kubernetes clusters on AWS and Azure. Whether you are a DevOps engineer moving your first Mirth instance to the cloud or a cloud architect designing a multi-region integration platform, this guide provides the architecture patterns, configuration details, and cost analysis you need to make informed decisions.
Why Move Mirth Connect to the Cloud
The business case for cloud Mirth deployment rests on four pillars:
Scalability on Demand
On-premise Mirth servers have fixed capacity. When message volume spikes, whether from a seasonal flu surge, a new integration partner, or a hospital merger, you are limited by the hardware you purchased 18 months ago. Cloud instances can be right-sized in minutes. Vertical scaling (bigger instances) handles immediate spikes. Horizontal scaling (multiple Mirth nodes behind a load balancer) handles sustained growth.
High Availability Without Complexity
Building high availability for on-premise Mirth requires redundant hardware, shared storage, database clustering, and load balancers, all managed by your team. Cloud providers offer these as managed services. AWS RDS Multi-AZ gives you automatic database failover. Application Load Balancers distribute traffic across Mirth instances. Auto Scaling Groups replace failed instances automatically. The result is better availability with less operational burden.
Disaster Recovery
On-premise disaster recovery means maintaining a second data center with replicated infrastructure. Cloud disaster recovery means cross-region database replicas and infrastructure-as-code that can rebuild your entire environment in a different region within hours. The cost difference is dramatic: maintaining a warm DR site on-premise costs $50,000-$100,000+ per year, while cross-region backups in the cloud cost a fraction of that.
Cost Optimization
Cloud deployment shifts capital expenditure (buying servers) to operational expenditure (monthly service fees). For many organizations, this is not just a financial preference but a strategic advantage: you pay for what you use, scale down during low-traffic periods, and avoid the depreciation cycle of hardware that is obsolete before it is fully amortized.
Architecture Patterns
Cloud Mirth deployments fall into three patterns, each appropriate for different use cases:
Pattern 1: Single Instance (Development / Test)
One Mirth Connect instance on a cloud VM or container, with a managed database. Simple, inexpensive, and appropriate for development environments, proof-of-concept deployments, and small organizations with low message volumes (under 1,000 messages per hour).
Pattern 2: Clustered Production
Multiple Mirth Connect instances behind a load balancer, sharing a managed database. Provides high availability and horizontal scalability. Appropriate for production deployments processing 1,000 to 50,000+ messages per hour. This is the most common production architecture.
Pattern 3: Fully Managed / Kubernetes
Mirth deployed as containerized workloads on Kubernetes (EKS, AKS, or self-managed). Provides maximum scalability, automated recovery, and infrastructure-as-code deployment. Appropriate for organizations with existing Kubernetes expertise and large-scale integration platforms.
AWS Deployment
AWS is the most common cloud platform for healthcare integration, offering a mature ecosystem of HIPAA-eligible services.
EC2 Instance Sizing
# Recommended EC2 instance types for Mirth Connect:
Development / Test:
t3.medium (2 vCPU, 4 GB RAM) ~$30/month
Handles: Up to 500 msg/hour, 5-10 channels
Small Production:
m6i.large (2 vCPU, 8 GB RAM) ~$70/month
Handles: Up to 2,000 msg/hour, 20-30 channels
Medium Production:
m6i.xlarge (4 vCPU, 16 GB RAM) ~$140/month
Handles: Up to 10,000 msg/hour, 50-100 channels
Large Production:
m6i.2xlarge (8 vCPU, 32 GB RAM) ~$280/month
Handles: Up to 30,000+ msg/hour, 100+ channels
# Key: Mirth is memory-intensive. Prioritize RAM over CPU.
# The Mirth JVM heap should be set to 60-70% of available RAM.RDS PostgreSQL for Mirth Database
AWS RDS for PostgreSQL eliminates database management overhead. For production Mirth deployments, a db.m6g.large or db.m6g.xlarge instance provides adequate performance at approximately $200-$500 per month, depending on storage and IOPS requirements.
# RDS Configuration for Mirth Connect:
Instance: db.m6g.large (2 vCPU, 8 GB RAM)
Storage: 100 GB gp3 (3,000 IOPS baseline)
Multi-AZ: Enabled (automatic failover)
Encryption: Enabled (AES-256, AWS KMS)
Backup: 7-day automated backups
Maintenance: Weekly window (Sunday 3-4 AM)
# Connection string for Mirth:
# jdbc:postgresql://mirth-db.xxxxx.us-east-1.rds.amazonaws.com:5432/mirthdb
# IMPORTANT: Enable SSL for database connections
# Set database.url parameter to include ?ssl=true&sslmode=requireVPC and Security Groups
# VPC Architecture for Mirth Connect on AWS:
VPC: 10.0.0.0/16
Public Subnets (for ALB):
10.0.1.0/24 (us-east-1a)
10.0.2.0/24 (us-east-1b)
Private Subnets (for Mirth EC2/ECS):
10.0.10.0/24 (us-east-1a)
10.0.11.0/24 (us-east-1b)
Database Subnets (for RDS):
10.0.20.0/24 (us-east-1a)
10.0.21.0/24 (us-east-1b)
Security Groups:
sg-alb: Inbound 443 from hospital VPN IPs only
sg-mirth: Inbound 8443 from sg-alb, MLLP ports from VPN
sg-rds: Inbound 5432 from sg-mirth only
# CRITICAL: Never expose Mirth admin (8443) to the internet
# CRITICAL: MLLP ports should only be accessible via VPN or Direct ConnectECS/Fargate for Containerized Deployment
For organizations preferring containers over VMs, AWS ECS with Fargate provides serverless container execution:
# ECS Task Definition for Mirth Connect:
{
"family": "mirth-connect",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "2048",
"memory": "8192",
"containerDefinitions": [
{
"name": "mirth",
"image": "nextgenhealthcare/connect:4.5.0",
"portMappings": [
{"containerPort": 8443, "protocol": "tcp"},
{"containerPort": 6661, "protocol": "tcp"}
],
"environment": [
{"name": "DATABASE", "value": "postgres"},
{"name": "DATABASE_URL", "value": "jdbc:postgresql://mirth-db.xxxxx.rds.amazonaws.com:5432/mirthdb"},
{"name": "VMOPTIONS", "value": "-Xmx5g -Xms2g"}
],
"secrets": [
{"name": "DATABASE_USERNAME", "valueFrom": "arn:aws:ssm:...:mirth-db-user"},
{"name": "DATABASE_PASSWORD", "valueFrom": "arn:aws:ssm:...:mirth-db-pass"}
],
"healthCheck": {
"command": ["CMD-SHELL", "curl -ks https://localhost:8443/api/server/status || exit 1"],
"interval": 30,
"timeout": 5,
"retries": 3
},
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/mirth-connect",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "mirth"
}
}
}
]
}Azure Deployment
Azure offers comparable services for Mirth Connect deployment, with strong integration into Microsoft-centric healthcare IT environments.
VM Sizing on Azure
# Recommended Azure VM sizes for Mirth Connect:
Development / Test:
Standard_B2s (2 vCPU, 4 GB RAM) ~$35/month
Small Production:
Standard_D2s_v5 (2 vCPU, 8 GB RAM) ~$75/month
Medium Production:
Standard_D4s_v5 (4 vCPU, 16 GB RAM) ~$150/month
Large Production:
Standard_D8s_v5 (8 vCPU, 32 GB RAM) ~$300/monthAzure Database for PostgreSQL
Azure Database for PostgreSQL Flexible Server is the managed database option for Azure deployments. Configure with zone-redundant high availability for production workloads.
Azure Kubernetes Service (AKS)
For containerized Mirth on Azure, AKS provides managed Kubernetes with integrated monitoring via Azure Monitor and Container Insights.
Docker Deployment Fundamentals
Whether you deploy on AWS, Azure, or a local development machine, Docker is the foundation for containerized Mirth. The official nextgenhealthcare/connect image on Docker Hub provides a production-ready Mirth Connect container.
Docker Compose for Development
# docker-compose.yml - Development Mirth Connect
version: '3.8'
services:
mirth:
image: nextgenhealthcare/connect:4.5.0
container_name: mirth-connect
ports:
- "8443:8443" # Mirth Admin/API
- "8080:8080" # HTTP Listener
- "6661:6661" # MLLP Port 1
- "6662:6662" # MLLP Port 2
environment:
- DATABASE=postgres
- DATABASE_URL=jdbc:postgresql://postgres:5432/mirthdb
- DATABASE_USERNAME=mirth
- DATABASE_PASSWORD=mirth
- DATABASE_MAX_CONNECTIONS=20
- VMOPTIONS=-Xmx4g -Xms1g
- KEYSTORE_STOREPASS=changeme
- KEYSTORE_KEYPASS=changeme
volumes:
- mirth-appdata:/opt/connect/appdata
- mirth-custom-lib:/opt/connect/custom-lib
depends_on:
postgres:
condition: service_healthy
restart: unless-stopped
postgres:
image: postgres:15
container_name: mirth-postgres
environment:
- POSTGRES_DB=mirthdb
- POSTGRES_USER=mirth
- POSTGRES_PASSWORD=mirth
volumes:
- mirth-pgdata:/var/lib/postgresql/data
ports:
- "5432:5432"
healthcheck:
test: ["CMD-SHELL", "pg_isready -U mirth -d mirthdb"]
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
volumes:
mirth-appdata:
mirth-custom-lib:
mirth-pgdata:Environment Variables Reference
# Essential environment variables for Mirth Docker container:
DATABASE # Database type: postgres, mysql, sqlserver, oracle
DATABASE_URL # JDBC connection string
DATABASE_USERNAME # Database user
DATABASE_PASSWORD # Database password
DATABASE_MAX_CONNECTIONS # Connection pool size (default: 20)
VMOPTIONS # JVM arguments (-Xmx, -Xms, GC options)
KEYSTORE_STOREPASS # Keystore password for TLS
KEYSTORE_KEYPASS # Key password for TLS
MIRTH_ADMIN_PASSWORD # Override default admin password on first runKubernetes Deployment
StatefulSet Configuration
Mirth Connect should be deployed as a StatefulSet (not a Deployment) in Kubernetes because each instance maintains state in its appdata directory and requires stable network identities for channel configuration.
# mirth-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mirth-connect
namespace: healthcare-integration
spec:
serviceName: mirth-connect
replicas: 2
selector:
matchLabels:
app: mirth-connect
template:
metadata:
labels:
app: mirth-connect
spec:
containers:
- name: mirth
image: nextgenhealthcare/connect:4.5.0
ports:
- containerPort: 8443
name: admin-api
- containerPort: 6661
name: mllp-1
env:
- name: DATABASE
value: "postgres"
- name: DATABASE_URL
value: "jdbc:postgresql://mirth-db-svc:5432/mirthdb?ssl=true"
- name: DATABASE_USERNAME
valueFrom:
secretKeyRef:
name: mirth-db-credentials
key: username
- name: DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: mirth-db-credentials
key: password
- name: VMOPTIONS
value: "-Xmx5g -Xms2g -XX:+UseG1GC"
resources:
requests:
memory: "6Gi"
cpu: "1000m"
limits:
memory: "8Gi"
cpu: "4000m"
readinessProbe:
exec:
command:
- /bin/sh
- -c
- "curl -ks https://localhost:8443/api/server/status"
initialDelaySeconds: 60
periodSeconds: 15
livenessProbe:
exec:
command:
- /bin/sh
- -c
- "curl -ks https://localhost:8443/api/server/status"
initialDelaySeconds: 120
periodSeconds: 30
volumeMounts:
- name: mirth-appdata
mountPath: /opt/connect/appdata
volumeClaimTemplates:
- metadata:
name: mirth-appdata
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: gp3
resources:
requests:
storage: 50GiHealth Checks and Horizontal Scaling
Configure readiness probes to ensure traffic is only sent to fully started Mirth instances (Mirth can take 60-120 seconds to start), and liveness probes to restart instances that become unresponsive. For horizontal scaling, use the Horizontal Pod Autoscaler based on CPU or custom metrics from Mirth monitoring endpoints.
Network and Security
TLS Termination
Terminate TLS at the load balancer or ingress controller, not at the Mirth instance. This simplifies certificate management (use AWS Certificate Manager or Azure Key Vault) and offloads TLS processing from the Mirth JVM. However, ensure internal traffic between the load balancer and Mirth instances is also encrypted, either via TLS or by running within a private network.
VPN and Private Connectivity
Hospital systems sending HL7 messages to cloud Mirth should connect via VPN (AWS Site-to-Site VPN or Azure VPN Gateway) or dedicated connectivity (AWS Direct Connect or Azure ExpressRoute). MLLP traffic should never traverse the public internet unencrypted. For organizations transitioning from on-premise to cloud, a hybrid architecture with VPN connectivity between on-premise and cloud Mirth instances is a common intermediate step.
No Public-Facing Mirth API
The Mirth Connect admin API (port 8443) should never be accessible from the internet. Restrict access to internal networks, VPN connections, and specific IP addresses. Use a bastion host or VPN for remote administration. This is not optional; it is a critical security requirement given recent Mirth CVEs that allowed unauthenticated remote code execution via the admin API.
HIPAA Compliance in the Cloud
Encryption Requirements
HIPAA requires encryption for Protected Health Information (PHI) both in transit and at rest:
- In transit: TLS 1.2 or higher for all connections. This includes load balancer to Mirth, Mirth to database, Mirth to external systems, and MLLP connections (use MLLP over TLS).
- At rest: Enable encryption on EBS volumes (AES-256), RDS storage encryption (AWS KMS), S3 bucket encryption for backups, and Kubernetes persistent volume encryption.
Access Logging
Enable comprehensive access logging: AWS CloudTrail for API calls, VPC Flow Logs for network traffic, RDS audit logging for database access, and Mirth Connect's built-in audit logging for message-level tracking. Retain logs for a minimum of 6 years per HIPAA requirements.
Business Associate Agreement (BAA)
Both AWS and Azure offer HIPAA Business Associate Agreements (BAAs) that cover their managed services. Ensure every cloud service used in your Mirth deployment is covered by the BAA. Services not covered by the BAA should not process or store PHI.
Performance in the Cloud
Instance Sizing Guidelines
Mirth Connect is memory-bound, not CPU-bound, for most workloads. The JVM heap size determines how many messages can be processed concurrently and how large the message queues can grow. Use the following as starting points and adjust based on performance monitoring data:
# Sizing formula (approximate):
# Base memory: 2 GB (Mirth + OS)
# Per active channel: 50-100 MB
# Per 1,000 queued messages: 100-200 MB
# Buffer: 20% headroom
# Example: 50 channels, 5,000 queued messages
# 2 GB + (50 * 75 MB) + (5 * 150 MB) + 20% buffer
# = 2 GB + 3.75 GB + 0.75 GB + 1.3 GB = ~8 GB RAM minimumDatabase IOPS
Mirth's database performance directly affects message throughput. Every message processed involves multiple database writes (message content, metadata, status updates). For high-throughput deployments, provision dedicated IOPS (io2 on AWS, Premium SSD on Azure) rather than relying on burstable performance (gp3 baseline).
Network Latency
For MLLP connections from on-premise systems to cloud Mirth, network latency is critical. Each HL7 message requires a TCP connection, message send, and ACK response. At 50ms round-trip latency, you can process roughly 20 synchronous messages per second per connection. Use connection pooling and multiple MLLP channels for high-throughput interfaces where latency is a factor.
Cost Comparison
# Monthly Cost Comparison (Medium Production - 50 channels, 10K msg/hour):
On-Premise:
Server hardware (amortized) $500/month
Database server (amortized) $300/month
Network equipment $100/month
Power / Cooling $200/month
Backup infrastructure $150/month
Staff time (20 hrs/month) $3,000/month
Total: ~$4,250/month
AWS:
EC2 m6i.xlarge (Reserved 1yr) $100/month
RDS db.m6g.large (Multi-AZ) $350/month
ALB $25/month
EBS storage (200 GB gp3) $20/month
Data transfer $50/month
CloudWatch $30/month
VPN connection $40/month
Staff time (8 hrs/month) $1,200/month
Total: ~$1,815/month
Azure:
D4s_v5 VM (Reserved 1yr) $110/month
Azure DB PostgreSQL (HA) $370/month
Load Balancer $30/month
Managed Disks (200 GB) $25/month
Data transfer $50/month
Azure Monitor $35/month
VPN Gateway $140/month
Staff time (8 hrs/month) $1,200/month
Total: ~$1,960/month
Managed Service (Vendor-Hosted):
Subscription $3,000-5,000/month
Staff time (4 hrs/month) $600/month
Total: ~$3,600-5,600/monthThe cloud options provide 50-60% cost savings over on-premise, primarily through reduced staff time (managed services eliminate database administration, backup management, and hardware maintenance) and elimination of capital expenditure. The managed service option costs more than self-managed cloud but requires the least internal expertise.
High Availability Architecture
Multi-AZ Deployment
Deploy Mirth instances across at least two Availability Zones. The load balancer routes traffic to healthy instances in either zone. If one zone fails, traffic automatically shifts to the surviving zone. RDS Multi-AZ provides automatic database failover with a typical recovery time of 60-120 seconds.
RTO and RPO Targets
# Typical Recovery Objectives for Healthcare Integration:
Component RTO RPO
--------- --- ---
Mirth Application 5 minutes 0 (stateless with shared DB)
Database 2 minutes 0 (synchronous Multi-AZ)
Message Queues 5 minutes 1 minute (journal to DB)
Configuration 15 minutes 24 hours (daily config backup)
Full Environment 1 hour 1 hour (cross-region restore)
# RTO = Recovery Time Objective (max downtime)
# RPO = Recovery Point Objective (max data loss)Monitoring in the Cloud
CloudWatch / Azure Monitor Integration
Forward Mirth Connect logs to the cloud provider's logging service for centralized analysis. Key metrics to monitor include: JVM heap usage (alert at 80%), message queue depth (alert at configurable threshold), channel error rates (alert on any sustained errors), database connection pool utilization (alert at 80%), and CPU/memory at the instance level.
Container Metrics
For Kubernetes deployments, use container-native monitoring (Prometheus + Grafana or cloud-native tools like Container Insights) to track pod resource usage, restart counts, and scaling events. Combine with Mirth-specific metrics from the admin API for a complete operational picture.
Disaster Recovery
Cross-Region Backup Strategy
Replicate database backups to a secondary region using RDS cross-region read replicas or automated snapshot copying. Store Mirth configuration exports (channel XML, code templates, global scripts) in S3/Azure Blob Storage with cross-region replication. Maintain infrastructure-as-code (Terraform, CloudFormation, or ARM templates) that can rebuild the entire Mirth environment in a secondary region within hours.
Testing DR Plans
Quarterly DR drills are essential. Simulate a region failure and verify that the team can restore the Mirth environment in the secondary region within the target RTO. Document the procedure, time each step, and identify bottlenecks. A DR plan that has never been tested is not a DR plan; it is a hope.
From architecture to production, our Healthcare Software Product Development team builds healthcare platforms that perform at scale. We also offer specialized Healthcare Interoperability Solutions services. Talk to our team to get started.
Frequently Asked QuestionsCan I use the free tier of AWS or Azure to run Mirth Connect?
For development and learning, yes. The AWS free tier includes a t2.micro instance (1 vCPU, 1 GB RAM) and a db.t3.micro RDS instance, which can run Mirth Connect with 2-3 channels and low message volume. This is suitable for training new engineers or prototyping integrations. It is not suitable for any production workload. Production Mirth requires at least 4 GB of RAM for the JVM, and the database needs adequate IOPS for message persistence.
How do I migrate existing channels from on-premise Mirth to cloud Mirth?
Export channels from the source Mirth instance via the admin API or Mirth Administrator (Channels > Export All Channels). Import into the cloud Mirth instance. Update connection parameters (database URLs, MLLP hostnames, file paths) to reflect the cloud environment. Test thoroughly in a staging environment before cutting over. For the database, use pg_dump/pg_restore to migrate the Mirth database if you need message history. For a clean start, deploy to a fresh database and re-import channels.
Is Docker or VM deployment better for production Mirth?
Both are viable for production. VM deployment is simpler, requires less specialized knowledge, and is a natural migration from on-premise. Docker/Kubernetes deployment provides better resource utilization, faster scaling, and infrastructure-as-code benefits but requires container orchestration expertise. If your team already operates Kubernetes, deploy Mirth on Kubernetes. If your team is new to containers, start with VMs and migrate to containers when the team is ready. The Mirth application itself runs identically in both environments.
What about Mirth Connect licensing in the cloud?
Mirth Connect is open source (MPL 2.0 license) and can be deployed in any cloud environment without licensing fees from NextGen Healthcare. The nextgenhealthcare/connect Docker image on Docker Hub is the official distribution. If you need commercial support, NextGen offers support contracts that cover cloud deployments. The license does not change based on deployment target: on-premise, cloud VM, and containerized deployments all use the same open-source license.
How do I handle MLLP connections from on-premise systems to cloud Mirth?
MLLP traffic must be secured in transit. The recommended approaches are: (1) AWS Site-to-Site VPN or Azure VPN Gateway, establishing an encrypted tunnel between your on-premise network and the cloud VPC. MLLP traffic flows through the tunnel without modification. (2) MLLP over TLS (also called Secure MLLP), where the Mirth source connector is configured for TLS and the sending system supports TLS-wrapped MLLP. (3) AWS Direct Connect or Azure ExpressRoute for dedicated, private connectivity. Never send unencrypted MLLP traffic over the public internet, as this violates HIPAA transmission security requirements.
The Bottom Line
Moving Mirth Connect to the cloud is not just an infrastructure decision; it is a reliability and scalability decision. Cloud deployment reduces the operational burden of maintaining high availability, simplifies disaster recovery, and provides the elasticity to handle growing message volumes without hardware procurement cycles.
Start with Docker Compose for development and testing. Graduate to a managed VM or ECS/AKS deployment for production. Use managed databases (RDS, Azure Database for PostgreSQL) to eliminate database administration overhead. Implement proper network security with VPN connectivity and never expose the Mirth admin API to the internet.
The cloud does not eliminate the need for monitoring, performance tuning, or operational expertise. But it does let your team focus on what matters most: building and maintaining the integrations that move patient data reliably between systems, rather than managing the infrastructure underneath.
