microsoft/dicom-server: the DICOMweb server is gone from main and the code lives on a branch

The server that this repository used to contain is no longer on main

The repository description still calls the project an OSS Implementation of DICOMweb standard, but the README says something quite different. All code except for the client has been removed, and only the client code remains in the main branch. Everything else, meaning the server side of a DICOMweb implementation, was moved to a branch called archived, where it is preserved for reference. That is a deliberate change of scope rather than a slow drift. The main branch still holds a full C# project, with a solution file named Microsoft.Health.Dicom.sln, a src/ directory, shared build configuration in Directory.Build.props and Directory.Packages.props, a global.json pinning the SDK, and a nuget.config. So a visitor who expected to find a running DICOM service here will find a client and a build system, and the difference between the two branches is the single most important fact about the repository today.

The team has said it plans to archive the project

An important notice sits at the top of the README. After more than 3 years, the team is planning to archive the DICOM server project so it can focus on delivering customer value to the managed service offering on Azure, and it points to a discussion post for the reasoning. The repository itself is not marked as archived, and the last push was on 2026-10-20, so code is still landing on main. What has happened is a shift of intent rather than a shutdown, and the two facts sit side by side. For anyone evaluating this project, the direction of travel matters more than the current activity: the maintainers have told you where they intend to take it, and that is not toward a self hosted open source server.

Getting at the server code means cloning and switching branches

The removed components are not deleted from Git history, they live on the archived branch. The README gives two steps for reaching them: clone the repository with git clone https://github.com/microsoft/dicom-server.git, then switch to the branch that holds the removed code with git checkout archived. Those are the practical instructions for anyone who came for the server and found only a client. Two things follow from that arrangement. The archived branch is not a released artifact, so nothing on it is packaged, versioned or supported in the way the old releases were, and it is a snapshot rather than a moving target only if you leave it alone. The other is that the main branch and the archived branch have diverged, so a component that read well in a blog post about the DICOM server may no longer have its dependencies in place on main, where the client code has been reorganised around the remaining surface.

The release history stopped in early 2024 while pushes continued

The listed releases are 10.0.838 from 2024-03-01, 10.0.836 from 2024-02-23 and 10.0.828 from 2024-02-16, a run of three builds inside a fortnight. Two and a half years have passed since the newest of those tags, while the last push to the repository was on 2026-10-20. That gap is the clearest signal in the data about what the project is now: the tagged releases stopped, the branch kept receiving commits, and the code that remained is the client. Anyone looking for a versioned server build to pin in a deployment will find that the most recent published version predates the current shape of main by a wide margin, and pulling a package from 2024 does not give you the repository as it stands now.

The build configuration points to a client library maintained in place

The top level of the repository shows a working .NET project rather than a stub. There is a src/ directory, the solution file, Directory.Build.props for shared build settings and Directory.Packages.props for central package version management, plus a global.json that pins the SDK version for the build. A nuget.config sits alongside them for package source configuration, and renovate.json is present, which is the usual sign that dependency updates are handled by automated pull requests. There is also a GeoPol.xml at the root, a .config/ directory, an .editorconfig, a .globalconfig for analyser rules, SECURITY.md and NOTICE.md. In other words, the housekeeping around a client library is intact and current, while the server half of the solution has been carved out. For a developer who only needs a DICOM client in .NET, this layout is straightforward and unremarkable. For one who needs the server, none of this configuration brings it back.

Why the DICOMweb server may still be worth reading

Even with the server removed from main, the repository is not without value. It remains a Microsoft reference implementation of the DICOMweb standard, and the parts that were kept were kept on purpose. For a team writing a DICOM client against a PACS or an archive, the client code here shows how the standard was mapped onto C# types by an implementation that had to interoperate with the server side it used to contain. The topic tags still list dicom, dicomweb, fhir, healthcare and medical-imaging, alongside azure, which reflects how the work sat next to the Azure offering. The README also lists Swiftle-style contribution routes that do not apply here but do describe how the project was run: a Contributor License Agreement, a CLA bot that decorates pull requests, and the Microsoft Open Source Code of Conduct. The licence is MIT, so the retained client code can be reused under its terms.

The managed Azure service is where the maintainers are pointing

The notice is explicit about the destination: focus on delivering customer value to the managed service offering on Azure, with a link to the Azure healthcare APIs documentation for DICOM. That is the alternative path for anyone who needs a working DICOMweb service, and the difference in approach is not a small one. A self hosted server means you run the processes, own the storage, handle the identity and the upgrades yourself, and accept the version pinning. A managed service means the deployment, scaling and lifecycle sit with the provider, and the local configuration surface shrinks to the endpoint and the credentials. The repository cannot tell you how the managed service compares in features, since that documentation lives on the Azure site rather than in the README, and the project makes no claim about parity. For a team choosing a path, the direction the maintainers have chosen is the strongest available signal.

Contributions now go through the CLA bot and the code of conduct

The contribution section still applies to whatever remains. Most contributions require agreeing to a Contributor License Agreement that declares the right to grant the rights to use the contribution, and a CLA bot decides automatically whether a pull request needs one and decorates it accordingly. The README notes that this has to be done only once across all repositories using the Microsoft CLA, which is the usual convenience for contributors who work across several of them. The project has adopted the Microsoft Open Source Code of Conduct, with a link to the FAQ and a contact address for questions. Given the archive plan, the sensible reading is that contributions will be limited to the client and to documentation, but the README does not say so explicitly, and it does not describe what happens to accepted pull requests once the project is archived.

Editorial conclusion

Treat microsoft/dicom-server as a source of reference and as a client library rather than as a server you can adopt, because the main branch holds only client code, the server components were moved to the archived branch and the team has said it plans to archive the project. It is worth reading if you need to understand how a DICOMweb server was structured in C# or you want the client, and it is the wrong starting point for a new deployment, where the team's own direction is toward the managed service on Azure. Before you build on anything here, check out the archived branch and read the discussion post referenced in the README, and confirm that the release you pick still matches the DICOMweb endpoints your imaging clients expect.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/dicom-server on GitHub
4. README
5. Releases