Mirth Connect Cloud Deployment 2026: AWS, Azure & Docker Production Guide

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.

New to Mirth? Start with our Mirth Connect guide: what it is, how it works, and when it fits.

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.

Watch: Running Mirth Connect in Production: Daily Checks, Backups and Runbooks (1:52).

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=require

VPC 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 Connect

ECS/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/month

Azure 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 run

Kubernetes 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: 50Gi

Health 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 the cloud via Mirth should connect via a 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-premises to the cloud, a hybrid architecture with VPN connectivity between on-premises 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 minimum

Database 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/month

The 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.

Frequently Asked Questions

Can 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-premises 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.

Related guides

This article is part of our complete guide to Mirth Connect: what Mirth Connect actually does. Related deep-dives:

• automated testing for Mirth channels
• running Mirth Connect locally
• calling HTTP APIs from Mirth Connect

Need production-grade Mirth Connect help? See our Mirth Connect integration services.