I might’ve found a clue but I don't have a solution yet. Indicium is listening on 127.0.0.11 inside the container and according to online sources this should probably be changed to 0.0.0.0 (all addresses).

This is what I saw inside the Indicium container:

Shouldn't this be 0.0.0.0:8080? I don't have a lot of knowledge on this topic and I'm basically just guessing now.

Hi ​@Roland, for what reason are you running Indicium and Universal on two seperate subdomains? When the current issue is solved you might stumble onto another, more difficult to solve issue; CORS.

Indicium does not trust traffic coming from other domains and will discard it by default, this includes subdomains.

As for the issue mentioned in this post, I am not able to replicate it with the supplied configuration. 
Could you check the logging of the Indicium container? The easiest way to do this is with docker compose logs gservice_name], so there is no need to look up the container name. Maybe the Indicium service is crashing.

If Indicium is running, without any errors, can you give me the output of netstat -tunlp? It provides a bit more information about the processes related to it.

In my case, it shows:
 

Sidenote about the IP 127.0.0.11, it is part of the loopback interface. Anything on the IP block 127.0.0.0/8 refers to localhost .

Hi ​@Leon Kroon. Running docker compose logs revealed that Indicium wasn't able to reach the SQL Server host. It turned out that resolving hostname from inside the container doesn't work. I've replaced this with hostname.domain.local everywhere it's used (Docker compose, SF, relevant IAMs) and now Indicium works as expected. It’s probably more elegant to append domain.local automatically when trying to resolve a hostname as is done on the host. However I didn't find an easy way to achieve that.

As to using different subdomains: having a specific API subdomain makes it stand out better so it seemed like a good idea to separate it from the frontend like that. But to prevent the CORS issue you mentioned I switched back to the default method of sharing the same (sub)domain between Indicium and Universal. Universal now loads the end-product properly.

It all seems to work now.  The final step is enabling HTTPS and generating and installing an SSL certificate which then also needs to be accepted by all devices inside the domain.

I have one more small follow-up question. Loading the end-product via SF works but it takes a while (30 seconds or more) for the first list to load after logging in. Subsequent lists seem to load a lot faster. Is there anything I could try to improve this behavior? This also happens on Indicium for Windows so perhaps it’s an SF or IAM issue?

Hi ​@Roland, maybe the DNS options in Docker might help resolving DNS names, maybe the --dns-search flag https://docs.docker.com/engine/network/#dns-services . 

For enabling SSL, there already was a topic, it might help you further;

I am unable to assist with loading the end-product, could you make a new question on the community for this?

​@Leon Kroon I tried the dns_search option in docker-compose.yaml but after destroying/rebuilding the containers with docker compose up -d resolving an existing hostname inside the container still returned a bad address. I'll just keep using fully stated domain names for now. Thank you for the helpful advice and I'll look into the tips for any remaining steps and issues.

These are some endnotes on how I got to a working setup using a traefik dynamic configuration and a self-signed SSL certificate.

Starting inside my docker compose working directory I created a new ./cert directory. In there I created a new certificate of 1 year validity via the following command:

openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout key2025.pem -out cert2025.pem

I stuck to 1 year validity because modern browsers no longer accept certificates that are valid longer than that.

I then added both PEM files to a new tls.yaml file, also in ./cert and with the following content:

tls:
  stores:
    default:
      defaultCertificate:
        certFile: ./cert/cert2025.pem
        keyFile: ./cert/key2025.pem
  certificates:
    - certFile: ./cert/cert2025.pem
      keyFile: ./cert/key2025.pem
      stores:
        - default

Then I included tls.yaml for only the traefik container in docker-compose.yaml as a dynamic configuration via the option: "--providers.file.filename=/cert/tls.yaml"

To give the traefik container access to ./cert/tls.yaml I added the following volume mapping:

    volumes:
      - ./cert:/cert

Because this is a dynamic configuration it's possible to hotplug a new certificate without taking the containers down. Simply changing the filenames inside tls.yaml and saving these changes makes traefik switch to the new certificate files on the fly.

The Indicium and Universal containers don't need to know about the actual certificates because they're served by traefik to the browser and other client software. The containers only need to have TLS enabled via traefik labels:

Universal: "traefik.http.routers.frontend.tls=true"
Indicium: "traefik.http.routers.backend.tls=true"

Finally just give docker compose up -d one more spin and all containers come up again with a working SSL setup.

Hi ​@Roland, thank you for the followup and clear instructions. When I have time I will include your instructions for the Compose file in our documentation .