Orthanc vs dcm4chee: which DICOM server to choose

Orthanc or dcm4chee: when to choose each

Choose Orthanc when you need a self-hosted DICOM server that a small team can deploy, understand and extend quickly, and choose dcm4chee-arc-light when your organization already runs Java EE, wants LDAP-based central configuration and needs a full archive stack. Orthanc suits research groups and imaging centers that want a single server with a small footprint, configured through its own settings and extended with plugins. The core is GPLv3 or later, and the scalability and cloud plugins, including the PostgreSQL and web viewer plugins, are AGPLv3 or later, so confirm with counsel how AGPL obligations apply if you modify and expose those plugins to users over a network. Orthanc also ships official plugins for DICOMweb, S3, Azure, Google Cloud, modality worklists and the advanced authorization plugin, which lets you add features without forking the core.

Choose dcm4chee when your environment is built around WildFly, LDAP and a relational database that your DBAs already support. Its build supports DB2, Firebird, H2, MySQL, Oracle, PostgreSQL and SQL Server, requires Java 17 or newer, and uses LDAP as its configuration store under the DICOM Application Configuration Management Profile. It is licensed under the Mozilla Public License 1.1, which is a file-level copyleft license, so confirm with your legal team how it fits your distribution model. Bahmni Standard runs dcm4chee as its PACS, so hospitals already on Bahmni may find it the default choice. Expect more moving parts: the Docker reference setup includes OpenLDAP, PostgreSQL, the archive, Keycloak and the Elastic Stack.

The decision turns on three things. First, expected instance volume: Orthanc's built-in SQLite index should be replaced by an enterprise database once it holds several hundred thousand instances, and the PostgreSQL plugin is the documented route for large datasets, so model your growth before you choose the storage layer. Second, in-house skills: a team comfortable with Linux and configuration files will run Orthanc with less effort, while a team with Java and LDAP operations experience will find dcm4chee's model familiar. Third, workflow integration: if you need IHE-oriented workflows and a central LDAP directory across many modalities, test dcm4chee against those requirements, and if you need DICOMweb access for a viewer, confirm the connection with your chosen viewer before committing.

Which scenario fits which platform

This table maps common deployment settings to the platform that usually fits better and the reason behind it. Read each row as a starting point: the fit shifts with instance volume, the number of sites, existing EHR integrations and the team's operating skills.

Scenario	Better starting fit	Reason and where it depends on conditions
Small research group with one modality	Orthanc	Orthanc runs on Windows, macOS, Linux and Docker, and its built-in SQLite index is the default starting point. It stays simple to run, but the Orthanc Book says to move to an enterprise database once storage reaches several hundred thousand instances, so confirm expected growth before committing.
Imaging center with several sites and growing study volume	Depends on the team	Orthanc's PostgreSQL plugin lets multiple instances share one database, which supports horizontal scaling and high availability. dcm4chee's LDAP-based configuration and Elastic Stack options suit a team that can run Java, WildFly and LDAP. Ask each vendor or integrator to confirm the topology you need.
Hospital PACS with a Bahmni deployment	dcm4chee	The Bahmni Standard Docker Compose stack runs dcm4chee as its PACS alongside a pacs-integration service, so it is the imaging archive in Bahmni hospital setups. Choose Orthanc here only if you are willing to build and maintain the integration yourself.
Hospital PACS with an EHR other than Bahmni	Depends on integration	dcm4chee-arc-light offers DICOM Application Configuration Management through LDAP, which suits IHE-oriented workflows. Orthanc exposes DICOMweb and offers modality worklists and an advanced authorization plugin. Confirm which interfaces your EHR and modalities require before deciding.
Team that wants plugin-based extension without Java operations	Orthanc	Orthanc is a C++ server extended through official plugins for storage, DICOMweb, worklists and viewers. Its core is GPLv3 or later, but the PostgreSQL and web viewer plugins are AGPLv3 or later, so review license obligations with counsel if you modify and expose them.
Organization that already runs Java EE, WildFly and LDAP	dcm4chee	dcm4chee-arc-light requires Java 17 or newer and runs in WildFly under the Mozilla Public License 1.1. Existing skills in these components reduce the effort to operate it. Without them, budget time to learn the stack.
Environment that must avoid a single security setup for all access	Depends on setup	Orthanc accepts HTTP only from localhost by default and needs authentication, registered users and HTTPS behind a reverse proxy for remote access. dcm4chee's Docker setup includes Keycloak and secured variants. Confirm the identity model and audit needs with your security team.
Large archive expected to reach hundreds of thousands of studies	Orthanc with PostgreSQL, or dcm4chee with PostgreSQL	Orthanc's documentation cites hospital deployments with more than 65 TB, 340,000 studies and around 150 million instances, and recommends the PostgreSQL plugin at scale. dcm4chee also supports PostgreSQL. Ask for sizing evidence from both sides and test with your own modality mix.

