Deploying Mirth Connect on Google Cloud Platform (GCP) gives US healthtech startups on the Google stack a HIPAA-eligible integration engine with Cloud Run's pay-per-use compute, Cloud SQL's managed PostgreSQL HA, and Secret Manager for credential security — without running persistent VMs. This guide covers the complete production architecture. For the AWS equivalent, see our Mirth on AWS Terraform HA guide. For the multi-cloud comparison, see the AWS vs Azure vs GCP healthcare architecture guide.
GCP vs AWS for Mirth Connect: The Key Difference
AWS defaults to persistent VMs (EC2) or task-based containers (ECS). GCP's Cloud Run is serverless containers that scale to zero. For Mirth Connect, Cloud Run requires --min-instances 1 for any channel with persistent MLLP connections — instances that scale to zero cannot accept incoming TCP. For HTTP-only Mirth channels, scaling to zero is fine and significantly reduces cost during low-traffic periods. Variable-load hospitals (busy during business hours, quiet overnight) typically save 30–40% vs EC2 running 24/7.
Containerizing Mirth Connect for Cloud Run
FROM eclipse-temurin:17-jre-jammy
WORKDIR /opt/connect
# Copy Mirth installation (or OIE/BridgeLink)
COPY connect/ /opt/connect/
COPY custom-libs/ /opt/connect/custom-lib/
EXPOSE 8080 8443 6661
ENV DATABASE_URL="" DATABASE_USER="" DATABASE_PASSWORD=""
CMD ["./mcserver", "-console"]# Build and push to Artifact Registry
gcloud auth configure-docker us-central1-docker.pkg.dev
docker build -t us-central1-docker.pkg.dev/PROJECT/healthcare/mirth:latest .
docker push us-central1-docker.pkg.dev/PROJECT/healthcare/mirth:latestCloud SQL PostgreSQL HA Setup
Never use the embedded Derby database in production — it will corrupt under load. Cloud SQL PostgreSQL 15 with Regional HA (primary + standby in different zones, automatic failover) is the correct backend. Set private IP only — no public exposure:
gcloud sql instances create mirth-db \
--database-version=POSTGRES_15 \
--tier=db-custom-2-7680 \
--region=us-central1 \
--availability-type=REGIONAL \
--backup-start-time=03:00 \
--enable-point-in-time-recovery \
--network=projects/PROJECT/global/networks/healthcare-vpc \
--no-assign-ipSecret Manager for Credentials
Never hardcode database passwords or API keys in container images. Use GCP Secret Manager and reference secrets as environment variables in the Cloud Run deployment:
echo -n 'your-db-password' | gcloud secrets create mirth-db-password --data-file=-
gcloud secrets add-iam-policy-binding mirth-db-password \
--member='serviceAccount:mirth-sa@PROJECT.iam.gserviceaccount.com' \
--role='roles/secretmanager.secretAccessor'Cloud Run Deployment
gcloud run deploy mirth-connect \
--image us-central1-docker.pkg.dev/PROJECT/healthcare/mirth:latest \
--platform managed --region us-central1 \
--min-instances 1 \
--max-instances 4 \
--memory 4Gi --cpu 2 \
--vpc-connector healthcare-connector \
--service-account mirth-sa@PROJECT.iam.gserviceaccount.com \
--set-secrets DATABASE_PASSWORD=mirth-db-password:latest \
--no-allow-unauthenticatedThe --min-instances 1 is critical for MLLP channels. For security hardening of the deployed Mirth instance, see our Mirth Connect security 2026 guide.
HIPAA BAA and GCP Healthcare Coverage
GCP's HIPAA BAA covers the services this architecture uses: Cloud Run, Cloud SQL, Secret Manager, Cloud KMS, Cloud Storage, and Cloud Audit Logs. Required HIPAA configuration: enable CMEK (Customer-Managed Encryption Keys) for Cloud SQL and Storage, configure VPC Service Controls to create a security perimeter, and enable Cloud Audit Logs for Admin Activity and Data Access on all services. For in-flight message disaster recovery, see our Mirth Connect disaster recovery guide.
