For practices and health-tech teams deciding where OpenEMR should run and who should look after it. We compare the official deployment options, give you a HIPAA hosting checklist to audit any host against, and explain what our managed hosting takes off your plate.
OpenEMR 8.5.0, the current stable release, shipped on October 27, 2026. Its notes list 84 security fixes, 6 of them critical and 32 high, including SQL injection, an OAuth scope flaw that allowed unauthenticated access to patient records, and a way to skip MFA through the password grant. It also raises the floor to PHP 8.3 and MariaDB 10.11 or MySQL 8.4, so a server on older packages needs a stack upgrade before it can take the fix.
OpenEMR costs nothing to license, but any outside party that stores its ePHI for you is a business associate. HHS says a cloud provider keeping encrypted ePHI qualifies even if it never holds the key, so a BAA is needed. The Security Rule already requires unique user IDs, audit controls, retrievable backup copies and procedures to restore lost data. HHS's January 2025 proposal to tighten the rule is not final: no final rule is in the Federal Register, and the latest regulatory agenda targets July 2027.
Hosting is only one part of running OpenEMR well. Our OpenEMR implementation and integration team handles forms, modules and interfaces; this page is about the server underneath them.
The OpenEMR project maintains each of these. Versions come from its pages and listings as checked on November 1, 2026.
The download page names the official openemr/openemr image as the recommended way to run OpenEMR, with tags up to 8.5.0. It needs a companion MySQL or MariaDB container, serves HTTPS with a self-signed certificate by default, and fetches Let's Encrypt certificates when you set the DOMAIN variable.
One EC2 instance with an embedded MariaDB server and rotated local backups, listed by the OpenEMR Foundation at 8.4.1 with no software fee. Its own documentation says covered entities may not store PHI on it, so keep it to demos and training.
The project's July 21, 2026 post says it now installs 8.2.0 on HIPAA-eligible AWS services, with KMS encryption, daily encrypted backups to S3 and CloudTrail auditing. Covered entities must accept the AWS BAA first, and the README points them to US East (N. Virginia) or US West (Oregon).
The HIPAA-eligible Marketplace edition adds an Amazon RDS database, KMS-managed S3 backups and a CloudFormation recovery stack that rebuilds the system in a fresh VPC, which makes a monthly restore drill practical.
Tarball and zip packages are still published. Choosing them means you own every layer: operating system, web server, PHP, database, TLS and backups.
| Aspect | Self-hosted | Managed by Xcodefix |
|---|---|---|
| OS, PHP and database patches | Your staff, when time allows | Our engineers, in an agreed patch window |
| OpenEMR upgrades | Tested and applied by you | Rehearsed on a staging copy, then applied |
| Backups and restore tests | Configured and checked by you | Encrypted backups with routine restore checks |
| BAA chain | You sign with your cloud provider | We sign a BAA for the hosting layer |
| Monitoring and audit logs | Whatever you set up | Continuous monitoring and audit logging |
| Security incidents | Your plan, your people | Same-day response from our team |
| Cost shape | Cloud bill plus staff hours | Fee scoped to the workload, plus cloud resources |
Managed hosting does not make a practice compliant by itself. User management, policies and how staff use OpenEMR stay with you, and we document exactly where our responsibility stops.
Audit any OpenEMR host against this list, ours included. It follows the current Security Rule at 45 CFR 164.308 and 164.312.
Your cloud platform and any managed host in between must sign one. AWS offers its standard BAA through AWS Artifact, and PHI may only live in services it lists as HIPAA-eligible.
Encryption is addressable today: you implement it or document an equivalent. In practice that means KMS-encrypted disks, database and backups, and TLS on every connection with no plain HTTP left open.
The rule requires backups you can retrieve and a written way to restore lost data; periodic testing of those plans is addressable. Restore into a separate environment on a schedule and keep the record.
Audit controls are a required standard. Keep OpenEMR's own logs, database and OS logs and cloud API logs such as CloudTrail, protect them from tampering, and review them.
Track OpenEMR security releases and the PHP and database versions each needs. A staging copy lets you rehearse every upgrade before production.
Unique user IDs are required. OpenEMR supports TOTP and U2F multi-factor authentication; enforce it on every account, restrict admin access by network, and remove leavers promptly.
OpenEMR's installation guide gives no hardware sizing table, so we size from measurement rather than a rule of thumb. These are the loads that move the numbers.
Front desk, clinicians and billers working at once drive PHP workers and database connections more than total patient count does.
Document storage grows steadily and dominates disk and backup size, so plan storage growth and retention together.
Patient portal logins and FHIR or REST calls from connected apps add load outside clinic hours.
Large reports and claim batches hit the database hardest; schedule them, or give the database its own instance as Cloud Standard does with RDS.
One shared instance concentrates load and risk; separate instances isolate clinics but multiply upkeep.
Cloud instances resize easily, so start modestly, watch CPU, memory and slow queries for a month, then resize from evidence.
Managed AWS with encryption at rest and in transit, least-privilege access, audit logging, monitoring and encrypted, tested backups under a signed BAA. See HIPAA Cloud Hosting.
Operating system, web server, PHP and database updates on a schedule, run the way our managed hosting engineers run every server.
Customizations and integrations reviewed, the upgrade rehearsed on a separate copy, critical workflows tested, then a controlled production change.
Database, documents and configuration copied to the new environment, validated, and cut over with a rollback point.
Lab, billing and FHIR connections, including Mirth Connect interfaces, retested after each change.
A penetration test of your OpenEMR portal and APIs, worth doing after any customization.
We run the hosting layer; your users, policies and workforce training stay with you. A HIPAA risk assessment covers that side of the line.
One company handles OpenEMR customization, integration and hosting, so upgrades are not passed between vendors.
We respond to new enquiries inside one business day, and to a suspected breach on the same day.
Operating since 2008 from engineering teams based in Coimbatore and Chennai, with a solution architect accountable for each environment.
Tell us your OpenEMR version, how many people use it and where it runs today. We will reply with the setup we would recommend, the upgrade steps it needs first, and the safeguards it includes.
Prefer email? info@xcodefixglobal.com
Talk to the specialist who would scope the work — not a call-centre script.
Ask us directlyFor production with patient data, run it on HIPAA-eligible infrastructure under a signed BAA, with encryption, tested backups and someone accountable for patching. The project recommends its Docker image, and its Express Plus and Standard AWS options are built on HIPAA-eligible services. The right choice depends on whether your team can run the server or should hand it to a managed host.
OpenEMR is a community project. Its website lists professional support vendors alongside community forums and chat, and paid support typically covers installation, upgrades, customization and hosting. We provide OpenEMR implementation, integration and managed hosting as an independent company, with no affiliation to the OpenEMR Foundation.
Yes. The OpenEMR Foundation publishes Cloud Express on AWS Marketplace for demos and training, Express Plus as a CloudFormation template on HIPAA-eligible services, and the HIPAA-eligible Cloud Standard edition with Amazon RDS. If the system will hold PHI, accept the AWS Business Associate Addendum in AWS Artifact before deploying anything.
The software has no license fee. OpenEMR's own documentation has quoted AWS minimums of about $10 a month for Express, $20 for Express Plus and $75 for Standard, though those figures date from 2017 to 2021 and AWS prices change. Real cost depends on instance size, storage, backups and who does the administration. Managed hosting is scoped to the workload.
Yes. The project's download page calls the official openemr/openemr image the recommended way to run it. The image needs a separate MySQL or MariaDB container, configured through variables such as MYSQL_HOST and MYSQL_ROOT_PASS. For production, set DOMAIN so the container obtains a Let's Encrypt certificate instead of using its default self-signed one.
Not Cloud Express: its documentation says HIPAA covered entities may not store PHI on it. Express Plus and Cloud Standard are built on HIPAA-eligible AWS services, but eligibility is a starting point rather than compliance. You still need the AWS BAA, correct configuration, access controls, monitoring and backups that you have restored at least once.
If the server holds patient data for a covered entity, yes. HHS guidance is explicit that storing ePHI for a covered entity makes a cloud provider a business associate, and holding no decryption key does not change that. So you need a BAA with the cloud platform and with any managed host sitting between you and it. We sign one for our HIPAA Cloud Hosting.
No software is compliant on its own. OpenEMR provides features that support compliance, such as individual user accounts, audit logs and TOTP or U2F multi-factor authentication. Compliance depends on how it is hosted, configured, patched and used, together with your policies, risk analysis, workforce training and BAAs with every vendor that touches the data.