How each server is built and what that means for operations

Orthanc and dcm4chee-arc-light solve the same archive problem with very different operating models. The cards below cover the core architecture, the configuration model, the Docker layers that dcm4chee brings with it, and the scaling path for each.

Orthanc's single binary and plugins

Orthanc is one server process whose core handles DICOM storage, query and retrieve, and a REST API. Databases, cloud object storage, DICOMweb, worklists and viewers arrive as plugins loaded into that process. Operations work is mostly about choosing which plugins to load and keeping their versions aligned with the core. Check which plugin versions your chosen Orthanc release supports before you upgrade either side.

SQLite index and its limits

Orthanc keeps its metadata index in SQLite by default, which needs no separate database server to run. The docs say this index should be replaced by an enterprise database engine once a site stores several hundred thousand DICOM instances. Plan the switch to the PostgreSQL plugin before go-live if your volume will grow into that range, because moving a populated archive is a migration project of its own.

dcm4chee's WildFly and LDAP configuration

dcm4chee-arc-light is a Java EE application that runs in WildFly and keeps its configuration in LDAP, following the DICOM configuration management profile. Operators manage archive entities, AE titles and routing rules in that directory rather than in a single local file. This suits teams that already run directory and Java application servers. Confirm that your team can administer LDAP schemas, WildFly and Java 17 or newer before committing.

Choosing the database for dcm4chee

The dcm4chee-arc-light build supports DB2, Firebird, H2, MySQL, Oracle, PostgreSQL and SQL Server. Choosing the database is a standards and support decision as much as a technical one, because your hospital's database platform team will own backups, patching and high availability. Ask whether your organization already runs one of these engines at the required support level, since that changes both licensing exposure and operating effort.

Docker layers in the dcm4chee stack

The Docker deployment separates OpenLDAP for configuration, PostgreSQL, the WildFly archive in plain, secure and secure-ui variants, Keycloak for sign-in, an OAuth2 proxy for Kibana, and Logstash. Each layer is another image to patch, another service to monitor and another credential set to rotate. Keycloak and the log stack add identity and audit capability but also raise the number of components your team must support. Map each layer to an owner before deployment.

Scaling Orthanc with shared PostgreSQL

Since Orthanc 1.9.2 with PostgreSQL and MySQL plugins 4.0, several Orthanc instances can read and write the same database. That makes horizontally scaled and highly available setups possible without moving to a different server. Storage placement, load balancing and shared-database failover still need design and testing in your own environment. Ask your vendor or integrator to document how instances share storage and which failure modes you have tested.

Capabilities, databases, security and identity side by side

This table sets the two DICOM servers against each other on license, runtime, databases, configuration, access defaults, identity and DICOMweb. Read each row as a question to answer for your own environment, and treat anything marked for confirmation as an item to check in the current documentation before you commit.

