How to Customize dcm4chee REST API URL in Docker Deployment?

[Andreiver Mateus]

Hello everyone,

I have a question and would appreciate some guidance.

I’m currently running dcm4chee-arc using Docker, and I would like to know how to customize the REST API base URL.

Is there a recommended way to change or configure the REST endpoint path (for example, modifying the default /dcm4chee-arc context path or REST root) when deploying via Docker?

Any advice or documentation would be greatly appreciated.

Thank you in advance!

[Alejandro Bepmale]

Hello!

You have a great instinct coming from previous monolithic architectures, but I have some good news for you: with dcm4chee-arc-light (version 5.x) running on Docker and WildFly, you do not need to recompile the Java source code to customize your REST API base URL.
That being said, changing the context path natively inside WildFly can become quite a headache. Since version 5.x relies heavily on an internal LDAP configuration schema and Keycloak validation, modifying the core path (/dcm4chee-arc) directly inside the container will immediately break the administration web UI (UI2), login redirects, and internal service calls unless you manually update every single reference across LDAP and Keycloak.

Instead, the containerized ecosystem provides much cleaner and industry-standard ways to achieve this without touching the internal application code. Here are the recommended approaches:

Option 1: Use a Reverse Proxy (The Ideal Approach)
In modern container architectures, the golden rule is to leave the container internals untouched. The cleanest and fastest way to customize your base URL is to keep dcm4chee listening on its default internal path (/dcm4chee-arc) and put a reverse proxy (like Nginx, Traefik, or Apache) in front of it to act as a facade.

How it works: You spin up a proxy container alongside your current Docker Compose setup. You configure the proxy to listen on your desired external path (e.g., /pacs-api/) and transparently forward those requests to http://arc:8080/dcm4chee-arc/ in the backend.

The Result: Your developers or users will see a clean, professional URL in their browsers (e.g., https://yourdomain.com/pacs-api/ui2 or a dedicated subdomain like https://pacs.yourdomain.com/ui2). The internal /dcm4chee-arc/ path and standard :8080 port are completely masked from the end user.


Advantage: Zero changes to the application configuration, making it fully immune to future dcm4chee docker image updates.

Option 2: Use the Native Environment Variable
If what you actually need is to tell the archive under which external URL or load balancer it is hosted (so that the REST services construct absolute URLs properly), the official dcm4chee-arc Docker image provides a built-in environment variable for this:


DCM4CHEE_ARC_URLS: This variable defines a space-separated list of the RESTful service URLs. While it defaults to /dcm4chee-arc , you can explicitly override it in your docker-compose.yml file:
YAML
environment:
  - DCM4CHEE_ARC_URLS=https://pacs.yourdomain.com/your-custom-path

(Note: This maps how the REST API announces its endpoint links globally, but it won't alter the internal WildFly deployment root path by itself).

Summary Recommendation
If your goal is simply to have a customized, cleaner, or white-labeled endpoint URL for your integration clients or medical staff, Option 1 (Reverse Proxy) is the absolute way to go. It bypasses the need for complex internal reconfigurations and avoids any system recompilation entirely.

Hope this guides you in the right direction!