Medplum cloud vs self-hosted Medplum

Should you self-host Medplum or use Medplum Cloud?

For most teams, Medplum Cloud is the default answer, and self-hosting is the right call only when a hard regulatory or contractual rule keeps hosting inside your own cloud or on premises. If your obligation is to control where data physically sits, self-hosting gives you that control. If your obligation is to show certifications and offload the operating load, the hosted service is built for that. Start by writing down which of those two you actually need, because it decides the rest of the comparison. Medplum Cloud fits a team that will treat patients or run research on the platform. Medplum's pricing page recommends the Production plan, listed at $2,000 per month, for production applications of that kind, and its hosted plans include a standard BAA and MSA. Medplum also states that the certifications on its Trust Center, including ONC Health IT certification, attach to its hosted environment and not to the open-source code. Ask Medplum for the current Trust Center documents and confirm which certifications cover the exact plan and region you buy, since a self-hosted deployment does not inherit them.

Self-hosting fits three situations that Medplum's own guidance describes: hard regulatory or contractual requirements to run on premises, such as some US federal work, low-connectivity or edge deployments with modest data needs, and education or non-production use. In those cases you accept the operating load. Medplum's self-hosting considerations say you must roll out every release, size and upgrade Redis and PostgreSQL, and staff 24/7 on-call with your own observability and alerting. Medplum estimates a single server upgrade can take one week to one month of a dedicated engineer's time, so ask whether your team can staff that before you commit.

How Medplum Cloud and self-hosted Medplum compare on each factor

This table sets Medplum's hosted service against self-hosting the Apache-2.0 platform, row by row, so you can see who carries each responsibility. Read each row against your own hosting rules, contracts and staffing, because the right column depends on those constraints more than on feature lists. The main takeaway is that the hosted plans move maintenance, upgrades and compliance evidence toward Medplum, while self-hosting moves that work to your team.

Factor	Self-hosted Medplum	Medplum Cloud
Hosting control and data location	You choose the cloud account, region or data center; Medplum's recommended path is AWS with CDK and CloudFormation templates	Medplum runs the hosted environment; confirm the data regions and residency terms in writing before you sign
Plans and published prices	Community is free; Enterprise Self-Hosted is custom-priced and quoted on request	Free, Production at $2,000 per month, Premium at $6,000 per month, and custom-priced Enterprise (Medplum pricing page)
BAA and MSA	No Medplum-provided BAA covers your own deployment; your BAAs cover your own hosting providers and business associates	Hosted plans include a standard BAA and MSA (Medplum pricing page); confirm scope and terms for your plan
Certifications	Medplum states its Trust Center certifications, including ONC, attach to the hosted environment, not the open-source code	Certifications listed on the Trust Center attach to the hosted environment; ask for current reports and scope
Support channels	Community support runs through Discord and GitHub	Paid plans move support to SLA-backed channels; confirm response terms for your plan
Log streaming	You build log shipping and alerting with your own observability stack	Streaming to SumoLogic and Datadog is available on Premium and Enterprise plans only
Identity options	You configure Medplum Auth, external providers, client credentials and MFA in your environment	Same identity options apply, with Medplum hosting the auth service; confirm which providers your plan supports
Bots	Available in your deployment, subject to your own configuration	Not enabled on the Free plan; available on paid plans
Licensing	Apache 2.0 for the code; Community is free, and Enterprise Self-Hosted is a separate commercial agreement	Apache 2.0 for the open-source code; hosted service is billed under the plan you select
Upgrade cadence	You roll out every release, including minor versions in sequence and annual major versions	Medplum handles upgrades and security updates as part of the service
Who runs maintenance	Your team sizes and upgrades Redis and PostgreSQL, and staffs 24/7 on-call for alerting	Medplum handles system maintenance, security updates, upgrades and infrastructure scaling

What certifications and compliance mean in each hosting model