Capability	Orthanc	dcm4chee-arc-light
License	Core under GPLv3 or later; scalability and cloud plugins such as PostgreSQL and web viewer under AGPLv3 or later. No paid edition; support is sold as services.	Mozilla Public License 1.1. Confirm with your legal team how it applies to your modifications and deployment model.
Core language and runtime	C++ core with plugins; runs as a native process on Windows, macOS, Linux and Docker.	Java EE application running in WildFly; requires Java 17 or newer.
Supported databases	Built-in SQLite index; PostgreSQL, MySQL/MariaDB and ODBC through official plugins.	DB2, Firebird, H2, MySQL, Oracle, PostgreSQL and SQL Server. Confirm which combinations your release supports.
Configuration model	Plain configuration file and plugin settings; no central directory service.	LDAP as the central configuration store, following the DICOM Application Configuration Management Profile. Confirm the LDAP schema and tooling your team will need.
Default access	Accepts HTTP only from localhost by default.	Confirm the default security setup in the release you deploy, and whether the secure Docker variants are the path you need.
Authentication guidance	If remote access is enabled, turn on authentication and define users in RegisteredUsers; use HTTPS and a reverse proxy for internet exposure. Advanced authorization is a separate plugin.	Keycloak 26.0.6 appears in the Docker stack for identity. Confirm how it integrates with your identity provider and which roles you need to map.
DICOMweb support	Available through the official DICOMweb plugin. Confirm the endpoints you need against the plugin documentation.	Confirm the DICOMweb services enabled in your build and their configuration in the archive documentation.
Typical fit for identity integration	Works well when access control is handled by a reverse proxy and a small set of named users.	Works well when the archive must sit inside an existing LDAP and SSO estate. Confirm the integration effort before you choose it.

Licensing, copyright and what is paid for

Orthanc's licensing differs by layer. The core server is licensed under GPLv3 or later, while the scalability and cloud plugins, including the PostgreSQL and web viewer plugins, are licensed under AGPLv3 or later. Copyright is shared across several holders over time: the University Hospital of Liege (2012 to 2016), Osimis S.A. (2017 to 2024, now defunct), Orthanc Team SRL (2024 to present) and UCLouvain (2021 to present). UCLouvain contributions made since September 1, 2021 cannot be dual licensed, so the project cannot offer a proprietary commercial licence covering those contributions.

Core licence: GPLv3 or later applies to the server itself.
Plugin licence: AGPLv3 or later applies to the PostgreSQL and web viewer plugins, which matters if you modify them and make them available to users over a network.
Copyright holders: four parties are named, and one of them is no longer operating, so confirm the chain of contributions with your legal team.
No paid edition: there is no commercial edition of Orthanc to purchase.
Paid services: Orthanc Team SRL sells deployment, configuration and development services, plus pre-paid dedicated support hours valid for 12 months, quoted on request.

Ask counsel how GPL and AGPL obligations apply to your internal use and any modifications, and request the support hour terms in writing.

What the scale evidence does and does not prove

The Orthanc documentation gives scale guidance and production figures that are useful for planning, but they describe Orthanc deployments only. Use them to decide when to plan a database move, then test both archives against your own workload before you commit.

Where SQLite stops being enough

The Orthanc docs say the built-in SQLite index should be replaced by an enterprise database engine once Orthanc stores several hundred thousand DICOM instances, and they recommend the PostgreSQL plugin for large datasets. This is a planning threshold from the vendor, not a hard failure point. If your archive is growing toward that range, budget time for a database decision early, because the PostgreSQL plugin is AGPLv3 or later and needs its own license review.

Cited Orthanc production deployments

The Orthanc Book cites production hospital deployments holding more than 65 TB of data, 340,000 studies and around 150 million instances. These are the largest figures the vendor publishes, and they show that Orthanc has been run at that size. They do not give you the hardware, database layout, network design or modality mix behind those systems, so ask the vendor or the deploying sites what those were before you treat them as a benchmark.

Vendor figures do not measure dcm4chee

Nothing in the Orthanc documentation measures dcm4chee-arc-light. A high Orthanc count tells you nothing about how the WildFly-based archive handles the same load, its LDAP configuration lookups, or its PostgreSQL behavior at your volume. Treat the Orthanc numbers as an Orthanc result only, and ask dcm4chee users or their own references for equivalent evidence rather than assuming the figures transfer.

Scale-out depends on the database

Since Orthanc 1.9.2 with PostgreSQL or MySQL plugins 4.0, several Orthanc instances can read and write the same database, which enables horizontally scaled and highly available setups. Whether that works for you depends on your database operations, network latency to storage and failover testing. Check how the plugin behaves during node failure and what your operators must maintain, instead of assuming a multi-node layout is ready for production.

