OHIF Viewer with Orthanc in Docker: Dental Setup

OHIF Viewer is a free, open-source DICOM viewer that runs in the browser; Orthanc is a free, open-source DICOM server. Together they give a dental clinic a small PACS with a zero-install viewer: CBCT and X-ray units send studies to Orthanc, and any workstation opens them in a browser tab. The short answer for Docker: a single practice should use the official orthancteam/orthanc image with its built-in OHIF plugin switched on, so one container stores the images and serves the viewer with no CORS or reverse-proxy work. Run a separate ohif/app container only when you need the current OHIF release or a custom viewer, and then put both behind one nginx proxy.

This guide follows the official OHIF deployment docs and the Orthanc Book. Sources were checked on 22 October 2026. Status: Not tested yet — we have not run this stack on a clinic network.

Two ways to run OHIF with Orthanc

Option A: Orthanc with the OHIF plugin (one container)

The Orthanc Book describes the OHIF plugin as an official plugin that “simplifies OHIF deployment and needs no reverse proxy”. It adds an OHIF button to Orthanc Explorer and is included in the orthancteam/orthanc and jodogne/orthanc-plugins images, so there is nothing to compile.

Settings that matter

1. Enable the plugin. In the orthancteam/orthanc image, plugins are switched on with environment variables; the one for OHIF is OHIF_PLUGIN_ENABLED. Orthanc Explorer 2 is on by default.
2. Choose the data source. The plugin’s default is dicom-json, which stores about 1 KB of extra metadata per instance in the Orthanc database, gives no study list inside OHIF, and only covers studies received after the plugin was installed. Set the OHIF option DataSource to dicom-web instead: no extra database space, a working study list, older studies included. That requires the DICOMweb plugin, enabled with DICOM_WEB_PLUGIN_ENABLED.
3. Mind the naming rule. Any Orthanc setting can be an environment variable: words get an underscore, nesting adds a double underscore, everything is upper case with the prefix ORTHANC__. The book’s example is DicomWeb.Root becoming ORTHANC__DICOM_WEB__ROOT. JSON files in /etc/orthanc/ work too and are easier to read.
4. Mount the storage. The image stores images at /var/lib/orthanc/db. Put that path on a persistent volume, or the studies live only inside the container.
5. Keep the secure defaults. Unlike the plain server, this image ships with RemoteAccessAllowed and AuthenticationEnabled both on. Define real users in RegisteredUsers; since Orthanc 1.13.0 the server refuses to start with remote access and authentication on but no users defined.
6. Publish the ports. Orthanc listens on 8042 for HTTP and 4242 for DICOM. Map them to the host, then add Orthanc as a DICOM destination in the CBCT software: server IP, port 4242, AE title ORTHANC.

After a restart, open Orthanc Explorer 2 (/ui/app/ on port 8042), pick a study and click the OHIF button; the viewer opens under /ohif/. The trade-off is version lag: the plugin’s NEWS file lists version 1.8 (March 2026) as updating OHIF to 3.12.0, while the stand-alone viewer is at 3.13.13 (image published 16 October 2026).

Option B: A separate OHIF container behind nginx

The official ohif/app image runs nginx and serves the static viewer. The deployment page’s basic command is docker run -d -p 3000:80 ohif/app:<tag>, after which the viewer answers at http://localhost:3000. Out of the box it points at a demo data source, so “No studies found” is normal until you configure your own archive.

Point OHIF at Orthanc

The viewer reads app-config.js. The Docker page gives two ways to supply yours: mount a local file at /usr/share/nginx/html/app-config.js (absolute path), or pass the file’s contents, not its path, in the APP_CONFIG variable; the mount wins if both are set. A dicomweb data source needs qidoRoot and wadoRoot for QIDO-RS and WADO-RS, and wadoUriRoot for WADO-URI. Orthanc’s DICOMweb plugin serves the first two under /dicom-web/ and WADO-URI under /wado by default, so the roots are those paths on your Orthanc address.

Solve CORS once, with one proxy

With the viewer on port 3000 and Orthanc on 8042, the browser treats them as different origins and blocks the viewer’s requests. The OHIF CORS page says the archive must send Access-Control-Allow-Origin with the viewer’s origin or *; the Orthanc FAQ confirms Orthanc has no built-in CORS support but that nginx can add the header. The cleaner answer in both documentation sets is a single nginx reverse proxy in front of viewer and archive, so everything shares one origin. OHIF’s “Nginx + Image Archive” recipe does exactly that with Orthanc: nginx proxies /pacs/dicom-web to Orthanc’s DICOMweb endpoints and /pacs to its web interface, the viewer sits at the root, and imaging units send to ORTHANC@127.0.0.1:4242. The files live in platform/app/.recipes/Nginx-Orthanc of the OHIF repository. One detail is easy to miss: the viewer’s public path (PUBLIC_URL) is baked in at build time, so to serve OHIF under a sub-path you rebuild the image with that argument.

