What upgrades and support involve for Orthanc
Upgrading Orthanc means moving the core server and every installed plugin to versions that work together, then testing before production cutover. The core is licensed GPLv3 or later, while plugins such as the PostgreSQL and web viewer plugins are AGPLv3 or later, and each plugin release is tied to a specific core series. A core upgrade that looks routine can break a database plugin, a DICOMweb configuration or a viewer if the pairing is not checked. Before any change, confirm the target version of each component in the release notes and in your own configuration inventory.
Four kinds of trigger usually start an upgrade. The first is a new minor release, such as 1.13.0, which was released on 2026-08-15 and includes a rewrite of storage-area access and DICOM parsing and transcoding. The second is a security fix. The third is a change of database back end, for example moving the index from SQLite to PostgreSQL. The fourth is an unsupported older build still in service. Each trigger needs a different test scope. A security fix may need only regression checks, while a storage or schema change needs verified study counts, DICOM transfer tests and viewer checks before cutover.
Orthanc has no paid edition, so there is no vendor support contract bundled with the software. Support is either handled by your own staff using the public documentation and community channels, or bought as services from Orthanc Team SRL, which sells deployment, configuration and development work and pre-paid dedicated support hours valid for 12 months, quoted on request. Ask any provider which hours are included, how urgent issues are triaged, and whether plugin compatibility checks are part of the quote.
What the work includes
Each card is a stage of an Orthanc upgrade or support engagement, with the deliverable you keep at the end. Scope and cost are agreed in writing before work starts, and the stages can be bought together or individually.
Release assessment
We read the release notes for the target Orthanc version, such as the move from 1.12.x to 1.13.0, and map each change against your configuration, plugins, REST calls and storage setup. The output is an upgrade report listing the changes that affect your deployment and the ones that do not. Ask us to confirm which breaking changes apply to your database back end before testing begins.
Test environment build
We build a non-production copy of your Orthanc stack with the same core version, plugins, database engine and configuration as production, using a copy of your data or a representative sample agreed with you. The test environment is where every later check runs. Confirm that it is isolated from modalities and clinical workflows so test traffic cannot reach live systems.
Core and plugin upgrade
We upgrade the Orthanc core and each plugin to a set of versions that are tested together, then record the pairing. Plugins such as the PostgreSQL, DICOMweb, Orthanc Explorer 2 and authorization plugins can lag the core, so the deliverable is a list of plugin versions tied to the core version. Ask for that list in writing before production changes.
Database schema validation
We check the database schema after upgrade for SQLite or PostgreSQL, confirm that migrations complete, and compare index and table state with the pre-upgrade baseline. Where Orthanc runs with multiple instances on a shared database, we also check that all nodes run compatible versions. Ask for the migration log and the backup taken before the schema change.
DICOM and DICOMweb regression checks
We run store, query, retrieve and modality worklist tests across C-STORE, C-FIND, C-MOVE and DICOMweb endpoints, and compare results with the pre-upgrade run. Instance and study counts, transfer syntaxes and transcoding results are compared, since the 1.13.0 release changed DICOM parsing and transcoding. Confirm which modalities and external systems must be included in the test matrix.
Viewer and authorization checks
We test the viewers you expose, such as Orthanc Explorer 2, Stone Web or OHIF, along with the access rules that apply to each user group. For deployments using the advanced authorization plugin or a token service, we confirm that denied requests still return the expected HTTP 403 response. Ask us to list the user roles and studies used in the test cases.
Rollback plan
We write a rollback procedure that restores the previous core, plugin versions and database state, with the backup and restore steps in the order they must run. The plan states the trigger conditions for rollback and who makes that call. Ask us to rehearse the rollback in the test environment so the timing and steps are known before production.
Runbook and handover
We deliver a tested runbook covering the upgrade steps, post-upgrade checks, version pairings and known issues, then hand it to your operations staff with a walkthrough. The runbook is the document your team uses for the next upgrade without us. Confirm who on your side will own it and where it is stored.
Optional support retainer
Ongoing support covers release monitoring, patch review, plugin compatibility checks and help with incidents between upgrades. Orthanc has no paid edition, so this is a service agreement with DeployOpen rather than a vendor license. Ask for the response expectations, the hours included and what is billed separately before you agree.
What drives effort and duration
The table lists the factors that change how much work an Orthanc upgrade or ongoing support engagement takes, why each one adds effort, and how to keep it manageable.
| Driver | Why it adds work | How to keep it down |
|---|---|---|
| Installed plugins | Each official or custom plugin has its own release cycle, configuration and compatibility with the core version, so every plugin must be retested on each core upgrade. | Enable only the plugins the workflow needs, pin known-good plugin versions, and remove unused plugins before the upgrade starts. |
| Database back end and sharing | The PostgreSQL, MySQL/MariaDB or ODBC plugins and any schema change must be tested, and a database shared by several Orthanc instances must be upgraded in a planned order. | Confirm the schema migration path for the target release, rehearse it on a copy, and stop all instances sharing the database in a documented sequence. |
| Archive size and instance count | Migration rehearsals, reindexing and full-archive verification take longer as the number of studies and instances grows, and backups take longer to restore for testing. | Test against a representative data subset that covers each modality, transfer syntax and study type, then run a full-archive check only on the production cutover. |
| Object storage back end | Changes to the storage plugin or to how files are addressed can affect existing data, so storage access must be verified after each upgrade. | Verify read, write and delete paths against the storage bucket with a sample of studies before and after the upgrade. |
| Environments | Development, test, staging and production each need the upgrade applied, tested and documented, and configuration drift between them increases rework. | Keep one configuration source for all environments, promote the same versioned package through each one, and record differences explicitly. |
| Custom Lua or Python scripts and REST integrations | Scripts and integrations depend on REST routes, events and internal behavior that can change between releases, so each one needs regression testing. | Keep custom code small, list every route and event it uses, and maintain a regression test set that exercises each integration. |
| Modalities and PACS peers | Every DICOM connection, worklist source and DICOM TLS peer must be checked after an upgrade, and some peers may need coordinated changes on their side. | Keep an inventory of AE titles, ports and peer settings, and run a C-ECHO and test C-STORE from each peer after the upgrade. |
| Compliance evidence needed | Change records, test results, approval records and access reviews must be produced for each upgrade, which adds documentation work beyond the technical change. | Agree the evidence list before the work starts and generate it from the change process so it is collected once. |
| Version jump size | Moving across several minor releases, such as 1.12 to 1.13, can change storage, parsing and configuration behavior, which widens the test scope compared with a patch update. | Read the release notes for every version in the jump, plan smaller steps where the notes flag breaking changes, and confirm the target release notes before quoting. |
How an upgrade project runs
The sequence below takes an Orthanc core and plugin upgrade from a documented baseline to a tested cutover, with a handover that leaves your team able to run the next upgrade.
Inventory the current deployment
We record the current Orthanc core version, every installed plugin and its version, the database back end (SQLite, PostgreSQL or MySQL/MariaDB), storage configuration, the orthanc.json settings, custom scripts, and every system that calls Orthanc, such as modalities, DICOMweb clients, viewers and export jobs. The output is a written baseline that your team signs off, so nothing in the environment is changed by surprise.
Review release notes for every intermediate version
We read the Orthanc NEWS file for each version between the current release and the target, not only the final one, and map each change to your baseline. Breaking changes, changed defaults, removed options and plugin compatibility notes are listed against your configuration. The output is a release review that names every change needing action, a test, or a decision from your team.
Rebuild the test environment from production data
We build a non-production environment that matches the baseline: same core and plugin versions, same database engine, and the same configuration. It is loaded with a copy of production data or, where a full copy is not permitted, a representative subset agreed with your data owners. The output is a test environment with a recorded data set and a check that its contents match the source.
Rehearse the schema and storage migration
We run the database schema upgrade and any storage-area changes on the test environment, measuring how long each step takes and how it fails if interrupted. The rehearsal is repeated until the steps are reliable. The output is a migration runbook with exact commands, checkpoints, and verified instance and study counts before and after.
Run functional and performance regression tests
We test the scenarios your clinical and operational users depend on: C-STORE and C-FIND from each modality, DICOMweb queries, viewer access, worklist queries, authorization rules and scripted exports. Performance is compared with the baseline under load that resembles your normal traffic. The output is a signed regression report listing each failure, its fix, and the retest result.
Cut over with a tested rollback
We run the migration runbook in the production window agreed with your team, verify counts and sample studies, then re-enable modality and client connections in a controlled order. A rollback path is prepared and rehearsed before cutover, including the database backup and the previous package. The output is a cutover record with verification results and the confirmed rollback decision point.
Hand over and agree support options
We deliver the final documentation: as-built configuration, the upgrade runbook, test scripts, monitoring checks and the known issues list. Your team runs a supervised session on the production system, then we agree how future upgrades and support will be covered, including any pre-paid support hours. The output is a handover pack and a named list of who owns each operational task.
What usually goes wrong
Most Orthanc upgrade problems come from a small set of predictable gaps: mismatched plugins, untested schema changes, and integrations nobody re-checked. Each card below names one risk and the step that prevents it.
Plugin and core version mismatch
Orthanc core and its plugins, such as the PostgreSQL, S3 or DICOMweb plugins, are released separately and must be matched to each other. Before any upgrade, list every installed plugin and its version, and confirm in the Orthanc Book which plugin builds support the target core release in your environment.
Schema changes without tested rollback
Database schema changes applied during an upgrade can make the previous core version unable to read the index. Take a restore-tested backup of the database and the storage area, and rehearse a full rollback on a copy of production data before the production upgrade window is approved.
Storage and DICOM parsing behavior changes
Orthanc 1.13.0, released on 2026-08-15, rewrote storage-area access and DICOM parsing and transcoding to improve caching and reduce memory use. Load-test representative studies on the new release and watch memory, cache hit rates and transcoding latency before the upgrade is accepted for production.
Consumers broken by REST changes
Modalities, viewers, scripts and reverse proxies often depend on specific REST responses and routes. Inventory every system that calls Orthanc, replay their real requests against the target version, and confirm that each one still parses responses correctly before cutover.
Authorization plugin not re-checked
The advanced authorization plugin forwards each REST request's token to an external web service, such as a token service built on Keycloak. An upgrade can change how requests reach that service or how tokens are read. Re-test denied and allowed access for each user role, including the HTTP 403 responses, after every core or plugin change.
Skipping intermediate releases
Jumping directly across several minor releases, for example from 1.12 to 1.13, means missing the migration notes and behavior changes published in each intermediate release. Read the NEWS file for every version between the current and target release, and record which steps apply to your configuration.
Single owner of the runbook
When one administrator holds the only copy of the upgrade procedure, test accounts, and knowledge of the plugin configuration, an absence can stall or derail the next upgrade. Keep the runbook in version control, name a second trained operator, and rehearse one full upgrade with both people present.
Support models: in-house, retainer or dedicated hours
This table compares three ways to keep Orthanc current, showing the skills each needs, what usually stays in-house and what is usually bought, so you can match a model to your team and risk appetite.
| Model | Skills required | Usually kept in-house | Usually bought |
|---|---|---|---|
| Internal team | Linux or Docker operations, DICOM and PACS knowledge, database administration for PostgreSQL or SQLite, and a clinical or imaging workflow owner | Change approval, clinical sign-off, monitoring and on-call response, and decisions about when to upgrade | Little by default, unless you choose to bring in outside help for specific releases or incidents |
| DeployOpen retainer | Shared responsibility: DeployOpen supplies upgrade, testing and on-call skills, while you supply the environment owner and clinical contact | Change approval, clinical sign-off and the production monitoring you already run | Scheduled upgrades, release assessment, cross-version testing, plugin upgrades and on-call support, as set out in the written scope |
| Pre-paid dedicated hours from Orthanc Team SRL | Vendor-level expertise on Orthanc itself, with your team or a partner handling operations, testing and sign-off | Operations, testing evidence, change approval, clinical sign-off and monitoring | Specific questions, fixes, configuration help or development work, drawn from hours valid for 12 months and quoted on request |
| Who signs off the change | Your change authority in every model | Always kept in-house, because clinical and governance decisions stay with your organization | Not transferred to any supplier, whichever model you choose |
| Schema change testing | Database administration plus a test copy of your archive large enough to exercise migrations | Test sign-off, rollback decisions and the go or no-go call | Cross-version test runs and schema change assessment within the retainer scope |
| Plugin compatibility | Knowledge of which plugins you run, such as PostgreSQL, S3, DICOMweb or viewer plugins, and their license terms | Inventory of plugins in use and the decision to keep or retire them | Compatibility checks and plugin upgrades matched to the core release you adopt |
| Cost pattern | Salaried staff time, which recurs and is harder to scale down during quiet periods | Internal labor, which is recurring and shared with other duties | Retainer fees recur on a fixed scope; hours are pre-paid and drawn down. Ask for the quote and the renewal terms in writing |
| Best fit | Organizations with a stable internal platform team and an imaging owner who can take on operations | Organizations that want a fixed, recurring operating model without building all skills in-house | Organizations that already run Orthanc well and need targeted expertise for a specific question or release |
How the work changes by starting point
This is the simplest starting point: one Orthanc process, one local SQLite index and files on a local or attached disk. Most of the upgrade risk sits in the index and the stored files, so the plan focuses on a complete copy before any change.
- Test scope: Load a copy of your production data into a staging server running the target core and each plugin version, then check study counts, series counts and a sample of retrievals.
- Schema validation: Confirm that the index upgrade completes on the copy and that the database file is consistent before the production run.
- Rollback: Keep a cold copy of the database and storage folder taken while Orthanc is stopped, and confirm the previous binary and plugins can be reinstalled.
- Client provides: A staging host with comparable disk, a maintenance window agreed with clinical users, and access to the current configuration file.
- Ask the vendor or DeployOpen: Whether a planned upgrade path from SQLite to a database plugin is part of this scope or a separate migration.
Here the metadata lives in PostgreSQL or MySQL/MariaDB and the DICOM files live in S3, Azure or Google Cloud object storage. The database plugin and the storage plugin are versioned pieces that must match the core, so each must be tested together.
- Test scope: Test the core, database plugin and storage plugin as one combination, including uploads, retrievals, deletions and any lifecycle rules on the bucket or container.
- Schema validation: Compare schema state before and after the upgrade on a restored database copy, and check that object keys in storage still map to index entries.
- Rollback: Snapshot or point-in-time restore the database and enable object versioning or a bucket copy where your provider supports it, since database and object store cannot be rolled back independently.
- Client provides: Database administrator access for the staging restore, cloud accounts with permissions to create test buckets, and the plugin versions you run today.
- Confirm: Your database engine version is supported by the plugin release you target, and the rollback window matches your backup retention.
When several Orthanc instances share one database, an upgrade can leave some instances on the old version and others on the new one. The official scalability guidance covers shared database access from release 1.9.2 with compatible plugin versions, so mixed-version behavior is the main test concern.
- Test scope: Include a rolling upgrade on the staging cluster, with reads and writes running from both versions during the transition, and failover of the load balancer.
- Schema validation: Check that the shared schema change is applied once and that older instances still operate safely against it, or that a full stop is required and is planned for.
- Rollback: Define whether rollback means rebuilding instances from the previous image or restoring the shared database, and rehearse the choice.
- Client provides: Load balancer or ingress control, orchestration or configuration management for the instances, and a staging cluster that matches production node count.
- Confirm: Whether the target release supports mixed-version operation in your topology, since this is not something to assume.
The packaging method changes how the binary and plugins are replaced and how quickly you can return to the earlier version. Docker images are versioned as units, while operating system packages update files in place and bring their own dependency and service changes.
- Test scope: Test the exact image tag or package versions you will deploy, including the plugin libraries that the image or package includes or loads.
- Schema validation: Run the same database and storage checks regardless of packaging, since the schema work does not change with the delivery method.
- Rollback: With Docker, keep the previous image tag and its configuration mounted as volumes; with packages, keep the previous package files or a system snapshot, because downgrades are not always clean.
- Client provides: Your registry or package mirror, configuration management records and the host or container runtime versions in use.
- Confirm: Which packages or images in your distribution carry the plugins you need, since availability differs across platforms.
In an offline network, nothing is downloaded during the upgrade. Release files, plugin binaries, container images and any operating system dependencies must be staged inside the network and verified before they reach the production system.
- Test scope: Rehearse the full install from the staged media on an isolated staging network, including every plugin you run, not only the core.
- Schema validation: Because no external tool can be fetched during the change, prepare and test the schema and migration scripts in advance and store checksums with them.
- Rollback: Keep the previous release files and plugin binaries staged alongside the new ones, and confirm they still install on the current operating system.
- Client provides: An internal artifact repository or media store, a process for importing and checksumming release files, and a staging network that mirrors production.
- Confirm: The licensing terms that apply to each component you redistribute internally, since the core and plugins carry different licenses.
What you need to provide
Before an Orthanc upgrade starts, the client supplies the inputs the work cannot be done without. Access to the production and test hosts, or to the container platform that runs Orthanc, is the first. Database credentials for the PostgreSQL or MySQL/MariaDB back end, and credentials for the S3, Azure or Google Cloud object storage, must carry backup rights so the pre-upgrade snapshot can be taken and verified. Ask the team to confirm which storage area holds the DICOM files and whether the index is SQLite, PostgreSQL or another engine, because that decides the schema test plan.
Next, provide a current configuration file, a plugin inventory with versions, and a list of the DICOM peers, modalities and DICOMweb clients that send to or read from the server. Include the viewers in use, such as Orthanc Explorer 2, Stone Web or OHIF, and any advanced authorization setup. The test dataset should be representative of real modalities and transfer syntaxes and must be de-identified or approved for use in a non-production environment. Confirm the approval in writing with your privacy or data protection owner before it is copied anywhere.
Name the owners who must agree to the rollback plan: the imaging or clinical owner, the infrastructure owner who controls the hosts and backups, and the security owner for any changes to authentication or exposed routes. The clinical or imaging owner also signs off on test results, so name that person and the sign-off criteria, and agree a change window with enough time to restore from backup if needed. Decide the support model before the upgrade, whether that is pre-paid dedicated hours from the Orthanc vendor, an internal team or a mix, because it determines who answers a problem after cutover.
In return, the client receives a runbook covering the pre-upgrade checks, the upgrade steps, the rollback procedure and the post-upgrade verification. It also receives test evidence: the schema and plugin test results, the transfer and query checks, and the sign-off record. A handover session transfers operational knowledge to the team that will run the server, and the documents stay in the client's own repository.
Common questions about Orthanc upgrades and support
Does Orthanc have a paid edition with included support?
No. Orthanc has no paid edition. The core is free software, and support is bought as services from Orthanc Team SRL, which sells deployment, configuration and development work, including pre-paid dedicated support hours that are valid for 12 months. Those hours are quoted on request, so the support you need is set out in a written scope rather than a license tier. Ask any provider to state in writing which hours are included, what they cover and what happens to hours you do not use within the validity period.
How is the cost of Orthanc upgrades and support determined?
Cost follows the scope, so no fixed price applies. The main drivers are the number of Orthanc instances and plugins, whether the database is SQLite or PostgreSQL, the size of the archive, how many modalities and viewers connect, the test effort needed before a release goes live, and how often you want support. DeployOpen does not publish prices. A quote follows from a written scope that lists deliverables, environments and timelines, and it is fixed in writing before work begins. Ask for one-time work and recurring support to be priced separately.
Can our own team upgrade Orthanc without outside help?
Yes, for routine patch releases, if you have a test environment that mirrors production and a tested rollback plan. Cross-release changes need more care. Upgrades such as 1.12 to 1.13 can change behavior in storage access, DICOM parsing and transcoding, and database schema changes must be tested against a copy of your real data, including plugin versions. Read the release notes for every version between your current and target release, and confirm plugin compatibility before you start.
How long does an Orthanc upgrade take?
The duration depends on the drivers in your environment, so it should be confirmed in the written scope rather than assumed. The main factors are the number of releases crossed, the size of the database and storage area that must be migrated and verified, the number of plugins and integrations to retest, and how much of the test cycle your team runs itself. Ask the provider to state the duration, the assumptions behind it, and the dates on which your environment and sign-off are needed.
What must our team provide for an Orthanc upgrade engagement?
Expect to provide access to the current servers and configuration, a test environment that resembles production, a copy or representative sample of the database and storage, a list of connected modalities, viewers and integrations, and named people who can approve test results and go-live. You will also need a backup you can restore and a maintenance window for cutover. Confirm these inputs in the scope, because missing test data or unavailable approvers are common causes of schedule slippage.
Can Orthanc upgrades and support be delivered in an air-gapped network?
Yes, in principle, because Orthanc is self-hosted and DeployOpen works inside the client's own infrastructure, including air-gapped networks. The practical questions are how packages, Docker images and plugin binaries reach the isolated network, how security patches are validated and transferred, and how remote support sessions are allowed or replaced by on-site work. Confirm the transfer process, the access model and the evidence you need from each change before the scope is agreed.
How DeployOpen scopes and supports Orthanc
DeployOpen plans, implements, tests, documents and supports Orthanc upgrades inside your own infrastructure, with each engagement agreed as a fixed scope in writing. Because Orthanc has no paid edition, the written scope and any ongoing retainer define exactly who maintains the server, its plugins and its database after go-live.
How we scope
- We record the current Orthanc core version, plugin set and database back end before proposing an upgrade path.
- The written scope names every plugin, such as PostgreSQL, S3 or DICOMweb, that must be upgraded or retested together.
- We confirm which environments, such as test, staging and production, the upgrade will pass through and who approves each step.
How we build
- We rehearse the core and plugin upgrade on a copy of your environment before any production change is made.
- Database schema changes are applied to a restored copy and checked for stored study, instance and index counts before cutover.
- Rollback steps, backup restore tests and the configuration changes needed for the new release are documented as deliverables.
How we hand over
- Your team receives a runbook covering the upgrade steps, configuration differences and verification checks used during testing.
- We provide a written record of the versions installed, plugin releases applied and any settings changed from defaults.
- Knowledge transfer sessions cover how to read Orthanc release notes and decide when a future upgrade needs a new scope.
How we support
- Ongoing support and scheduled upgrades can be arranged as a retainer, with the response expectations written into that agreement.
- Each future release is reviewed against your plugins and database back end before it is scheduled for your environment.
- Ask for the support terms, included hours and escalation path in writing, since Orthanc Team SRL sells dedicated support hours separately from the open-source software.