Load test on your own systems

Before deciding, run a load test that matches your modalities, storage backend, network path and retention policy. Measure C-STORE ingest from each modality at peak, C-FIND and C-MOVE response under concurrent viewer use, storage write throughput, and recovery time after a restart. Run the same script against both archives on the same hardware. Results from your own environment are the only scale evidence that will support a sizing decision.

Confirm the figures with each vendor

Ask Orthanc Team and the dcm4chee community for the hardware, database engine, instance counts, study mix and uptime behind any figure you plan around. Ask for the test method and the version used. Note that the Orthanc Team sells services and that the cited deployments are its own reference points, so request written support scope for performance tuning if your sizing depends on it.

Moving an archive from one server to the other

This sequence moves stored DICOM studies between Orthanc and dcm4chee with the modality, viewer and integration behavior intact on the new server. The old store is retired only after the new one has been checked against the same studies and workflows.

Inventory modalities, AE titles and integrations
Your PACS or imaging administrator lists every modality, workstation and viewer that sends to or reads from the current archive, with its AE title, host, port and transfer syntax needs. The same list covers EHR, RIS and reporting links, plus any DICOMweb or worklist consumers. Record which systems are configured on the old server and which are configured on the modalities themselves. The inventory is complete when every sender and reader has an owner and a row in a shared sheet that the migration team signs off.
Map existing configuration to the target model
The engineer compares how the source server stores its settings with how the target server stores them. Orthanc uses JSON configuration files and its own user and authorization settings. dcm4chee keeps its configuration in LDAP following the DICOM Application Configuration Management Profile, so AE definitions, devices and routing rules are recreated there rather than copied file for file. Write down each rule, user group and worklist filter as a target object. The mapping is done when every source setting has a matching target object or a documented decision to drop it.
Stand up the target and test with sample studies
Deploy the target server in a non-production environment that matches your planned production topology, including the database choice. Send a small set of representative studies from one modality and one viewer to confirm storage, retrieval and metadata handling. Check that the target stores the DICOM objects and returns them unchanged to the viewer. The step is complete when test studies round-trip with matching study, series and instance counts.
Export or re-send studies to the target
Choose a transfer method by volume. For smaller archives, the storage team can export studies from the source and import them into the target. For larger archives, the source can forward studies to the target over DICOM C-STORE in batches, which keeps the old server as the system of record during the copy. Track progress by study count and checksum, and keep the source read-only for the cutover window. Confirm that the target instance and study counts match the source for each batch before moving on. Effort depends on the volume and the number of integrations, so confirm both with the vendor or the implementer before agreeing a schedule.
Rebuild routing, authorization and worklist rules
Rebuild forwarding rules, retention behavior, user roles and worklist filters on the target server using the mapping from the earlier step. On the Orthanc side, check that remote access and authentication settings follow the security guidance before any cross-network access is opened. On the dcm4chee side, confirm that the LDAP entries and the Keycloak-based access setup match the role model your users expect. Test each rule with a sample transaction from a real sender and record the result. The step is complete when every routing and access rule passes its test case.
Re-point viewers, EHR and PACS integrations
Update each viewer, EHR, reporting and worklist consumer to use the new server's AE title, host, port or DICOMweb endpoint. Modalities need their own configuration changes to send to the new AE title, and those changes often need the device owner or vendor. Test one study from each modality and one retrieval from each viewer, confirming that patient identifiers and study links resolve as before. The step is complete when each integration has a signed-off test result.
Validate parallel operation, then retire the old store
Run both servers in parallel for a period agreed by the clinical and imaging leads, with new studies sent to the target and reconciled against the source. Compare study counts, retrieval success and audit logs between the two systems. When the reconciliation is clean, make the source read-only, take a final backup, and document the retirement decision and the backup location. Retire the old server only after the backup restore has been tested. The migration is closed when the signed-off checklist, the reconciliation report and the backup record are filed together.

Where implementation projects usually run long

