Open-source FHIR servers used to feel like a research-lab choice for American hospital IT teams. In 2026 they are mainstream. Several of the largest US health systems run open-source FHIR servers in production for analytics, app development, and even primary clinical-data exchange. The catch is that not every open-source project is equally maintained, and a hospital IT lead who picks the wrong one inherits a maintenance burden that no amount of vendor support can fix later.
Here are the seven open-source FHIR servers that show up most often in US hospital evaluations, ranked roughly by maturity and US-deployment footprint. For a full vendor-by-vendor decision framework, the 2026 Buyer's Guide to FHIR Servers is worth reading first, and deeper FHIR walkthroughs provide background on each piece.
HAPI FHIR
HAPI is the reference open-source FHIR server in the US. Java code base, full R4 and R5 support, and a well-known operations story. American hospital IT teams pick HAPI when they want maximum control and have at least two developers comfortable maintaining a Java service in production. The community is responsive and the documentation is thorough.
LinuxForHealth FHIR (formerly IBM FHIR Server)
LinuxForHealth FHIR is the successor to IBM's FHIR Server, now maintained as a community project. It has a more rigorous test suite than HAPI and a clean separation between persistence and API layers. American hospitals running it tend to be the ones with strong Java shops and a preference for IBM-flavored open source.
Blaze
Blaze is a FHIR server built on Datomic and focused on bulk-data and analytics workloads. American hospitals running it use it for research and population-health pipelines, where the immutable-history model fits the use case. It is not a general-purpose clinical FHIR store the way HAPI is, but for the niche it serves, nothing else comes close.
Medplum (open-core)
The open-core part of Medplum is genuinely open source and is enough to run a useful FHIR endpoint for an American hospital app project. The managed product is the path most production teams pick, but the open-source path stays viable for smaller deployments and proof-of-concept work.
Aidbox FHIR Base (community edition)
Aidbox publishes a community edition of its FHIR server that some American hospital labs run for internal tooling. It is more limited than the commercial product but is enough for several US Core use cases. Hospitals that pilot Aidbox often start here.
Vermonster's fhir-kit-server
The fhir-kit-server project is a Node.js FHIR server that turns up in American digital-health startups working closely with US hospitals. It is lighter than HAPI and easier to extend in JavaScript. Hospital IT teams that need a small, dedicated FHIR endpoint for a single use case sometimes pick it for that reason.
HAPI on FHIR-Works on AWS
FHIR Works on AWS is an open-source reference implementation that wraps HAPI in a way that runs cleanly on AWS infrastructure. For American hospitals deeply on AWS, this is a sensible starting point for a managed-ish HAPI deployment without paying for a commercial wrapper.
Choosing Among Them
Open-source picks usually come down to language fit (Java team picks HAPI or LinuxForHealth; Node team picks Medplum or fhir-kit-server), cloud fit, and the size of the maintenance crew you can dedicate. The HAPI vs Aidbox vs Medplum for US health systems goes deeper on a head-to-head that comes up often, and the self-hosted vs managed FHIR servers question is worth working through before the procurement starts. Pick the open-source server you can actually staff, not the one with the longest feature list.
Sources
Related Posts
