How to self-host a DICOM server

Before you start: what a DICOM server is, and is not

A DICOM server is software that speaks the DICOM network protocol so that imaging equipment can send it studies and clients can ask for them back. In DICOM terms it acts as a Service Class Provider: it listens on a port, accepts connections from modalities and workstations, and provides the standard services those devices expect, chiefly receiving images (C-STORE) and answering queries and retrievals (C-FIND, C-MOVE). Self-hosting it means running that software on hardware you control rather than on a vendor's cloud, so the studies stay on your side of the wall.

One thing to be honest about up front: a bare DICOM server is not a full PACS. It receives, stores and serves images, but it does not by itself give clinicians a viewer, a worklist or the workflow to read and report. Every PACS contains a DICOM server; not every DICOM server is a PACS. If you only need a networked node to receive and route DICOM, a bare server is the right tool. If you need people to actually read the images, plan for the viewer from the start. The DICOM server explainer covers that distinction in full; this page is the how-to.

Step 1: Plan storage and backup first

The mistake that hurts later is treating storage as an afterthought. Plan it before you install anything. Imaging archives grow with volume, so size the primary storage for where you expect to be in a few years, not just today, and lay it out so it can extend without a rebuild. A mirror across two drives is a sensible baseline so a single disk failure does not take the archive with it.

• Primary storage. Enough capacity for your growing archive, on a redundant layout such as a two-drive mirror.
• A separate backup target. A second copy that does not live on the same drive, or ideally the same machine, as the primary. A backup on the same disk is not a backup.
• A restore drill. Decide now that you will restore from that backup on a schedule to prove it works. A backup you have never restored is a hope.

A single mini PC can hold millions of images without drama; the part that matters is not raw size but the layout and a backup you have actually restored from.

Step 2: Install Docker on a Linux box

Most modern DICOM servers ship as containers, which makes Docker on Linux the simplest way to run one. You do not need much hardware. For a single site a quiet mini PC with a modern CPU and enough RAM is enough to receive from the modalities and serve clients on the local network.

1. Install a current long-term-support Linux distribution on the machine, fully patched.
2. Install Docker and the Compose plugin, and confirm the service starts on boot so the server comes back after a power cut.
3. Create a directory for the archive on your planned storage volume, and a separate directory or mount for backups.
4. Decide the DICOM port you will expose, commonly 104 or a high port like 11112, and note it for the firewall step.

Running the server and its database as containers keeps the whole thing reproducible: the configuration lives in a Compose file you can version, and a rebuild is one command rather than a fresh manual setup.

Step 3: Choose the software

There are two honest routes, and the right one depends on how much engineering time you want to spend.

• Open-source, assembled yourself. Projects such as Orthanc and dcm4che give you a capable DICOM server that implements the standard network services and runs well in a container. They are a genuine option if you are ready to build and maintain the viewer, the worklist and the workflow on top. The Orthanc alternative comparison walks through exactly where a bare server ends and a full system begins.
• An assembled self-hosted system. You still run it on your own hardware and keep the data, but the archive, viewer and worklist come fitted together and supported, so it works the week you install it. You trade some do-it-yourself freedom for a system that is complete on day one.

Whichever you pick, read its DICOM conformance statement and confirm the services you need, C-STORE, query/retrieve, and modality worklist if you want it, are actually supported and match what your equipment expects. The conformance statement matters more than the marketing.

Step 4: Configure the AE title, IP and port

Every DICOM node is identified by an Application Entity title, its AE title, together with an IP address and a port. Getting these three right, and consistent on both sides, is most of what makes two nodes talk.

1. Give the server a clear AE title, and set the port it listens on to the one you chose in step 2.
2. Give the machine a fixed IP address on the local network so the modalities always find it at the same place.
3. On each modality or client that will send to the server, add the server as a destination using that AE title, IP and port.
4. Record the AE title, IP and port of every device that will connect, since many servers only accept associations from nodes they know.

Step 5: Verify the connection with C-ECHO

Before sending a single image, run a C-ECHO, the DICOM verification handshake, from a modality or a test tool to the server. It confirms the two nodes can open an association and talk, and nothing else. This isolates the network layer: if C-ECHO succeeds you know the AE title, IP and port are right and no firewall is in the way, so any later problem is about the study or the storage rather than reachability. If C-ECHO fails, fix the AE title, the port or the firewall now, before you move on.

Step 6: Receive a test C-STORE from a modality

With verification passing, send one real study. C-STORE is how a modality pushes images: it opens an association and transmits each object to the server, which receives and stores it as a Store SCP.

1. From a modality, or a test sender, push a single known study to the server's AE title, IP and port.
2. Confirm the study lands in the archive and is indexed with the right patient and study details.
3. If nothing arrives, check the AE title match, the port, and any firewall between the two, the same suspects as before.

Once a study receives cleanly, the core job of the server, taking images off your equipment and holding them, is working.

Step 7: Set up the viewer

This is the step people forget, and it is where a bare server shows its limits. Receiving and storing a study does not let anyone read it. If your chosen software includes a viewer, confirm that clinicians can open a received study and that it renders correctly. If it does not, decide now how the images get read: a separate viewer that queries the server, or a full system that has the viewer built in. The worst outcome is an archive full of studies and no practical way to look at them, with the images and the people who need them in two disconnected places.

Step 8: Harden access, encryption and the audit log

A server holding imaging data has to be secured, not just stood up. None of this is exotic, but all of it is now your responsibility rather than a line in a vendor's attestation.

• Accounts and roles. Real user accounts with roles, no shared logins, so access can be granted and revoked per person.
• Encryption. Encrypt the disks that hold the archive and the backups, so a stolen drive is not a breach.
• Network segmentation. Keep the server on a controlled segment, expose only the DICOM port to the devices that need it, and do not put it on the open internet.
• Audit log. Keep a record of who accessed which study and when. In a HIPAA review this is the answer to the question that gets asked most.
• Updates. Apply operating system and container updates on a schedule, not never and not in a panic.

Step 9: Test a restore

The last step closes the loop on step 1. Actually restore from your backup, into a scratch location, and confirm the studies come back intact and readable. Do this before go-live and then on a schedule. Because the archive sits on your own storage in standard DICOM, a restore is a data copy you control, not a request you file with a vendor, and proving it works is the difference between owning your archive and merely hoping you do. Only once a restore has succeeded is the server genuinely in production.

Where MiniPACS fits

If you work through the steps above and conclude you want the whole system rather than a bare server to assemble, that is the case MiniPACS is built for. It is a full self-hosted PACS, the DICOM archive, a browser-based viewer and a worklist, running together on one machine. It acts as a DICOM server and receives studies from your modalities, and on top of that it gives clinicians the viewer and workflow a bare server leaves out. Studies open in about two seconds with no plugin and no dedicated workstation, and the imaging data never leaves the building.

It installs with Docker on Linux, runs comfortably on a mini PC for a single site, holds millions of images, and is priced as a flat 300 dollars per location per month rather than per study. In other words, it is the assembled route from step 3: you still own the hardware and the data, but the viewer and worklist come fitted and supported. For the deployment choice in general see self-hosted PACS; for what the whole system does day to day see what is PACS; and for pricing and a live demo you can click through, see the landing page.

FAQ