Implementation projects for either server usually run long because of work that sits outside the install. For Orthanc, scope the plugin selection early: the PostgreSQL, S3 or Azure storage choices, the DICOMweb and modality worklist plugins, and the authorization plugin each add configuration and testing. Decide how RemoteAccessAllowed, AuthenticationEnabled and RegisteredUsers will be set, and who owns the HTTPS termination and reverse proxy the Orthanc Book recommends for any Internet exposure. Those decisions change the storage and access design, so make them before the build starts.

For dcm4chee-arc-light, the longer tail usually sits in operations. Scope the LDAP configuration tree that holds the archive's settings, the WildFly deployment and its Java 17 or newer runtime, the chosen database from the supported list, and the log stack, including Elasticsearch, Logstash, Kibana and the OAuth2 proxy in the Docker layout. Confirm which of these your platform team will run, patch and monitor, and whether the Keycloak identity setup in the reference Docker stack fits your directory. Ask the integrator to state the exact image versions and the upgrade path in writing.

On both platforms, the costliest delays tend to be modality configuration, identity integration, validation against your own clinical workflow and backup and upgrade routines. Modality configuration means every scanner, workstation and PACS peer must be registered and tested, and that work depends on the people who control those devices. Identity integration can stall on access policy. Workflow validation needs test studies that mirror real acquisition and retrieval. Backup and restore must be proven, not assumed, and upgrade testing should be a written deliverable. Ask for each of these as a named line item with an owner, acceptance criteria and a scoped number of test cycles.

Questions buyers ask before choosing a DICOM archive

What drives the cost of running Orthanc or dcm4chee?

The software costs nothing to license in either case, so the cost sits in infrastructure, staff time, support and upgrades. Orthanc has no paid edition, and Orthanc Team SRL sells deployment, configuration and development services, including pre-paid dedicated support hours valid for 12 months, quoted on request. dcm4chee-arc-light is licensed under the Mozilla Public License 1.1, so license fees do not apply here either. Recurring costs come from storage growth, hosting for the archive and database, the people who patch and monitor it, and the work of each major upgrade. Ask any provider for a written quote that separates one-time setup from recurring operations, and ask what each line covers.

Can a team run Orthanc or dcm4chee without outside help?

A team with Linux administration and some DICOM knowledge can run Orthanc on a single host, since it is distributed for Windows, macOS and Linux and as Docker images. A larger archive with LDAP configuration, a secured WildFly deployment, Keycloak and the Elastic Stack is a heavier job that usually needs staff comfortable with Java EE application servers. Whether your team can do this alone depends on its existing skills, on-call capacity and how much integration with your PACS, viewers and identity systems you need. Outside help is an option for planning, implementation, hardening and retainer-based support, which DeployOpen offers under a written scope.

How long does a DICOM archive deployment take?

No supplied fact gives a general timeline, so treat any number you hear as a claim to verify. The duration depends on the number of modalities and sites, the volume of existing studies to migrate, the authentication model, integration with the EHR or viewers, and the testing and sign-off your organization requires. A single-host Orthanc test instance can be stood up quickly, while a secured multi-service dcm4chee environment with directory-based configuration takes longer to design and validate. Ask for a timeline in the written scope, with the assumptions that would change it.

What Linux, Java and database skills does each server need?

Orthanc needs Linux or Docker skills, a clear view of its configuration file, and, for larger sites, familiarity with PostgreSQL or another supported database through its plugins. dcm4chee-arc-light needs Java 17 or newer, WildFly, LDAP for configuration through the OpenLDAP image, and one of the supported relational databases, including PostgreSQL versions 12 to 18 in the Docker setup. Your team also needs skills for Keycloak and log tooling if you adopt the secured Docker stack. Confirm which of these skills are on staff before you choose, because a missing skill is usually the largest hidden cost.

Is migrating between Orthanc and dcm4chee practical?

Migration is possible but not a configuration switch, because the two servers store data and configuration in different ways. Orthanc keeps its index in SQLite or a database through plugins, while dcm4chee uses LDAP for configuration and a relational database for its archive. The practical work is moving stored DICOM objects, mapping AE titles and routing rules, reconfiguring modalities and viewers, and validating a sample of studies before cutover. Plan for a parallel run and ask any implementer for a migration plan in writing, including rollback steps and what happens to in-flight transfers.

