What a self-hosted PACS is
A self-hosted PACS is a picture archiving and communication system that runs on hardware you control rather than in a vendor's cloud. It does everything any PACS does. It receives studies from your modalities over the DICOM network protocol, keeps them in an archive, indexes patients and studies in a database, and gives clinicians a viewer and a worklist to read them. What changes with self-hosting is only where the system runs and who holds the data: the images sit on a machine on your side of the wall, the backups are yours, and there is no cloud bill that grows with every study.
For a plain-language account of the system as a whole, see what is PACS. For the networking layer underneath it, the part that actually speaks DICOM to your scanners, see DICOM server. This page is about the deployment choice: running that whole system yourself.
Why independent centers self-host
Three reasons come up again and again, and they map cleanly onto the pressures a small imaging business actually feels.
Control of the data. When the archive and its audit log live on hardware you own, the hardest questions in a HIPAA review answer themselves. There is no third party holding the imaging history, no shared-tenancy caveat, no request to file to get your own studies back. You decide the access controls, the encryption and the retention, and you can show exactly where the data sits.
Predictable cost. Cloud PACS commonly bills by study or by stored volume, which means the cost of yesterday's imaging keeps arriving for years. A self-hosted system replaces that with a flat, known figure: you pay for the software and you own the storage. For a center that reads a steady volume, the difference over a few years is large and, more importantly, it is easy to budget.
Speed on the floor. A study that opens from a server on the local network does not round-trip to a distant data center. On a modern self-hosted setup scans open in about two seconds, with no plugin to install and no dedicated workstation to sit at. That is the difference between a viewer clinicians reach for and one they avoid.
What you take on
Self-hosting is a trade, not a free win, and the honest version names the cost. When you run the system you own the parts a cloud vendor would otherwise run for you: the hardware, the backups and the security hardening.
- The hardware. One reliable machine, kept powered and cooled, with a plan for when a drive fails. This is smaller than it sounds, but it is yours to look after.
- The backups. A second copy of the archive, on a separate target, that you restore from occasionally to prove it works. A backup you have never tested is a hope, not a backup.
- The hardening. Accounts and roles, encrypted disks, a segmented network, and updates applied on a schedule. None of it is exotic; all of it is now your responsibility rather than a line in a vendor's attestation.
The right way to weigh this is not self-hosted against cloud in the abstract, but against your own appetite for owning those three things. A center that already runs its own network and wants control will find the trade easy. One that wants no infrastructure at all should read the cloud comparison below with open eyes.
The hardware is smaller than you think
The most common reason centers assume they cannot self-host is a picture of a server room they do not have. For a single independent site that picture is wrong. A small, quiet mini PC with a modern CPU, enough memory and a pair of drives in a mirror is usually enough to receive from the modalities and serve the viewer to everyone on site. A mini PC is enough. What grows with your imaging volume is storage, so that is the part you size deliberately, together with a backup target that lives apart from the primary drive.
The archive itself can hold millions of images without drama; the engineering that matters is not raw size but a storage layout and a backup you have actually restored from. Plan those two things and the rest of the hardware question gets small.
Self-hosted versus cloud PACS
Both models read the same DICOM and show the same images; they differ in who holds the archive and how you pay. Cloud PACS hands the infrastructure to a vendor and bills for it, frequently per study or per gigabyte, and your imaging history lives on their systems. Self-hosted PACS keeps the data and the cost on your side, a flat fee and full ownership, in exchange for owning the hardware and backups.
There is no universally correct answer, only a correct answer for a given center. For the full side-by-side, including how the two models diverge over a multi-year horizon, see cloud PACS versus on-site and the cloud PACS cost calculator.
Open-source or commercial self-hosted
Choosing to self-host is not the same as choosing to assemble the system yourself. Open-source projects such as Orthanc and dcm4che give you an excellent DICOM archive and are a genuine option if you have the engineering time to build the viewer, the worklist and the workflow on top. The honest question is where a bare server ends and a working, day-to-day system begins, and how much of that gap you want to close by hand. The Orthanc alternative comparison walks that line in detail.
A commercial self-hosted PACS is the other route: you still run it on your own hardware and keep the data, but the viewer, the worklist and the setup come assembled and supported. You trade a piece of the do-it-yourself freedom for a system that is working the week you install it.
Where MiniPACS fits
MiniPACS is a self-hosted PACS built for exactly this case: an independent imaging center that wants to own its archive without running a data center. It is the whole system, not a bare server. The DICOM archive, a browser-based viewer and a worklist run together on one machine in the clinic. 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, and is priced as a flat fee per location per month rather than per study.
If you want to see it rather than read about it, the landing page has pricing and a live demo you can click through. For how a full PACS behaves day to day, see what is PACS; for the option set across the market, see comparing PACS vendors.
What to check before you self-host
- The whole system, not just the archive. Confirm the viewer and worklist come with it, or plan who builds them, so the images and the people who read them do not end up in two disconnected places.
- Backups you test. Decide the second copy, the target and the restore drill before go-live, not after the first drive failure.
- Access from where clinicians work. Whether studies open in a browser from anywhere on the network or need a specific workstation with software installed.
- Exit terms. Even for a system you host, ask how a full export works and in what format, so ownership is real and not just implied.
- Support for the setup. Who helps you stand it up and who answers when something breaks, because self-hosted does not have to mean self-supported.
FAQ
What is a self-hosted PACS?
A self-hosted PACS is a picture archiving and communication system that runs on hardware you control, in your own building or your own rented server, rather than on a vendor's cloud. It does the same job as any PACS: it receives studies from your modalities over DICOM, stores them in an archive, indexes patients and studies in a database, and gives clinicians a viewer and a worklist to read them. The difference is only where it runs and who holds the data. With a self-hosted PACS the images never leave premises you control, backups are yours, and there is no per-study cloud fee.
Why do imaging centers self-host their PACS?
The three reasons that come up most are control, cost and speed. Control means the imaging archive and its audit log stay on hardware you own, which makes the data-residency and access questions in a HIPAA review simple to answer. Cost means a flat, predictable bill instead of a charge that grows with every study or gigabyte. Speed means studies open from a server on the local network rather than round-tripping to a distant data center. The trade is that you take on the hardware, the backups and the security hardening yourself.
What hardware does a self-hosted PACS need?
Less than most people expect. For a single independent center a small, quiet mini PC with a modern CPU, enough RAM and a couple of drives in a mirror is usually enough to receive from the modalities and serve the viewer to everyone on site. The archive grows with your imaging volume, so storage is the part you plan for, along with a backup target that is separate from the primary drive. You do not need a rack or a server room; you need one reliable machine, a UPS, and a backup you actually test.
Is a self-hosted PACS HIPAA compliant?
The software does not make you compliant by itself; how you run it does. Self-hosting helps because the imaging data stays on infrastructure you control, with your own access controls, encryption and audit trail, and there is no third party holding the archive. You are still responsible for the surrounding controls: user accounts and roles, encrypted disks and backups, network segmentation, and a record of who accessed what. A self-hosted system gives you the ability to satisfy those requirements directly instead of relying on a vendor's attestation.
Self-hosted PACS or cloud PACS: which is right?
It comes down to who you want holding the archive and how you prefer to pay. Cloud PACS hands the infrastructure to a vendor and bills for it, often per study or per gigabyte, and your imaging history lives on their systems. Self-hosted PACS keeps the data and the cost on your side: a flat fee and full ownership, in exchange for owning the hardware and backups. Small and independent centers that want predictable cost and data control tend toward self-hosting; groups that want zero infrastructure and will pay for it tend toward cloud.
Can I move off a self-hosted PACS later?
That is one of the quieter advantages. Because the archive sits on your own storage in standard DICOM, your exit is a data copy, not a negotiation. With a cloud PACS the practical question is always how you get the full archive back and in what format if the relationship ends. With a self-hosted system you already hold it. When you evaluate any PACS, ask exactly how a full export works before you commit, not after.