Certifications and compliance work differently depending on who runs the environment. The cards below separate what attaches to Medplum's hosted service, what stays with your organization in either model, and where the HIPAA obligations and enforcement exposure sit.

Data location and control

In the hosted model, Medplum runs the environment, so the question is where your patient data sits and who can reach it. In a self-hosted deployment, your cloud account, region and access controls define that answer. Medplum's self-hosting guidance names hard regulatory or contractual hosting requirements, such as US federal work that must run on premises, as a reason to self-host. Ask Medplum to confirm the hosting regions and data residency terms for the Production and Premium plans in writing.

Certifications attach to the hosted environment

Medplum states that the certifications on its Trust Center, including ONC Health IT certification, attach to its hosted environment and not to the open-source code. The same codebase run by your team does not inherit those certifications. If you self-host, you must establish your own evidence for the controls that a certified hosted environment would otherwise supply. Confirm the current certification scope and audit dates in the Trust Center with Medplum before you rely on them in a procurement file.

Shared responsibility in both models

Medplum's compliance documentation states that compliance is a shared responsibility between Medplum and its customers. In the hosted model, Medplum covers the hosted platform while your team still owns how users are provisioned, which identity providers are connected, how Bots are written and how data is exported. In a self-hosted model, your team also owns infrastructure, patching and monitoring. Map each control in your program to one of these owners before go-live, and record the mapping.

HIPAA has no certification

HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not stop HHS from later finding a violation. A certificate on a vendor's Trust Center therefore does not make your deployment compliant. The HIPAA obligations stay with covered entities and business associates, and your own risk analysis and risk management program must show how the platform is configured and monitored. Treat the hosted certifications as supporting evidence, not as a substitute for your program.

Business associate contract requirements

Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI. Medplum's hosted plans include a standard BAA and MSA, so the hosted route starts from a signed contract. In a self-hosted model, you carry the covered entity obligations directly and should confirm which parties need a BAA with your cloud provider and with DeployOpen or any other implementation partner.

Enforcement exposure

For penalties assessed on or after 28 January 2026, the inflation-adjusted HIPAA civil money penalty ranges from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294, under 45 CFR 102.3. Exposure depends on the covered entity's own program, so a hosted certification does not reduce it on its own. Ask which breach notification and incident response duties sit with the vendor under the BAA, and which sit with your team in a self-hosted deployment.

What your team takes on when it self-hosts Medplum

Self-hosting Medplum moves the operating work of a hosted service onto your team. Medplum documents that Medplum Cloud handles system maintenance, security updates, upgrades and infrastructure scaling, while self-hosters must roll out every release, size and upgrade Redis and PostgreSQL, and staff 24/7 on-call with their own observability and alerting. The Medplum server runs on Node.js and TypeScript with PostgreSQL as its database and Redis as its cache, so both stores sit in your operating scope from day one. Before you commit, confirm who owns each of these duties, which on-call rotation covers the Medplum server and its data stores, and which alerts you will page on.

Release cadence sets the rhythm of that work. Medplum ships major versions annually in Q4, minor versions two to three times a year and patch versions weekly. Each major version gets one year of Active support and one year of Maintenance, with an Enterprise extension of 12 more months of security patches, for 36 months in total. Medplum targets security patches within 7 days for critical vulnerabilities (CVSS 9.0 or higher) and within 14 days for high ones (CVSS 7.0 to 8.9). If you self-host, those windows apply to your environment only after you deploy the fix, so your change process must be able to ship a patch inside them. Ask Medplum which support tier your contract includes and how it notifies self-hosters of security releases.

Upgrades carry the heaviest load. Medplum estimates that a single server version upgrade can take one week to one month of a dedicated engineer's time for self-hosters. Medplum's upgrade guide also requires that you move through each minor version in sequence. Skipping versions, for example from v3.1.2 straight to v4.3.4, causes startup failures, and post-deploy data migrations can run for hours or days on large datasets. Plan a staging environment with a production-sized copy of the database, schedule migration windows, and rehearse rollback before the first upgrade. Treat the one-week to one-month figure as Medplum's own estimate and validate it against your data volume and change controls.