Securing the stack for patient data

OHIF’s recipe carries a warning worth repeating: “Do not use this recipe to host sensitive medical data on the open web.” In the Nginx recipe every user reaches the viewer and the PACS without authentication, which the docs say may be acceptable on an internal network depending on policy. For a clinic:

• Keep the stack on the practice network; reach it from home over a VPN, not an open port.
• Leave Orthanc’s authentication on with one entry per user in RegisteredUsers; the configuration comments note these passwords are stored in plain text, so protect the file.
• Use HTTPS through a reverse proxy (nginx, Apache or IIS), which the Orthanc Book prefers over the built-in TLS.
• List the CBCT and X-ray units in DicomModalities and turn off DicomAlwaysAllowStore, as in our Orthanc setup guide.
• Do not set VERBOSE_STARTUP in production: the Docker page warns it can print passwords to the logs.

For single sign-on, OHIF’s “User Account Control” recipe chains nginx, OAuth2 Proxy and Keycloak in front of the viewer and PACS; OHIF makes “no claims or guarantees regarding the security of this approach”, so it is a starting point for a team that already runs identity systems.

Backup and updates

Containers are disposable; the data is not. Back up the Orthanc volume (DICOM files and index), the Orthanc configuration and your app-config.js or nginx files together, following the stop-copy-restart rule in our DICOM backup plan. Pin image tags (for example orthancteam/orthanc:26.9.1 and ohif/app:v3.13.13) rather than latest, so an automatic pull cannot change the viewer on a Monday morning.

Which option should a clinic choose

A single practice with one always-on server should take Option A: one container, authentication on by default, OHIF one click away, no CORS to debug. Choose Option B when the IT team wants the current OHIF release, a custom mode or single sign-on across sites, and can maintain nginx. In both cases the archive is Orthanc and the viewer is OHIF Viewer; dentists who need curved MPR along the arch can add a desktop client such as Weasis, which queries Orthanc over DICOM. If the group outgrows Orthanc, OHIF connects the same way to dcm4chee. More tools are in our dental imaging software hub.

Limitations

• Not tested yet: the steps come from the OHIF and Orthanc documentation; we have not run the containers ourselves.
• OHIF’s FAQ states the viewer is not FDA-cleared or CE-marked and not HIPAA-compliant on its own; the Orthanc project makes no medical-device claim either.
• Neither tool has a dental mode: no curved MPR along the arch, no implant planning, no tooth segmentation.
• The plugin route lags the stand-alone OHIF release by one minor version at the time of writing.
• The authentication recipes need web and identity-management skills; nothing here is legal advice.

FAQ

Does OHIF work with Orthanc?

Yes. Orthanc has an official OHIF plugin that serves the viewer under /ohif/, and a stand-alone OHIF container can connect to Orthanc’s DICOMweb plugin at /dicom-web/.

Is there an OHIF Docker image?

Yes, ohif/app on Docker Hub, with version tags such as v3.13.13. It runs nginx and serves the viewer on port 80 inside the container.

Why does OHIF show “No studies found” after install?

The default build points at a demo data source. Supply your own app-config.js with the Orthanc DICOMweb roots. With the Orthanc plugin’s default DICOM JSON source there is no study list at all; switch it to dicom-web.

How do I fix CORS errors between OHIF and Orthanc?

Add Access-Control-Allow-Origin for the viewer’s origin in the nginx in front of Orthanc, or avoid the problem by serving viewer and archive from one reverse proxy, as OHIF’s Nginx + Orthanc recipe does.

Can OHIF run with dcm4chee in Docker?

Yes. dcm4chee exposes DICOMweb at /dcm4chee-arc/aets/<AET>/rs, and OHIF’s documentation uses that layout as its example data source.

Is OHIF with Orthanc free?

Both are free and open source: OHIF under the MIT licence, the Orthanc server under GPLv3 or later, with some plugins under AGPLv3 or later.

Editorial team. Sources checked 22 October 2026.

Last updated: 22 October 2026 · DentIIT editorial team. Licence, version and platform details are checked against each developer's official documentation; none of the tools listed here should be treated as a certified medical device unless its vendor says so.