Deploying Mirth Connect on AWS and Azure
Running Mirth Connect on AWS or Azure can improve reliability, scalability and disaster recovery, but only when the deployment is designed for healthcare traffic from the start. Taction Software builds Mirth cloud deployments with the right compute sizing, managed databases, isolated networks for inbound MLLP, TLS, secrets management, encrypted backups and key rotation. We use only HIPAA-eligible services under a signed Business Associate Agreement, because a technically correct deployment on non-eligible services is still non-compliant. Plan your Mirth cloud migration with our team today.
Reference Architecture for Mirth Connect on AWS
A production Mirth Connect AWS deployment typically runs on EC2 instances inside a private VPC, backed by a managed PostgreSQL database and protected by tightly scoped security groups. Inbound HL7 connections arrive through site-to-site VPNs or private connectivity, never directly over the public internet. Secrets, certificates and backups use managed AWS services. This reference design balances reliability, security and cost for most hospital, lab and healthtech integration environments we support today.
Compute Sizing on EC2
Start with memory-optimized instances sized for Java heap, channel count and peak message volume. Load test with realistic traffic, then right-size, because undersized instances cause slow processing and memory failures.
Managed Database With RDS
Use Amazon RDS for PostgreSQL with Multi-AZ, encryption at rest and automated backups. A managed database removes much operational burden and gives Mirth reliable storage for messages and configuration. Test failover regularly.
Network Isolation and VPN
Place Mirth in private subnets, with inbound MLLP arriving through site-to-site VPNs from partner networks. Security groups should allow only known partner IP ranges and required ports, nothing broader. Review rules quarterly.
TLS and Certificate Management
Terminate TLS on Mirth or a network load balancer, depending on connection type, including FHIR integration endpoints. Manage certificates with AWS Certificate Manager where possible, and track expiry dates for partner-facing MLLP certificates carefully.
Secrets and Key Management
Store database credentials, API keys and certificates in AWS Secrets Manager, with encryption keys in AWS KMS. Rotate secrets on schedule, and never store credentials inside channel configurations or scripts.
Reference Architecture for Mirth Connect on Azure
A Mirth Connect Azure deployment follows the same principles with Azure-native services: virtual machines in a private virtual network, Azure Database for PostgreSQL, network security groups and VPN gateways for partner connectivity. Azure suits organizations already standardized on Microsoft infrastructure and identity. Each component must use HIPAA-eligible services covered by Microsoft's BAA, and configuration should follow the same security baseline as your other clinical workloads hosted in Azure. The main components are below.
Azure Virtual Machines
Run Mirth on memory-optimized VMs in availability zones where supported. Size for peak volume and Java heap, then monitor utilization and adjust, rather than overprovisioning permanently from the beginning. Autoscaling rarely suits Mirth.
Azure Database for PostgreSQL
Use the flexible server option with zone-redundant high availability, encryption and automated backups. Configure private access, so the database is reachable only from the Mirth virtual network and administrators. Test restores regularly.
Virtual Networks and VPN Gateways
Isolate Mirth in private subnets, connect partners through VPN Gateway or ExpressRoute, and restrict network security groups to known sources, required ports and management access through a bastion host. Document every partner tunnel.
Azure Key Vault
Store secrets, certificates and keys in Azure Key Vault, accessed through managed identities rather than stored passwords. Enable soft delete and purge protection, so keys cannot be removed accidentally. Audit access regularly.
Azure Monitor and Logging
Send Mirth logs, VM metrics and database metrics to Azure Monitor, with alerts for channel failures, resource exhaustion and security events, while keeping message content out of general logs. Retention follows policy.
HIPAA Requirements for Mirth Cloud Deployment
A Mirth cloud deployment is only compliant if every service processing or storing ePHI is covered by the provider's Business Associate Agreement and configured correctly. AWS and Microsoft both publish lists of HIPAA-eligible services, and using any service outside those lists breaks compliance, even if encryption is enabled. Cloud providers secure their infrastructure, while you remain responsible for configuration, access and monitoring, as described in HIPAA technical safeguards. Our guide to HIPAA compliance covers the broader rules.
Sign the Cloud Provider's BAA
Accept the provider's Business Associate Agreement before any ePHI enters the account. Without a signed BAA, storing or processing PHI in that cloud account is not compliant, regardless of technical controls.
Use Only HIPAA-Eligible Services
Check every service against the provider's current HIPAA-eligible list, including logging, monitoring and backup services. A single non-eligible service handling message content creates a compliance gap. Recheck the list whenever you add services.
Encrypt Everything
Encrypt disks, databases, backups and snapshots at rest, and encrypt all traffic in transit, including internal connections between Mirth and its database. Use customer-managed keys where policy requires it. Verify settings periodically.
Control Administrative Access
Use individual accounts, multi-factor authentication and role-based permissions for cloud consoles, servers and Mirth administration. Log all administrative actions and review them regularly for unusual activity. Remove unused accounts promptly after staff changes.
Back Up and Test Restores
Automate backups of the database, configuration exports and certificates, store them encrypted in separate locations and test restores regularly. Untested backups often fail when they are needed most. Schedule quarterly restore tests.
Running Mirth Connect in Docker
Mirth Connect Docker deployments are increasingly popular for consistency, automation and faster environment builds. Containers work well for Mirth, but the engine is stateful: it depends on a database, configuration, certificates, extensions and sometimes local files. Treating it like a stateless microservice causes lost configuration, broken channels and failed restarts. Our Mirth Connect consulting team designs container deployments that handle state correctly from day one. HL7 integration listeners need particular care.
Persistent State Caveats
Mirth configuration and messages live in the database, but extensions, custom libraries, keystores and file readers may use local paths. Mount persistent volumes for these, or containers lose them on restart.
Image Versioning
Pin Mirth image versions explicitly and build your own images with required extensions and libraries. Avoid latest tags, because unplanned upgrades can break channels during routine container restarts. Upgrade deliberately, never accidentally.
Configuration as Code
Store channel exports, code templates and environment settings in version control, and deploy them through automated pipelines. This makes environments reproducible and simplifies promotion between test and production. Rollbacks become straightforward.
Networking for MLLP Listeners
Containers must expose MLLP listener ports reliably, with stable addresses for partners. Use static networking or load balancers designed for long-lived TCP connections, not only HTTP-oriented ingress controllers. Partners need predictable endpoints.
Orchestration Considerations
Kubernetes can run Mirth, but ordered channels, clustering licences and persistent connections complicate scaling. Many teams run one Mirth container per environment, with orchestration handling restarts rather than scaling. Keep it simple.
Frequently Asked Questions
Can Mirth Connect run on AWS?
Yes. Mirth Connect runs well on AWS using EC2 instances, Amazon RDS for PostgreSQL, private VPC networking, VPN connectivity for partners, and Secrets Manager for credentials. For PHI, you must sign the AWS Business Associate Agreement and use only HIPAA-eligible services configured with encryption, access controls and logging.
Is Mirth Connect on Azure HIPAA compliant?
It can be, when configured correctly. You must accept Microsoft's Business Associate Agreement, use only HIPAA-eligible Azure services, encrypt data at rest and in transit, restrict network access, control administrative accounts and monitor activity. Azure provides compliant infrastructure, but your configuration determines whether the deployment is actually compliant.
Can Mirth Connect run in Docker?
Yes. Official and community Docker images exist, and containers improve consistency and automation. However, Mirth is stateful, so you must use an external database, persistent volumes for extensions and keystores, pinned image versions and stable networking for MLLP listeners. Treating it as stateless causes configuration loss.
How do partners connect to Mirth in the cloud?
Most partners connect through site-to-site VPNs or private connectivity services, with MLLP traffic encrypted and restricted to known IP addresses. HTTP and FHIR traffic can use TLS-protected endpoints behind load balancers. Direct unencrypted MLLP over the public internet should never be used for PHI.
What database should Mirth use in the cloud?
Use a managed PostgreSQL service, such as Amazon RDS or Azure Database for PostgreSQL, with high availability, encryption and automated backups enabled. Managed databases reduce maintenance effort and improve reliability. Avoid the default embedded database for any production environment, whether hosted in the cloud or on premise.
How long does it take to migrate Mirth to the cloud?
A straightforward migration of a single Mirth environment often takes six to twelve weeks, including architecture, network setup with partners, testing and cutover. Partner VPN coordination usually drives timelines more than technical work. Larger environments with many partners or clustering requirements typically take longer to complete safely.
Planning a Mirth Move to AWS or Azure?
Our integration engineers are ready to help. Free consultation, no obligation.