What your team runs in each model

This table sets out who operates each part of Medplum in a self-hosted deployment versus Medplum Cloud, based on Medplum's own self-hosting guidance. Read each row as a question to put to Medplum and to your own platform team before choosing a model, since the on-call scope and exact responsibility split should be confirmed in writing.

Area	Self-hosted (your team)	Medplum Cloud (vendor-run)
System maintenance	Your team keeps the servers, containers or cluster running and patched at the infrastructure layer	Medplum handles system maintenance as part of the hosted service
Security updates	Your team must roll out every release that carries security fixes, within your own policy window	Medplum applies security updates; confirm the patch timing it commits to under its versioning policy
Upgrades	Your team steps through each minor version in sequence; skipping versions causes startup failures, and data migrations can run for hours or days	Medplum performs upgrades; confirm how customers are notified and whether any downtime applies
Infrastructure scaling	Your team sizes and scales compute and the database tier as load grows	Medplum handles infrastructure scaling; confirm the limits of your plan
PostgreSQL and Redis sizing	Your team sizes, tunes and backs up PostgreSQL and Redis, the database and cache Medplum uses	Medplum runs PostgreSQL and Redis; confirm backup, restore and retention terms in your contract
On-call	Your team staffs 24/7 on-call for the platform	Medplum operates the hosted environment; confirm the scope of on-call coverage and escalation paths with Medplum
Observability and alerting	Your team builds and runs its own observability and alerting stack	Medplum runs monitoring for the hosted service; ask what alerting and status information customers receive
Log streaming	Your team configures log shipping to its own tools	Log streaming to tools such as SumoLogic and Datadog is available on Premium and Enterprise plans
Identity setup	Your team configures Medplum Auth, external identity providers, MFA and client credentials in its own environment	Medplum provides the same identity options; confirm which external providers and MFA settings your plan supports
Deployment target	Your cloud, data center or on-premises network; AWS with CDK and CloudFormation is the recommended path	Medplum's hosted environment, which carries the certifications listed on its Trust Center

Which hosting model fits which team

This tab applies when a regulator, a federal contract or an internal policy requires the clinical data store to run on premises or in a specific environment you control. Medplum's own self-hosting guidance names US federal work that must run on premises as a case where self-hosting fits. In this situation the hosting decision is not a preference, so the question is how much operating capacity you will staff to meet it.

Who runs the platform: You own every release, upgrade, backup and incident. Medplum Cloud handles those tasks for hosted customers, so they move to your team.
Upgrade path: Self-hosted Medplum must move through each minor version in sequence. Medplum estimates a single server version upgrade can take one week to one month of a dedicated engineer's time.
Certifications: Medplum states its Trust Center certifications attach to the hosted environment, not the open-source code. Your own environment will need its own evidence.
Deployment path: Medplum's recommended self-hosting option is AWS with CDK and CloudFormation templates, the same approach it uses for its hosted service. Confirm your target cloud before you plan around it.

Before committing, ask Medplum which of its self-hosting options your data residency and contract terms allow, and get the on-call and upgrade staffing model in writing.

How to move between self-hosted Medplum and Medplum Cloud

This sequence gives you a verified inventory, an agreed target plan and BAA, a validated data and Bots baseline, and a clean cutover with no open dependencies on the old environment.