What security setup does each server need before going live?

Orthanc is safe by default because it only accepts HTTP connections from localhost. If you enable RemoteAccessAllowed, the documentation says to set AuthenticationEnabled to true, define users in RegisteredUsers, and place a reverse proxy with HTTPS in front of it for any Internet exposure. dcm4chee's secured Docker variants add Keycloak and an OAuth2 proxy for log access, so identity design is part of the build. Your security and compliance team should own the access model, audit logging, encryption and network segmentation, and should confirm them against its own frameworks. DeployOpen can prepare systems and evidence for compliance assessments, but it does not issue audit reports or certifications.

How do I check which archive scales to my study volume?

Start by measuring your current and projected instance count, not only your study count. The Orthanc documentation says the built-in SQLite index should be replaced by an enterprise database engine once several hundred thousand DICOM instances are stored, and cites production hospital deployments holding more than 65 TB, 340,000 studies and around 150 million instances. Since Orthanc 1.9.2 with PostgreSQL and MySQL plugins 4.0, multiple instances can share one database for horizontal scaling and high availability. Ask dcm4chee's implementers for comparable production figures, and run a load test against your own modalities and retention rules before deciding.

What drives the running cost of each platform

The running cost of an Orthanc or dcm4chee-arc-light archive is mostly people and storage, not licenses, because neither product has a license fee to pay. Orthanc has no paid edition, and dcm4chee-arc-light is licensed under the Mozilla Public License 1.1. Your budget therefore goes to the infrastructure that holds the studies, to in-house administrators who keep the server patched and backed up, and to any outside work you buy. For Orthanc, that outside work can come from Orthanc Team SRL, which sells deployment, configuration and development services, including pre-paid dedicated support hours valid for 12 months and quoted on request. For dcm4chee, you pay whoever runs the Java EE stack for you, which in practice means your own platform team or an integrator.

One-time costs are installation, configuration of the archive and its modalities, and migration of any existing data. For dcm4chee-arc-light, the one-time work is heavier because LDAP holds the central configuration and you must also prepare the database (the build supports PostgreSQL, Oracle, SQL Server and others), WildFly and Java 17 or newer. Recurring costs are storage growth, which is usually the largest line item for a hospital PACS, upgrades, backups and restore tests, and support. Upgrades recur on both sides: Orthanc 1.13.0 was released on 2026-08-15 and dcm4chee-arc-light 5.35.2 on 15 October 2026, so ask who tests each release against your modalities and who signs off the change window. When you request a quote from any implementation partner, insist on a written scope that names the components (archive, database, LDAP or configuration store, identity, reverse proxy, backup target, viewers), the deliverables for each, and the acceptance tests. Ask whether support is pre-paid hours, a retainer, or per-incident, how many hours are included, what response windows apply, and which upgrades and security patches are covered. Ask for the storage sizing assumptions in writing, including how many studies per month you expect, so the storage line can be checked against your own growth figures.

How DeployOpen helps choose, implement or migrate a DICOM archive

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Orthanc or dcm4chee decision is tested against your network, identity setup and imaging workflow. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we scope

We map your modalities, expected study volumes, retention rules and the systems that must query or receive images.
The written scope names the platform, database engine, storage backend, viewer and identity integration you have agreed.
We record which DICOM services, DICOMweb endpoints and remote-access paths are in scope before any work starts.

How we build

We deploy the chosen archive in your cloud account, data center or air-gapped network, using your own storage and database.
We configure authentication, HTTPS and reverse proxying, and test access controls against the scope you signed off.
We integrate the archive with your viewer, worklist and EHR interfaces, and test transfers with representative sample studies.

How we hand over

You receive architecture notes, configuration records, backup and restore procedures, and an operations runbook.
We document the security setup and the evidence an assessor would ask for, without claiming any audit or certification result.
Your administrators walk through upgrade steps, so your team can apply future Orthanc or dcm4chee releases confidently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped separately in writing.
A retainer can cover platform upgrades, plugin updates, backup verification and periodic security testing of the archive.
Ask any provider to confirm response expectations, change control and who holds the database and configuration backups.

Orthanc vs dcm4chee