What does Medplum cost to run once the license is free?
Medplum is released under the Apache 2.0 license, and its Community self-hosting option carries no license fee. That does not make self-hosting free to run. Total cost of ownership is set by four things: the infrastructure you operate, the upgrades you apply, the compliance evidence you assemble, and the staff who keep the platform working. A team deciding between self-hosting and a paid hosted plan should compare those four cost lines side by side, not the license line alone. On the hosted side, Medplum's pricing page lists Free, Production at $2,000 per month, Premium at $6,000 per month, and a custom-priced Enterprise plan. Self-hosting is offered as the free Community option or as custom-priced Enterprise Self-Hosted. Paid cloud plans include standard BAA and MSA agreements. Multiple external identity providers for SSO are listed as an enterprise feature, so confirm with Medplum whether your identity design requires that tier before you compare numbers. The pricing page figures are list prices as published, and your own quote may differ.
Self-hosting moves recurring costs onto your side of the contract. Expect to pay your cloud provider for compute, PostgreSQL and Redis capacity, backups, storage, logging and network egress, and to staff the on-call and change work that comes with running a Node.js and TypeScript server in your own account. Medplum's self-hosting documentation recommends AWS with CDK and CloudFormation, and other paths include Kubernetes, Docker and Terraform-based GCP and Azure deployments, where the Azure and GCP paths are marked Beta. Ask which deployment path your team will support long term, because the path drives both build effort and steady-state operating cost. Upgrades are a recurring labor cost. Medplum ships major versions annually in Q4, minor versions two to three times a year, and patch versions weekly. Self-hosted instances must move through each minor version in sequence, and post-deploy data migrations can run for hours or days on large datasets. Each major version gets one year of Active support and one year of Maintenance, with an Enterprise extension for security patches. Build a standing upgrade cycle into your staffing estimate, including a non-production rehearsal of each migration, and ask any support provider to state in writing what they cover in that cycle. Compliance evidence is the cost line most often underestimated. Medplum's compliance documentation covers HIPAA, SOC 2 Type II, ONC certification, 21 CFR Part 11, HITRUST e1, CLIA/CAP and ISO 9001, and it states that compliance is a shared responsibility between Medplum and its customers. A self-hosted deployment makes you the owner of the hosting controls, access reviews, logging retention and patch records that an auditor will sample. Those evidence routines recur every assessment cycle, and they need named owners. When should you ask for an outside cost review? The usual points are before you choose an edition, before a compliance assessment begins, and once the first self-hosted build is underway, when infrastructure choices are hardest to reverse. Such reviews are often done in-house by platform and security teams, with a partner brought in when the team lacks FHIR or healthcare operations experience. Whichever route you take, ask for a written quote that separates one-time build costs from recurring infrastructure, upgrade, evidence and staffing costs, and confirm each figure with Medplum and your cloud provider directly.
What a Medplum cost of ownership review covers
A cost of ownership review turns the Medplum license decision into a costed operating model. Each card below is one component that drives total cost, and each ends in a written deliverable the client can take into budget and procurement discussions. Together they show what the Community option leaves to the client and what a hosted or Enterprise Self-Hosted quote should be compared against.
Edition comparison
The review sets Community self-hosting, the hosted Free, Production and Premium plans, and custom Enterprise Self-Hosted side by side against the same requirements. Medplum's pricing page lists Production at $2,000 per month and Premium at $6,000 per month, and marks Enterprise as custom-priced, so the comparison must confirm which features each option includes, such as BAA coverage and multiple external identity providers. The deliverable is a comparison matrix with each feature mapped to the edition that provides it, plus a list of questions for Medplum about gaps.
Infrastructure model and run costs
Medplum's self-hosting options include AWS with CDK and CloudFormation, Kubernetes, Docker, Ubuntu through an APT repository, DigitalOcean, building from source, and Terraform for GCP and Azure, which Medplum marks as Beta. Each model carries different compute, managed database, Redis and networking costs, and different staffing needs. The deliverable is a written cost model with line items for each component, the assumptions behind each line, and the cloud or hosting costs the client pays directly.
Upgrade and patch workload
Medplum ships major versions yearly, minor versions two to three times a year, and patch versions weekly, and self-hosted upgrades must pass through each minor version in sequence. Post-deploy data migrations can run for hours or days on large datasets, which affects maintenance windows and test environment size. The deliverable is an estimate of recurring upgrade work with its assumptions, including the security patch targets in Medplum's policy of 7 days for critical and 14 days for high vulnerabilities.
Identity and compliance obligations
Self-hosting moves identity, access, audit and evidence work to the client. Medplum supports its own Auth, external providers such as Google, Auth0 or AWS Cognito, domain-level corporate identity providers, client credentials and MFA, and its compliance documentation states that compliance is a shared responsibility. The deliverable is a list of recurring controls the client must operate, the identity configurations to maintain, and the evidence each one produces for HIPAA or other assessments.
Staffing and ownership roles
Self-hosting requires named owners for the Node.js and TypeScript server, PostgreSQL, Redis, cloud infrastructure, identity, Bots and the app layer, and an on-call rotation for production. The review estimates the roles needed for each deployment model, marks which roles can be covered by a retainer, and identifies skills the internal team lacks. The deliverable is a staffing plan with role coverage, the internal and external split, and the questions to ask a partner about support scope and response expectations.
Which Medplum edition fits: Community, hosted plans or Enterprise Self-Hosted
The first decision is whether you want to run Medplum yourself or buy a hosted plan, and the answer shapes everything that follows. Community self-hosting carries no license fee: the Medplum code is released under the Apache 2.0 license, and you deploy it into your own cloud account or data center. Hosted plans move operation to Medplum. The pricing page lists a Free tier, a Production plan at $2,000 per month and a Premium plan at $6,000 per month, with custom-priced Enterprise and Enterprise Self-Hosted options above them. Those monthly figures are list prices from Medplum's pricing page at the time of research, so confirm them before you build a budget around them. The license fee is the smallest line in most comparisons. Under Community self-hosting, your team pays for cloud infrastructure, PostgreSQL and Redis operations, upgrades, backups, monitoring and on-call coverage. Under a hosted plan, the monthly subscription replaces much of that infrastructure and operations work, but you still pay for your own integration engineering, data loading, and application development. Ask each option's vendor which of those tasks are included, which are billed separately and which remain your responsibility. Regulated buyers should check two contract points early. Paid Medplum cloud plans include standard Business Associate Agreement and Master Services Agreement terms, which matters if you handle protected health information and need a BAA in place before go-live. Identity can also change the edition decision. Connecting multiple external identity providers, such as Okta, Azure or Auth0, for single sign-on is listed as an enterprise feature. If your workforce authenticates through more than one of these providers, or your policy requires centralized SSO across several systems, the Community or lower hosted tiers may not meet that need without a higher plan. Before you choose, ask Medplum for written answers on current plan limits, including user, project and storage constraints, support response terms, and exactly what Enterprise Self-Hosted includes, such as upgrade assistance, security patch delivery and deployment support. Those terms change, and the pricing page does not describe them in full. Ask for the answers in writing so you can compare them against your own requirements for data residency, identity and uptime. A practical way to frame the choice is to list your must-have requirements first: where the data must live, which identity providers must sign users in, whether you need a BAA immediately, and how much operations work your platform team can absorb. If the answers point to your own infrastructure with multi-provider SSO, price Enterprise Self-Hosted against Community plus the staffing you would otherwise add. If they point to fast start with limited operations capacity, compare the hosted tiers against the same staffing estimate. Either way, put the comparison in a written quote so the assumptions are visible to finance and security reviewers.
What pushes Medplum running costs up or down
This table lists the main drivers of what it costs to run Medplum, with why each one matters for a FHIR server built on Node.js, TypeScript, PostgreSQL and Redis, and how to keep it under control. Read each row as a lever: the driver pushes cost up as it grows, and the reduction column shows the design choice that holds it down. Most of the recurring cost comes from data volume, environment count and the edition you choose.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Data volume and growth | PostgreSQL storage, backups and memory for the working set grow with stored FHIR resources, history and audit records, and large datasets lengthen post-deploy migrations during upgrades. | Confirm retention rules for resource history and audit logs before sizing storage. Plan capacity from a measured load test, not from estimates. |
| Users and connected apps | Concurrent users, client applications and SMART-on-FHIR launches drive API request volume, which increases Node.js instance count, Redis capacity and database connections. | Separate high-traffic integrations from interactive users where possible. Use client credentials for servers rather than many user sessions. |
| Bots and integrations | Bots run server-side logic and consume compute on each execution, and scheduled or subscription-driven Bots add steady background load. | Inventory every Bot and its trigger. Retire unused Bots and avoid polling where a subscription can do the job. |
| HL7 feeds | HL7 v2 interfaces keep listeners open and convert messages into FHIR resources, so each feed adds throughput, error handling and monitoring work. | Count feeds by source system. Consolidate sources that send the same message types and size the interface engine for peak, not average, volume. |
| Environments (dev, test, production, disaster recovery) | Each environment repeats the database, Redis, compute and backup footprint. A disaster recovery copy also needs replication and periodic restore testing. | Keep development and test small and seeded with synthetic data. Right-size disaster recovery to the recovery objectives the business has agreed. |
| Chosen deployment target | AWS with CDK and CloudFormation is the recommended path. Kubernetes, DigitalOcean, Docker and the Beta GCP and Azure Terraform options each carry different managed-service, licensing and staffing costs. | Use the target your team already runs and operates. Confirm which managed database and cache services your chosen target supports before pricing. |
| Identity provider count | Each external identity provider adds configuration, testing, claim mapping and support for token behavior. Multiple external providers for SSO are listed as an enterprise feature on the pricing page. | Limit connected providers to the directories that hold your workforce. Agree on one domain-level identity provider where possible. |
| Compliance scope | Evidence collection, access reviews, logging and encryption controls apply to every system that stores or processes PHI. Medplum's compliance is a shared responsibility, so your own controls and evidence add cost. | Scope the PHI boundary tightly. Keep non-PHI tooling, sandboxes and reporting outside it, and confirm the BAA and MSA terms that apply to each vendor. |
| Edition | Free Community self-hosting shifts all infrastructure, staffing and patching to your team. Hosted Production and Premium plans list fixed monthly prices, and Enterprise and Enterprise Self-Hosted are quoted individually. | Compare the total of infrastructure, staff time and support against the hosted monthly price. Ask each vendor for a written quote covering included BAA, support and upgrade terms. |
How a Medplum cost review moves from scope to a costed model
A Medplum cost review turns a written scope into a costed model covering the edition decision, infrastructure, staffing and compliance, and the vendor's release and security policies. The client ends with a model they can maintain after the engagement closes.
Agree the scope and inventory the environment
DeployOpen and the client agree the review scope in writing, including which workloads, data types and environments are in view and who signs off the assumptions. The inventory covers the current environment if one exists, such as cloud accounts, existing FHIR or EHR systems, identity providers, and the data residency and hosting constraints the organization already applies. For a planned deployment, the inventory records the intended architecture and the teams who will run it. The step closes when the client confirms the inventory is complete and the timeline is recorded in the written scope.
Compare editions and choose the deployment model
The review sets the Community self-hosted option against the hosted Free, Production and Premium plans and Enterprise Self-Hosted, using the requirements from the inventory. Hosted plan prices come from Medplum's public pricing page, while Enterprise and Enterprise Self-Hosted are custom-priced, so the client needs a written quote for those. The output is a short decision record showing which edition and deployment model fit the requirements, the business associate and identity provider needs that drive the choice, and the open questions for Medplum's sales team. The step closes when the client approves the chosen option.
Build the infrastructure cost lines
DeployOpen models the cloud or data center resources the chosen deployment needs, including compute, PostgreSQL and Redis, storage and backups, networking, logging, and non-production environments. Medplum's recommended path is AWS with CDK and CloudFormation, and other documented paths (Kubernetes, Docker, Ubuntu, and Terraform-based GCP and Azure, which Medplum marks as Beta) change the cost lines. Each line states whether it is one-time setup or recurring, what drives it up or down, and which provider rate card it uses. The client confirms the sizing assumptions. The step closes with a line-item infrastructure model that the client can reprice.
Model staffing, implementation and compliance costs
This step costs the people and controls around the license: implementation effort, the platform and integration staff who will operate Medplum, on-call coverage, and the upgrade work set by Medplum's sequential minor version path. It also covers compliance preparation, since Medplum states that compliance is a shared responsibility, so the client carries evidence collection, policy work, and any independent assessment it chooses to commission. DeployOpen identifies which costs are one-time and which recur, and lists what to request in each vendor and partner quote. The output is a staffing and compliance cost schedule, with assumptions the client can challenge.
Review release and security policies against operations
DeployOpen compares Medplum's versioning policy with the client's operating model. The review covers the annual major release cadence, the Active and Maintenance support windows, the Enterprise extension, the targets for critical and high security patches, and the weekly patch cadence. The team checks whether the client can absorb those cadences in its change process and maintenance windows, and whether the cost model needs an upgrade or support budget line. The output is a findings register listing each policy and its operating impact, with items the client must confirm directly with Medplum. The step closes when the client accepts or amends the findings.
Assemble and test the costed model
DeployOpen combines the infrastructure, staffing, compliance, and policy findings into one cost model with a single set of assumptions, scenarios for the main decision points, and a summary of total cost of ownership by category. The team checks the model against the inventory and the quotes received, and reruns the key scenarios with the client to test sensitivity to the biggest drivers. The step closes when the client reviews the scenarios and confirms the model reflects its environment.
Hand over a model the client can update
DeployOpen delivers the model in an editable form with a documented structure, a list of assumptions and their sources, and instructions for updating prices, sizing, staffing rates and vendor quotes. The handover includes a walkthrough with the people who will maintain it and a short register of the items to recheck, such as Medplum's pricing page, its release policy, and any quotes that expire. The step closes when the client's owner confirms they can run an update without DeployOpen.
Which costs recur after go-live and what sets their size
This table lists the cost lines that continue after a self-hosted Medplum platform goes live, with the driver that sets each one's size. Read it as a checklist for building an annual run budget, since most lines scale with environment count, data volume and how quickly your team can absorb Medplum's release cadence. The main takeaway is that the license is often the smallest recurring line, while upgrade and patch workload is set by Medplum's release policy and your own staffing.
| Recurring cost line | Who is paid | What sets its size |
|---|---|---|
| Cloud hosting for the Medplum server | Your cloud provider, plus your team or a partner for operations | Instance count and size for the Node.js and TypeScript server, scaling under API traffic, and the AWS CDK or Kubernetes footprint you choose |
| PostgreSQL and Redis | Your cloud provider or database service, plus staff who tune and monitor them | PostgreSQL holds the FHIR data repository and Redis serves as the cache, so storage growth, replica count and cache sizing drive the bill |
| Backups, storage and retention | Your cloud provider | Data volume, backup frequency, retention periods set by your policies and the restore testing you schedule |
| Non-production environments | Your cloud provider and the team that maintains them | Number of dev, test and staging copies, whether they hold synthetic or de-identified data, and how often they are rebuilt during upgrades |
| Edition or subscription fees | Medplum, for hosted plans or Enterprise Self-Hosted; none for Community self-hosting | Chosen edition. Medplum lists Free, Production and Premium hosted plans, and custom-priced Enterprise options. Request current terms in writing |
| Support contracts | Medplum or a partner, depending on the agreement | Response expectations, coverage hours and whether the contract includes upgrade help. Confirm exactly what your edition includes |
| Upgrade effort across the release cadence | Your internal team or a partner | Medplum ships major versions yearly in Q4, minor versions two to three times a year and patches weekly. Self-hosted upgrades must pass through each minor version in sequence, and post-deploy data migrations can run for hours or days on large datasets |
| Security patch response | Your internal security and platform staff | Medplum targets security patches within 7 days for critical (CVSS 9.0 or higher) and within 14 days for high (CVSS 7.0 to 8.9) vulnerabilities. Your staffing must cover that window in every environment you run |
| Compliance evidence collection | Your compliance lead, plus any assessor or certification body you engage | Medplum's compliance documentation states that compliance is a shared responsibility. Evidence for HIPAA, SOC 2 or other frameworks you pursue is generated by your own configuration, logs and change records |
| Internal skills and staffing | Your payroll or your partner's retainer | Skills in FHIR, Node.js, PostgreSQL, Kubernetes or AWS, and on-call coverage. Staffing is often the largest recurring line, so confirm who owns each release and patch task before go-live |
How ownership cost changes by starting point and environment
Teams leaving a commercial healthcare platform usually replace a license with a cost structure they build and run. The license line may fall away or change, but the work of data migration, interface rebuilding and staff retraining does not. Ownership cost depends on what the current contract covers and what your team must rebuild.
- Infrastructure: New cloud or data center spend appears for the Node.js server, PostgreSQL and Redis, which the former vendor hosted for you.
- Staffing: Platform, database and security roles move in-house. Confirm whether existing staff can absorb them or whether you need new hires.
- Upgrade effort: Annual major versions and sequential minor upgrades become your calendar. Ask the vendor for its upgrade guidance and compare it with your current platform's cycle.
- Compliance evidence: Your team must produce HIPAA and audit evidence that the former vendor supplied under its agreements. Confirm which evidence the current contract provides, including BAA terms, and which you must generate yourself.
- Parallel running: Running both systems during cutover adds temporary infrastructure and labor. Ask for the expected overlap period in writing.
Before comparing totals, check the current contract's termination, data export and BAA terms, since they determine how much spend overlaps.
The AWS path using CDK and CloudFormation is the option Medplum's self-hosting documentation lists as recommended, so it is the reference point for most quotes. Costs center on AWS services, the work of keeping templates current, and the operations staff who watch the stack.
- Infrastructure: Compute, managed PostgreSQL, Redis, load balancing and storage carry the bulk of recurring spend. Ask for a sizing assumption tied to your user and data volume, and confirm which services the templates create by default.
- Staffing: Someone must own the CDK application, review template changes and govern the AWS account. Confirm whether your team already has CDK and AWS operations skills.
- Upgrade effort: Each minor version must be applied in sequence, and post-deploy data migrations can run for hours or days on large datasets. Plan maintenance windows and rehearse on a copy of production data.
- Compliance evidence: AWS account controls, logging and encryption settings become part of your evidence file. Confirm which AWS agreements and BAA coverage apply to your account.
- Patch timing: The vendor targets security patches within 7 days for critical vulnerabilities and within 14 days for high ones. Your change process must fit those timeframes.
In the quote, ask which CDK and CloudFormation versions the templates target and for an infrastructure cost breakdown by service, since both change as the stack changes.
These paths give you more control over the platform layer but move more design work to your team. Kubernetes and DigitalOcean are documented self-hosting options. The Terraform paths for GCP and Azure are marked Beta, which changes the support expectation and the amount of validation you must carry.
- Infrastructure: You choose the cluster, managed database and cache layout. Compare a managed PostgreSQL and Redis service with self-run instances inside the cluster, because the choice drives both cost and operating effort.
- Staffing: Kubernetes operations, including upgrades, networking and secrets management, add a skill requirement. Confirm whether your platform team already runs production clusters.
- Upgrade effort: Each cluster version and each Terraform module version adds a compatibility check on top of the Medplum upgrade sequence.
- Compliance evidence: Beta modules need your own validation records for configuration, encryption and logging. Ask the vendor which parts of the Beta templates it tests and which it does not.
- Support scope: Confirm in writing whether vendor support covers the Beta deployment modules or only the application itself.
For a regulated workload, confirm the support terms and the validation work in writing before choosing a Beta path, since both add cost that a documented path typically carries less of.
Air-gapped operation removes the internet path that cloud and hosted models assume. Cost moves toward transfer procedures, offline dependency management and staff who can maintain the platform without outbound connectivity. Confirm what the vendor can deliver into a network with no outside access before you build the budget.
- Infrastructure: Staging and recovery environments often need duplicate capacity inside the enclosure, and each adds hardware or private cloud spend.
- Staffing: Staff must handle package mirroring, image transfer and manual dependency checks, which lengthen routine maintenance tasks.
- Upgrade effort: Each minor release must be moved across the boundary and applied in sequence. Plan for transfer lead time, because the vendor's 7-day and 14-day patch targets still set the benchmark for how quickly a fix should reach you.
- Compliance evidence: Your own records of transfers, approvals and offline validation become part of the audit file. Ask how the vendor provides release artifacts and verification data for offline use.
- Identity and access: Confirm whether identity providers, licensing or telemetry depend on outbound connectivity, and which of them need an offline alternative.
Ask the vendor and your security team to document every external dependency before quoting, since each one needs an offline alternative and a named owner.
Moving from Medplum's hosted cloud to self-hosting shifts operational and compliance responsibility to your team. Hosted plans bundle infrastructure, upgrades and part of the compliance work into the subscription. Self-hosting gives you direct control in exchange for those lines, so the cost moves from a subscription to a mix of infrastructure, staffing and evidence work. Medplum's compliance documentation describes compliance as a shared responsibility, so your share grows after the move.
- Infrastructure: You take on the cloud accounts, databases, caches and backups that the hosted service previously carried.
- Staffing: Operations, on-call and security monitoring move in-house. Confirm whether the Enterprise Self-Hosted terms include vendor support hours and what those hours cover.
- Upgrade effort: Upgrades follow your schedule. Plan for sequential minor upgrades and data migrations that can run for hours or days on large datasets.
- Compliance evidence: Controls the hosted plan covered, such as BAA coverage and infrastructure logging, must be rebuilt in your environment. Ask which of the vendor's compliance programs apply to a self-hosted deployment.
- Agreement change: Hosted terms may end or change to a custom Enterprise Self-Hosted agreement. Ask for written terms covering exit, data export and support during cutover.
Before comparing totals, map each hosted-plan benefit to a line in your own budget, since the difference shows up in the lines you must now staff and evidence.
Where Medplum cost estimates usually go wrong
Medplum cost estimates tend to count the software license and miss the work around it. The six errors below share one pattern: they overlook recurring operations, environments and agreements that a self-hosted deployment needs. Check each one before the estimate is signed off.
Treating Community as the total cost
The Community option is free to self-host under the Apache 2.0 license, but the license is only one line in the model. Infrastructure on AWS or Kubernetes, PostgreSQL and Redis, implementation, integration, compliance evidence and ongoing staffing all carry their own costs. Prevention: build the estimate as a list of components, each with an owner and a recurring or one-time label. Question to ask: which lines in this estimate are not license fees, and who pays for each one?
Ignoring sequential minor upgrades
Self-hosted Medplum must move through each minor version in order, and skipping versions can cause startup failures. Minor versions arrive two to three times a year, patches weekly, and majors annually, so upgrade work recurs for the life of the deployment. Prevention: budget named staff time for each upgrade cycle and rehearse each step in staging. Question to ask: how many minor versions separate our current release from the target, and who performs each step?
Underestimating post-deploy migration time
Some post-deploy data migrations run for hours or days on large datasets, according to the vendor's upgrading guide. A migration that finishes quickly on a small test database can overrun a maintenance window on production data. Prevention: measure migration duration on a copy of production-sized data, then schedule the window and a rollback plan around that measurement. Question to ask: what is the measured migration time on a production-sized copy, and where does it sit in the schedule?
Skipping non-production environments
Estimates often include one production environment and omit the rest. Upgrades, data migrations, integration tests and SMART-on-FHIR app testing all need a staging environment that mirrors production, and each environment needs patching and monitoring. Prevention: list every environment in scope, its purpose, its refresh schedule and the staff who maintain it. Question to ask: which environments are priced in this estimate, and who keeps each one patched?
Assuming the hosted BAA covers self-hosting
Medplum's paid cloud plans include a standard BAA and MSA, but those agreements describe the hosted service. A self-hosted deployment runs in your own cloud account or data center, so the agreements that cover that infrastructure are your responsibility to confirm. Prevention: ask Medplum and your infrastructure provider which signed agreements apply to each environment that stores patient data. Question to ask: which signed agreement covers the environment holding PHI, and who signs it?
Leaving identity provider licensing out
Medplum supports its own identity provider as well as external ones such as Google, Auth0 or AWS Cognito, and the pricing page lists multiple external identity providers for SSO as an enterprise feature. Most identity providers also charge per user or per feature, and that charge recurs. Prevention: name the identity provider in the estimate, confirm which Medplum edition includes the needed SSO features, and model the per-user cost. Question to ask: which identity provider will staff and app users sign in with, and what does it charge for the users in scope?
What to gather before asking for a Medplum cost review
A cost review for Medplum is only as accurate as the inputs behind it. Before requesting one, gather the facts that decide whether the work points toward the free Community option, a hosted plan, or Enterprise Self-Hosted, and what the infrastructure and staffing around the license will cost. Start with architecture and cloud accounts. Document whether you plan to deploy on AWS with the CDK and CloudFormation path that Medplum's self-hosting docs describe as recommended, on Kubernetes, on another listed option, or on the Terraform-based GCP or Azure paths, which the docs mark as Beta. Note the accounts, regions, network boundaries and any existing PostgreSQL and Redis services you intend to reuse. Each choice changes the infrastructure line, the skills needed to run it, and the effort to harden it. Next, estimate users and data with growth. Medplum's server uses PostgreSQL for storage and Redis for caching, so resource needs follow the number of concurrent users, API calls, bots running, and the volume of FHIR resources you expect to store and retain. Ask your product owners for expected counts at launch and at 12 and 24 months, plus any known peak events such as enrollment periods. Record which data must be kept for how long, because retention drives storage and backup costs and affects the work needed for audit evidence.
Third, list every integration and HL7 feed in scope. Medplum includes an HL7 client and server, and each inbound or outbound feed, EHR connection, lab interface or third-party FHIR endpoint adds mapping, testing, monitoring and support effort. Separate feeds you will build now from those planned later. Identify which ones are one-directional and which require acknowledgments, retries or reconciliation. Assign an owner in your integration or interface engineering team to confirm the list, since missing feeds are one of the most common reasons an estimate changes after kickoff. Fourth, identify the identity providers in use and the compliance obligations they touch. Medplum can authenticate against its own identity provider, external providers such as Google, Auth0 or AWS Cognito, and domain-level corporate providers, and its pricing page lists multiple external identity providers for SSO such as Okta, Azure and Auth0 as an enterprise feature. Confirm with your identity team which provider is the system of record, whether MFA is enforced centrally, and which applications need client credentials. Then name the frameworks your organization is subject to, such as HIPAA, and the systems each one covers. Medplum's compliance documentation states that compliance is a shared responsibility, so the security and compliance lead should list which controls your organization must evidence itself. Finally, name the internal owners and the approval path. Assign one person each for infrastructure operations, the upgrade schedule and security response, since Medplum ships major versions annually, minor versions two to three times a year, and patches weekly, and critical security patches are expected within the vendor's stated windows. Ask finance or procurement to confirm the budget owner, the approval thresholds, and whether recurring cloud and support spend must be approved separately from one-time implementation work. Share these answers in writing so the quote separates one-time work from recurring costs.
Questions buyers ask about Medplum cost before hiring help
Is self-hosting Medplum free?
The Community option is free to download and run, because Medplum is released under the Apache 2.0 license. The license fee is only one part of the total. You still pay for the cloud or data center infrastructure that runs the Medplum server, PostgreSQL and Redis, plus backups, monitoring, network and storage costs. You also pay for the people who deploy, upgrade, secure and support the platform. Infrastructure and staff are not free. Ask your team to list each of these as a recurring or one-time cost before you compare options.
How do Medplum hosted plan prices compare with Enterprise Self-Hosted?
Medplum's pricing page lists hosted plans at fixed monthly rates for Production at $2,000 per month and Premium at $6,000 per month, with a custom-priced Enterprise tier. Enterprise Self-Hosted is custom-priced, so there is no published rate to compare directly. The hosted price includes Medplum's operation of the platform, while a self-hosted deployment moves that operation, and its infrastructure, into your environment. Confirm the terms, inclusions and any minimums with Medplum in writing before you build a comparison, since the two models carry different cost components.
How long does a Medplum cost review take?
The duration of a cost review is set in the written scope agreed before work starts, and this page does not estimate it. DeployOpen's engagements are generally fixed-scope, so the scope, deliverables and timeline are defined in writing. The length depends on how many deployment options you are comparing, how much of your current infrastructure and staffing data is available, and whether you need compliance cost items included. Ask for the timeline as a line item in the written scope.
What information does a Medplum cost review need from our team?
A useful review needs your expected workload, not just a list of features. Prepare the number of users and applications that will call the FHIR API, expected data volume and growth, required integrations such as HL7 feeds or identity providers, and your target availability and recovery expectations. Also share the cloud accounts or data centers you plan to use, your current licensing and staffing model, and any compliance obligations that apply, such as HIPAA. Missing inputs usually move cost into the assumptions, so document each one.
Can our own team build the Medplum cost model without outside help?
Yes, many teams build a basic model internally. Start with the Community license, your infrastructure pricing, and the staff hours needed for deployment, upgrades and security patching. Medplum ships major versions once a year, minor versions two to three times a year and patch versions weekly, and self-hosted upgrades must move through each minor version in sequence. Include that upgrade effort in your staffing line. An outside review adds value when you need an independent check of assumptions, a comparison with Enterprise Self-Hosted terms, or a quote built from a fixed scope.
Does a Medplum cost review include a compliance assessment?
A cost review can identify the compliance-related costs that sit around the platform, such as hardening, audit logging, evidence collection and the staff time to keep them current. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies. Medplum's compliance documentation states that compliance is a shared responsibility between Medplum and its customers, so confirm which controls each party covers before you assign costs.
What costs are one-time and what costs recur with self-hosted Medplum?
One-time costs usually include the initial design, deployment, data model setup, identity integration, and any data migration or hardening work. Recurring costs include cloud or data center infrastructure, database and cache operation, backups, monitoring, patching, the annual major upgrade, and the staff time to run the platform. Your costs go up when data volume, availability targets or the number of integrations grow. Ask any partner for a quote that separates these two groups so you can compare each year's spend on its own.
How DeployOpen scopes, delivers and hands over a Medplum cost review
DeployOpen approaches Medplum cost of ownership as a written, fixed-scope review of what your organization would actually pay for, from the free Community self-hosting path to hosted plans and Enterprise Self-Hosted. The review covers the license tier as well as the infrastructure, implementation, compliance and staffing costs around it, and it ends with documentation your team can keep and reuse.
How we scope
- Agree the written scope before work starts, including which Medplum editions and deployment options are compared.
- Confirm your hosting environment, data volumes, integrations and identity providers, since these change the cost picture.
- Define which compliance obligations, such as HIPAA safeguards, must be costed into the review and who owns them.
- Ask us to list the deliverables, review points and decision dates in the scope document so the quote follows from it.
How we build
- Model the Community self-hosting option against hosted and Enterprise Self-Hosted tiers using your agreed assumptions.
- Estimate cloud infrastructure for PostgreSQL, Redis and the Medplum server in your own accounts, with the sizing basis documented.
- Map recurring costs such as upgrades, patch handling under the vendor's security timelines, and staff time against one-time setup work.
- Test the cost model against your environment's assumptions and record which figures came from vendor sources and which came from your inputs.
How we hand over
- Deliver a written cost of ownership report with each cost component, its owner, and whether it is one-time or recurring.
- Provide a sensitivity view showing which assumptions, such as data volume or staffing model, move the total most.
- Document the questions to put to Medplum and any cloud or staffing vendors, so your procurement team can request matching quotes.
- Walk your technical and financial stakeholders through the model and leave the spreadsheet and assumptions with your team.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if you want help keeping the cost model current.
- Revisit the model when Medplum's release policy or your data growth changes the assumptions behind it.
- Support the upgrade and patching work that the cost model depends on, scoped separately under a written agreement.
- Confirm with Medplum and your auditors which compliance evidence is yours to maintain, since compliance is a shared responsibility.