Inventory data, identity and integrations
Your team lists every resource type and dataset in the current environment, every identity provider and client credential in use, and every system that calls the FHIR API, consumes HL7 messages or receives log streams. Name an owner for each item. The step is done when the inventory is signed off by the platform lead and the security owner, and nothing in production is unaccounted for.
Confirm target plan and BAA terms
Before any data moves, confirm which Medplum hosted plan you need and what it includes. Medplum's pricing page lists a Free, Production, Premium and custom-priced Enterprise tier, and states that its hosted plans include a standard BAA and MSA. Ask Medplum to confirm in writing the BAA and MSA terms that apply to your account. The step is done when procurement and legal hold a signed BAA covering the target environment.
Align self-hosted version with the release path
Confirm the version your self-hosted instance runs and whether it is still under support according to Medplum's versioning policy. Plan the upgrade path to the target release, since self-hosted Medplum must be taken through each minor version in sequence. Skipping versions can cause startup failures. The step is done when a written upgrade path exists and the instance is on a supported version before migration begins.
Scope the data migration by dataset size
Measure the size of your PostgreSQL data and the volume of resources to be moved, then ask Medplum and your implementation partner to confirm how the migration and any post-deploy data migrations will run against that dataset. Post-deploy migrations on large datasets can take hours or days, so the duration depends on your data, not on a general estimate. DeployOpen would scope this work in writing, with deliverables and timelines agreed before work starts. The step is done when the migration plan and its timing are approved in writing.
Validate data and Bots behavior
Run the migrated or restored data through test queries, FHIR API calls and SMART-on-FHIR launches that match production use. Check that every Bot your applications depend on runs in the target environment. Bots are not enabled on the Free plan, so confirm the plan supports them before testing. The step is done when reconciliation reports show record counts and key clinical fields match the source, and each Bot returns the expected output in a test run.
Cut over identity and log streaming
Point your applications and users at the new environment's authentication configuration, including any external identity providers, client credentials for server-to-server calls and multi-factor authentication settings. Reconfigure log streaming to your monitoring tools, noting that streaming to tools such as SumoLogic and Datadog is available on Premium and Enterprise plans. Keep the old environment read-only during the switch. The step is done when test logins succeed, client credentials work, and log events arrive in your monitoring tools from the new environment.
Retire the old environment
After a confirmed observation period agreed in advance, decommission the self-hosted stack. Revoke its credentials, remove DNS and network paths, and archive or securely destroy the database backups according to your retention policy and any applicable HIPAA requirements. Retain the migration records and sign-offs as evidence. The step is done when the old environment is decommissioned, access is revoked, and the change record is filed with the compliance owner.

What buyers ask before choosing Medplum Cloud or self-hosting

What does self-hosting Medplum cost in staff time?

Self-hosting moves recurring engineering work from Medplum to your team. Medplum estimates that a single server version upgrade can take one week to one month of a dedicated engineer's time. The rest of the staffing load comes from running the stack: you roll out every release, size and upgrade Redis and PostgreSQL, and staff 24/7 on-call with your own observability and alerting. Medplum Cloud handles maintenance, security updates, upgrades and infrastructure scaling on hosted plans. Your self-hosting costs are mostly people time, the cloud infrastructure you pay for in your own account, and the on-call rotation, all of which recur. Ask Medplum to list which of these tasks its Enterprise Self-Hosted terms cover and which remain with your team.

Does Medplum Cloud cover HIPAA compliance by itself?

No. HIPAA compliance is a shared responsibility between Medplum and its customers, as the Medplum compliance documentation states. Hosted plans include a standard BAA and MSA, which gives you the contract layer. Medplum also states that the certifications on its Trust Center, including ONC Health IT certification, attach to the hosted environment and not to the open-source code, so self-hosting does not carry them over. HIPAA itself has no certification: HHS says no Security Rule standard requires certifying compliance. Under 45 CFR 164.314, a business associate contract must require Security Rule compliance and incident reporting, so have counsel review the BAA. Your access control, user management and clinical workflows remain your responsibility in either model.

How long does a self-hosted Medplum upgrade take?

Medplum estimates one week to one month of a dedicated engineer's time for a single server version upgrade. The path matters as much as the effort. Self-hosted Medplum must move through each minor version in sequence, and skipping versions causes startup failures; the documentation gives the example of jumping from v3.1.2 straight to v4.3.4. Post-deploy data migrations can run for hours or days on large datasets, so the size of your data drives the window. Release cadence adds recurring load: Medplum ships major versions annually in Q4, minor versions two to three times a year and patch versions weekly. It targets security patches within 7 days for critical vulnerabilities and 14 days for high ones. Each major version gets one year of Active support and one year of Maintenance, extendable to 36 months in total under Enterprise.

Can a small team run Medplum on its own infrastructure?

A small team can run it for some use cases, and Medplum's own guidance names where self-hosting fits. It suits hard regulatory or contractual requirements that force on-premises hosting, such as US federal work, low-connectivity or edge deployments with modest data needs, and education or non-production use. A self-hosted sandbox or training environment carries far less risk than a patient-facing system. For production applications such as treating patients or conducting research, Medplum recommends its Production plan unless you must host on your own cloud. Before committing, count the people who can cover upgrades and 24/7 on-call without a single point of failure, and confirm whether a retainer or vendor scope covers that load.

What should a quote for self-hosted Medplum include?

A useful quote states the scope, the target environment, the support tier and the terms of Enterprise Self-Hosted, and it is agreed in writing before work starts. Ask who sizes and upgrades PostgreSQL and Redis, who runs on-call, and which observability and alerting tools are in scope. Medplum's recommended self-hosting path is AWS with CDK and CloudFormation, with Ubuntu, Docker, Kubernetes and other options documented, so confirm which target the quote covers. Log streaming to tools such as SumoLogic and Datadog is available on Premium and Enterprise plans. Support channels move to SLA-backed options on paid plans, so get the SLA terms in writing. Medplum lists Production at $2,000 per month and Premium at $6,000 per month, while Enterprise and Enterprise Self-Hosted are priced on request, so confirm current figures directly with Medplum pricing.

Can I move from Medplum Cloud to self-hosting later?

The documentation available to this comparison does not describe a migration path between the hosted service and a self-hosted deployment, so confirm the export, import and cutover steps with Medplum before you depend on either direction. The known constraints are still worth planning around. A self-hosted instance must follow a sequential minor version path, so its target version has to align with the version your data already runs on. Large data migrations can run for hours or days, which means cutover needs a planned window. Ask whether FHIR data, Bots, authentication settings and client credentials carry over intact. Also ask what happens to the BAA and to any certifications when workloads leave the hosted environment, since those certifications attach to the hosted environment.

Should DeployOpen run a self-hosted Medplum environment for us?

DeployOpen can plan, implement, harden, back up, upgrade, document and support self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. A retainer can address the upgrade and on-call load described above, but confirm which Medplum versions, upgrade windows and response terms it covers. DeployOpen does not publish a price list, so a quote follows from your written scope. It prepares systems and evidence for compliance assessments but does not issue audit reports, attestations or certifications, and it is not an official Medplum partner or reseller.

How DeployOpen scopes and supports a self-hosted Medplum

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For Medplum, that means working from a written scope that states whether self-hosting is the right call at all, and then carrying the self-hosted deployment through handover and ongoing support.

How we scope

Written scope agreed before work starts, covering the hosting target, data classes and regulatory obligations in play.
Clear statement of which Medplum components, identity providers and integrations are in and out of scope.
Confirmation of who holds the business associate agreement and which compliance evidence the client will own.

How we build

Deployment carried out in the client's own environment, using the self-hosting method the client has chosen for Medplum.
Configuration of identity integration, including Medplum Auth, external identity providers and multi-factor authentication.
Security testing of the deployed platform and its APIs before go-live, with findings tracked to closure.

How we hand over

Runbooks for release rollout, minor version sequencing, database and cache sizing, and backup and restore.
Documentation of observability, alerting and on-call responsibilities so the client knows exactly who responds to what.
Evidence packs prepared for the client's compliance assessor, with clear notes on what the certifications do and do not cover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrade planning scheduled around Medplum's published release cadence and the required sequence of minor versions.
Periodic review of patch status against the vendor's security patch targets, reported to the client's security team.