Configuration for traefik as reverse proxy

[s7a7ic]

I'm currently testing xyops in my homelab and it looks very promising. However, I’ve encountered some issues setting it up with docker and traefik.

This is an docker-compose.yml example for a single xyops container that works with traefik:

networks:
  web: # change this to your docker network used by traefik
    external: true

services:
  xyops01:
    image: ghcr.io/pixlcore/xyops:v1.0.85
    init: true
    restart: unless-stopped
    container_name: xyops-conductor-01
    hostname: xyops.server.example.com
    environment:
      - TZ=America/Los_Angeles
      - XYOPS_base_app_url=https://xyops.server.example.com
      - XYOPS_satellite__config__secure=true
      - XYOPS_satellite__config__port=443 # double quoting here leads to "\"443\"" in config.json on xysat
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./xyops/data:/opt/xyops/data
      - ./xyops/conf:/opt/xyops/conf
      - ./xyops/logs:/opt/xyops/logs
    networks:
      - web # change this to your docker network used by traefik
    labels:
      - traefik.enable=true
      - traefik.http.routers.xyops.rule=Host(`xyops.server.example.com`)
      - traefik.http.services.xyops.loadbalancer.server.port=5522

NOTE:
Remember to change xyops.server.example.com and the network to your environment.
Also I have configured traefik to redirect all requests on port 80 to 443 (HTTPS only).

The important settings are:

• hostname - Otherwise the "conductor host id" (aka. satellite.config.hosts) and url shown when adding a server is the randomly generated container id.
• XYOPS_satellite__config__secure=true and XYOPS_satellite__config__port=443 (mentioned in the tailscale documentation).

Other settings

• Setting XYOPS_masters leads to an error as the port 5522 is not used externaly:
  • Error > PeerSocket | comm | Socket Error: connect ECONNREFUSED 192.168.2.15:5522
• Also I don't use XYOPS_xysat_local=true as the satellite is set up directly on the host afterwards.

Issues and Questions

I've faced the following issues when setting up xyops the quick-start way but with the exception of using traefik and not exposing the ports:

• Connecting to the web UI trough traefik worked fine.
• The url shown when adding a server was http://xyops.server.example.com:5522 but I fixed this by adding config.satellite.port=443 and config.satellite.secure=true in the override.json file.
• However, as soon as the xyops container is restarted the web UI is having 502 and 404 errors in the browser.

Questions
Is the frontend considered a "satellite" or why changing the satellite.config has implications on how the frontend behaves?
Why is setting XYOPS_satellite__config__* as environment variables vs. setting them in override.json circumventing this behaviour?
Is there a "correct" way of using xyops with traefik that I'm not aware of?

I understand the reasoning behind some behaviour, as explained in this issue.
But in my opinion, the implementation for the different possible configuration methods of how the xysat connects to the server is somewhat complicated.

Anyway, thank you for this great software.

[jhuckaby]

Note

I have very little experience with Traefik, so I used ChatGPT to help me write this reply.

Thank you for the detailed write-up and the working Compose example. I can see why this is confusing, because the same hostname and port can appear in several places, but they describe different network paths.

The short version is:

• The browser UI is not a satellite.
• satellite.config.port and satellite.config.secure do not configure the xyOps web UI or its web server.
• Environment variables and conf/overrides.json ultimately update the same xyOps configuration tree.
• The 502 and 404 errors after restart were almost certainly caused by a separate startup, conductor identity, primary election, or Traefik routing issue.

The different network paths

It helps to separate the system into these paths:

Setting	Purpose
base_app_url	The public, human-facing URL used in emails, alerts, tickets, web hooks, and similar links
WebServer.port	The port on which the xyOps conductor process actually listens
masters / masters.json	The hostnames of conductor servers in the conductor cluster
satellite.config	Fleet-wide xySat defaults, distributed to all worker servers
xySat host / hosts	Where a particular xySat connects to the conductor

In your setup, the browser path should be:

Browser
  -> https://xyops.server.example.com:443
  -> Traefik
  -> http://xyops01:5522
  -> xyOps conductor

The fact that the browser uses HTTPS on port 443 does not mean the xyOps container itself must listen on HTTPS or port 443. Traefik terminates TLS and forwards ordinary HTTP traffic to port 5522 inside the Docker network.

The WebSocket used by the web UI follows the same route. Traefik supports WebSocket upgrades automatically, so xyOps should not need special WebSocket header middleware.

An xySat connecting through Traefik would use:

xySat
  -> wss://xyops.server.example.com:443
  -> Traefik
  -> ws://xyops01:5522
  -> xyOps conductor

That is where these settings matter:

XYOPS_satellite__config__host: xyops.server.example.com
XYOPS_satellite__config__secure: "true"
XYOPS_satellite__config__port: "443"

They tell xySat how to reach the conductor. They do not change how the conductor listens, and they do not change how Traefik reaches the container.

They also affect the installation URL shown in the Add Server dialog. That URL is deliberately constructed from the satellite connection configuration, because the address used by the browser is not necessarily reachable from worker servers.

This is described in the Satellite Configuration and Overriding the Connect URL sections.

Why the restart problem was probably unrelated

Changing:

satellite.config.port
satellite.config.secure

does not alter:

WebServer.port
WebServer.https_port

Therefore, those satellite properties cannot directly make the xyOps HTTP listener disappear from port 5522.

A Traefik 502 Bad Gateway normally means that the router matched, but Traefik could not successfully contact its selected upstream container and port. A 404 from Traefik usually means that no router matched the request. These indicate different conditions, and neither one is caused by the xySat port setting.

A few possibilities after the restart are:

1. xyOps had not finished starting yet.
2. The conductor had not become primary yet.
3. The persisted masters.json contained an old or unexpected hostname.
4. The container hostname did not exactly match the hostname in the conductor list.
5. Traefik briefly had stale Docker provider state while the container was recreated.
6. Traefik selected the wrong Docker network.
7. overrides.json was malformed or accidentally replaced instead of edited.
8. The error responses came from different layers, for example a Traefik 502 followed by an application or cached-frontend 404.

The /health endpoint is particularly useful here. It returns success only when the conductor is primary.

After a restart, try:

docker exec xyops-conductor-01 \
	curl -sS -i http://127.0.0.1:5522/health

And from outside Docker:

curl -k -i https://xyops.server.example.com/health

The results narrow the problem down considerably:

• Internal /health is 200, public URL is 502: Traefik cannot reach the correct container/network/port.
• Internal /health is 200, public URL is 404: inspect the Traefik router, entry point, TLS, and Host() rule.
• Internal /health is 503: xyOps is running but is not currently primary.
• Internal request cannot connect: xyOps has not opened port 5522, exited, or is still starting.

Environment variables versus overrides.json

These are not separate implementations of satellite behavior. They are two configuration input mechanisms that feed the same in-memory configuration tree.

For example, these are equivalent when only one of them is used:

XYOPS_satellite__config__secure: "true"
XYOPS_satellite__config__port: "443"

{
	"satellite.config.secure": true,
	"satellite.config.port": 443
}

There is one precedence detail: xyOps applies environment overrides first, and then applies conf/overrides.json. Therefore, if the same property is present in both places, overrides.json wins.

I recommend defining a property in only one place. For Docker Compose installations, environment variables are usually the clearest choice for deployment-specific values. The overrides file is also valid, but it is commonly managed by the xyOps configuration UI and contains important properies such as secret_key.

Also, the filename is overrides.json, plural. The nested property path is satellite.config.port, not config.satellite.port.

If manually editing this file, make sure to:

• Preserve all existing properties, especially secret_key.
• Keep it valid JSON.
• Use flat dot-path keys.
• Use JSON numbers and booleans, not quoted values.
• Never publish the file without redacting secrets.

The difference you observed between the two configuration methods therefore suggests either a difference in the actual values, a malformed or incorrectly named file, a stale override taking precedence, or a separate restart problem. There is no intended UI behavior that is enabled by one method but disabled by the other.

Your note about quotes in Compose is also worth clarifying. With list-style environment syntax, this:

- XYOPS_satellite__config__port="443"

can include the quote characters as part of the value. Mapping-style syntax avoids that ambiguity:

environment:
  XYOPS_satellite__config__port: "443"

Compose passes the value as 443, and xyOps converts the numeric string to a number.

The XYOPS_masters error

This message is significant:

PeerSocket | comm | Socket Error: connect ECONNREFUSED 192.168.2.15:5522

PeerSocket is conductor-to-conductor communication. It is not xySat traffic, and satellite.config.port=443 does not apply to it.

A conductor expects to contact other conductors directly on the conductor web server port, which is 5522 in this setup. It does not use the public xySat proxy address for conductor peer communication.

For a single-conductor installation, if these values all match exactly:

hostname: xyops.server.example.com

environment:
  XYOPS_hostname: xyops.server.example.com
  XYOPS_masters: xyops.server.example.com

then xyOps should recognize that the only conductor in the list is itself and become primary immediately. It should not open a PeerSocket connection to itself.

If it tries to connect to xyops.server.example.com:5522, that strongly suggests its actual conductor host ID did not match the entry in masters. It consequently treated that hostname as another conductor. Since the public DNS address led to the Docker host and port 5522 was not published, the connection was refused.

I would inspect:

docker exec xyops-conductor-01 hostname
docker inspect -f '{{.Config.Hostname}}' xyops-conductor-01
docker exec xyops-conductor-01 getent hosts xyops.server.example.com

Also inspect:

./xyops/conf/masters.json

It should contain one entry, exactly matching the conductor host ID:

{
	"masters": [
		"xyops.server.example.com"
	]
}

If this installation was initially started before the stable hostname was added, the persisted configuration may contain an old container ID. Supplying both XYOPS_hostname and XYOPS_masters explicitly removes that ambiguity.

A more explicit topology is to use separate internal and public names:

hostname: xyops01.internal.example.com

environment:
  XYOPS_hostname: xyops01.internal.example.com
  XYOPS_masters: xyops01.internal.example.com
  XYOPS_base_app_url: https://xyops.server.example.com
  XYOPS_satellite__config__host: xyops.server.example.com
  XYOPS_satellite__config__secure: "true"
  XYOPS_satellite__config__port: "443"

This makes the distinction very clear:

• xyops01.internal.example.com is the conductor identity.
• xyops.server.example.com is the public UI and xySat proxy endpoint.

For a single conductor, using the public name as both can also work, provided the conductor identity matches it exactly.

Suggested Traefik configuration

I would make the Traefik relationship explicit and add a primary-aware health check:

services:
  xyops01:
    image: ghcr.io/pixlcore/xyops:v1.0.85
    init: true
    restart: unless-stopped
    container_name: xyops-conductor-01
    hostname: xyops.server.example.com

    environment:
      TZ: America/Los_Angeles
      XYOPS_hostname: xyops.server.example.com
      XYOPS_masters: xyops.server.example.com
      XYOPS_base_app_url: https://xyops.server.example.com
      XYOPS_satellite__config__host: xyops.server.example.com
      XYOPS_satellite__config__secure: "true"
      XYOPS_satellite__config__port: "443"

    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./xyops/data:/opt/xyops/data
      - ./xyops/conf:/opt/xyops/conf
      - ./xyops/logs:/opt/xyops/logs

    networks:
      - web

    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=web"

      - "traefik.http.routers.xyops.rule=Host(`xyops.server.example.com`)"
      - "traefik.http.routers.xyops.entrypoints=websecure"
      - "traefik.http.routers.xyops.tls=true"
      - "traefik.http.routers.xyops.service=xyops"

      - "traefik.http.services.xyops.loadbalancer.server.scheme=http"
      - "traefik.http.services.xyops.loadbalancer.server.port=5522"
      - "traefik.http.services.xyops.loadbalancer.healthcheck.path=/health"
      - "traefik.http.services.xyops.loadbalancer.healthcheck.interval=10s"
      - "traefik.http.services.xyops.loadbalancer.healthcheck.timeout=3s"

networks:
  web:
    external: true

Change websecure to the actual HTTPS entry point name in your Traefik configuration. If certificate resolution is configured per router rather than globally, you would also add your tls.certresolver label.

The important additions are:

• traefik.docker.network=web, so Traefik does not guess which Docker network to use.
• An explicit router-to-service association.
• An explicit http backend scheme and port 5522.
• A /health check, which only succeeds once xyOps is primary.

Traefik documents the network and service port labels in its Docker routing documentation. It also confirms that WebSockets work through normal HTTP routing without special upgrade-header configuration.

About the satellite connection model

The intent is centralized fleet management rather than several competing configuration mechanisms:

1. A new xySat receives an initial hosts list during installation.
2. It connects to one conductor and discovers which conductor is primary.
3. The primary distributes the centrally managed satellite.config.
4. If the conductor cluster changes, xyOps updates the hosts list.
5. A per-server host setting is available for unusual routing cases.
6. managed_keys is available when a server needs local settings that the conductor should not overwrite.

For a simple single-conductor setup, it boils down to:

• One stable conductor identity
• One public application URL
• One xySat connection endpoint

The extra options exist for multi-conductor clusters and worker servers on different networks. You should not need most of them in a homelab.

If the restart problem persists, the most useful diagnostic information would be:

docker compose config
docker logs xyops-conductor-01
curl -i http://127.0.0.1:5522/health
curl -k -i https://xyops.server.example.com/health

Please also include the relevant Traefik log entries, masters.json, and only the property names from overrides.json. Make sure to redact secret_key, authentication tokens, cookies, and other credentials.

I will work on making the setup instructions easier. You're right that they are quite complex at the moment.

[s7a7ic]

Thank you for your extensive response.

Just did some tests and can report that the XYOPS_masters setting is not causing any problems. The hostname setting was probably missing before as the ECONNREFUSED error does not happen when it is configured.
Without it, an additional conductor gets added with the random container id as the hostname and the hostname provided by the XYOPS_masters value is not reachable externally on port 5522 in my setup.

Some clarification on my configuration

The "browser path" in my environment is exactly like you described.

I use traefik for mainly for these reasons:

• No need to change ports or enable https inside the container as it's routing the connection to the default container port without having to mange certificates for different services.
• It does all the work of terminating TLS (providing a secure https connection) with a known certificate for multiple web services.
• Use as a load balancer for multiple containers running on one or more hosts.

Some ideas on this issue

The XYSat configuration could be made easier, but I don't know how practical it is in your implementation or if I'm missing some requirements for the XYSat connection to the server.

XYOps reminds me of a similar software I used once in a windows environment.

• There was a configurable "hosts" list for the agents (satellites) to connect to.
• You could only make the decision if all hosts in the lists are secure or not (use of HTTP or HTTPS for the connection).
• Primary was always the first in the list which looked like: ['loadbalancer.example.com:443', 'server1.example.com:5523', 'server2.example.com:5523']
• If the load balancer wasn't reachable, then the agents would connect directly to a server.

My thinking: Why not just provide a basic endpoint list with ports to the satellites even if it's just one host?

• XYOps does this already without a port

The list can be made configurable in the Web UI prefilled by the conductor automatically and maybe some manual enable/disable checkbox.
This would make the specific satellite.conf.host setting obsolete and also provide a way to configure endpoints for the satellites without editing the overrides.json or setting the environment variables.

Further tests withouth XYOPS_satellite__config__*

I've tested a compose file to create a new container with XYOPS_masters and without XYOPS_satellite__config__*.

Then made the changes in override.json (without restarting the container) so it looks like this:

{
  "secret_key": "redacted_secret_key",
  "satellite": {
    "config": {
      "port": 443,
      "secure": true
    }
  }
}

Everything works at this point: satellite connects, workflows can be run, correct url when adding servers, no errors.

However when the XYOps container is restarted I get the following error in the container log:

| xyOps > Startup complete, entering main loop

| ✅ Transaction > master_primary | Conductor server is now primary: xyops.server.example.com | {"host":"xyops.server.example.com"}

| ✅ Transaction > critical | Crash log was found at startup. | {"details":"**Log Contents:**\n\n```\nTue Jul 28 2026 12:32:17 GMT+0200 (Central European Summer Time) - xyops.server.example.com - xyOps v1.0.85 - PID 7\nTypeError: Cannot read properties of undefined (reading 'replace')\n    at Request.request (/opt/xyops/node_modules/pixl-request/request.js:504:13)\n    at Request.<anonymous> (/opt/xyops/node_modules/pixl-request/node_modules/class-plus/class.js:76:70)\n    at Request.get (/opt/xyops/node_modules/pixl-request/request.js:307:8)\n    at Request.<anonymous> (/opt/xyops/node_modules/pixl-request/node_modules/class-plus/class.js:76:70)\n    at Request.json (/opt/xyops/node_modules/pixl-request/request.js:227:15)\n    at Request.<anonymous> (/opt/xyops/node_modules/pixl-request/node_modules/class-plus/class.js:76:70)\n    at /opt/xyops/lib/api/satellite.js:112:19\n    at FSReqCallback.oncomplete (node:fs:196:21)\n```\n","server":"xyops.server.example.com","hostname":"xyops.server.example.com"}

When opening the web UI in the browser the 502 errors are shown:

When clicking on "Servers" in the menu the web UI starts returning 404 errors and a "Reconnecting" message as the xyops goes into a crash + restart loop.

This is the container log after clicking on the "Servers" menu

| Comm > New WebSocket client connected: wsms4iwmqznujdi2 (IP: ::ffff:172.20.0.8) | {"current":1}

| xyOps > Uncaught Exception: TypeError: Cannot read properties of undefined (reading 'replace') | "TypeError: Cannot read properties of undefined (reading 'replace')\n    at Request.request (/opt/xyops/node_modules/pixl-request/request.js:504:13)\n    at Request.<anonymous> (/opt/xyops/node_modules/pixl-request/node_modules/class-plus/class.js:76:70)\n    at Request.get (/opt/xyops/node_modules/pixl-request/request.js:307:8)\n    at Request.<anonymous> (/opt/xyops/node_modules/pixl-request/node_modules/class-plus/class.js:76:70)\n    at Request.json (/opt/xyops/node_modules/pixl-request/request.js:227:15)\n    at Request.<anonymous> (/opt/xyops/node_modules/pixl-request/node_modules/class-plus/class.js:76:70)\n    at /opt/xyops/lib/api/satellite.js:112:19\n    at FSReqCallback.oncomplete (node:fs:196:21)"

TypeError: Cannot read properties of undefined (reading 'replace')
    at Request.request (/opt/xyops/node_modules/pixl-request/request.js:504:13)
    at Request.<anonymous> (/opt/xyops/node_modules/pixl-request/node_modules/class-plus/class.js:76:70)
    at Request.get (/opt/xyops/node_modules/pixl-request/request.js:307:8)
    at Request.<anonymous> (/opt/xyops/node_modules/pixl-request/node_modules/class-plus/class.js:76:70)
    at Request.json (/opt/xyops/node_modules/pixl-request/request.js:227:15)
    at Request.<anonymous> (/opt/xyops/node_modules/pixl-request/node_modules/class-plus/class.js:76:70)
    at /opt/xyops/lib/api/satellite.js:112:19
    at FSReqCallback.oncomplete (node:fs:196:21)

| xyOps > xyOps v1.0.85 Starting Up | {"pid":7,"ppid":1,"node":"v22.23.1","arch":"x64","platform":"linux","argv":["/usr/local/bin/node","/opt/xyops/lib/main.js","--foreground"],"execArgv":["--max-old-space-size=4096"]}

Note

This does not happen when setting XYOPS_satellite__config__port=443 and XYOPS_satellite__config__secure=true in contrast to setting these values in overrides.json.

Maybe this explains the questions I had in my first post a little bit.

[jhuckaby]

Thank you very much for doing all of this additional testing and for providing the complete crash trace. This explains the behavior perfectly, and you were right that the restart problem was correlated with the satellite configuration change.

You have also uncovered a real crasher bug in xyOps. I will be fixing that right away!

The crash occurs in the conductor's satellite release API when the Servers page asks for the available xySat versions. Regardless of which component owns the code, an API request should never be able to crash the entire conductor, even when the configuration is incomplete or invalid. That part is definitely a bug on our side.

Why it crashed

So, the root cause is the structure that was manually added to overrides.json:

{
	"secret_key": "redacted_secret_key",
	"satellite": {
		"config": {
			"port": 443,
			"secure": true
		}
	}
}

The overrides.json file is not intended to be a second, partial copy of config.json, and it does not perform a recursive merge of nested objects. It is an internal, machine-managed file written by xyOps, primarily when settings are changed through the configuration UI. It is not intended to be manually authored or edited by users.

Internally, the file is a sparse collection of individual configuration paths. For example, when the xyOps UI changes these two settings, it writes something conceptually like this:

{
	"secret_key": "redacted_secret_key",
	"satellite.config.port": 443,
	"satellite.config.secure": true
}

Each dotted key identifies one specific leaf in the main configuration tree.

When the manually edited file instead contains a top-level key named satellite, xyOps interprets that as an instruction to replace the entire satellite object. It does not merge the nested config object into the existing one.

The normal satellite configuration contains considerably more than the settings sent to xySat. In simplified form, it looks like this:

{
	"satellite": {
		"list_url": "https://api.github.com/repos/pixlcore/xysat/releases",
		"base_url": "https://github.com/pixlcore/xysat/releases",
		"image": "ghcr.io/pixlcore/xysat",
		"version": "latest",
		"enable_version_checks": true,
		"cache_ttl": 3600,
		"config": {
			"port": 5522,
			"secure": false
		}
	}
}

After your nested override was loaded, the effective value became only:

{
	"satellite": {
		"config": {
			"port": 443,
			"secure": true
		}
	}
}

This removed satellite.list_url, satellite.base_url, satellite.image, satellite.version, and the other sibling properties. These are all required properties, so the code basically lost its marbles, and did not handle that case well at all.

That also explains why the environment variables do not produce the same failure. This environment variable:

XYOPS_satellite__config__port=443

is translated into the specific path satellite.config.port. Only that one leaf is changed, while the rest of the satellite object remains intact.

So your original observation was correct. The environment variables and the manually edited file really did behave differently in this case. The reason was not a different implementation for xySat connectivity, but the fact that the nested satellite object in overrides.json replaced the entire existing object.

Why everything initially appeared to work

Several parts of xyOps only need the two properties that remained:

satellite.config.port
satellite.config.secure

For example, generating the "Add Server" installation command only needs enough information to build the connection URL. Existing satellites and workflows also do not need the conductor's xySat release metadata during normal operation.

The browser may also have already cached the latest xySat version information in memory. This can temporarily hide the missing list_url property.

When the Servers page is opened in a new session, xyOps asks the conductor for the available xySat releases so it can identify outdated agents. The conductor eventually reaches code equivalent to:

self.request.json( sat.list_url, ... );

At that point, sat.list_url is undefined because the parent satellite object was replaced. The HTTP request library attempts to process the missing URL as a string and throws:

TypeError: Cannot read properties of undefined (reading 'replace')

That exception is not currently caught, so the entire conductor process exits. Docker restarts the process, and Traefik understandably returns 502 or temporarily 404 responses while the upstream container is repeatedly crashing and restarting.

The message saying that a crash log was found at startup is xyOps reporting the crash record left by the previous process. The later uncaught exception after opening Servers is the new crash that starts the loop again.

This matches every part of the behavior you reported.

What should be used in Docker

For Docker Compose, I recommend keeping these deployment-specific settings in the environment:

environment:
  XYOPS_satellite__config__host: xyops.server.example.com
  XYOPS_satellite__config__port: "443"
  XYOPS_satellite__config__secure: "true"

Alternatively, settings can be changed through the xyOps configuration UI, which will write the appropriate sparse keys into overrides.json.

The existing overrides.json should generally be left under xyOps control. This is especially important because it may contain the generated secret_key and other settings maintained by internal operations.

For recovery, the manually added nested satellite object can be removed while preserving the existing secret_key, and the satellite connection settings can remain in the Compose environment.

The crasher is still our bug

Even though the nested shape is not the intended format for overrides.json, xyOps should not crash like this.

At minimum, the satellite release API should verify that satellite.list_url is present and valid before trying to make a request. If it is missing, the API should return a clear configuration error while the conductor remains online.

I will fix this crasher right away. I will also clarify the documentation around overrides.json, because the current wording does not make the sparse path format sufficiently clear. Saying that the file is "applied on top of config.json" can reasonably sound like nested objects will be recursively merged, even though that is not how the internal override system works.

Thank you again for continuing to investigate this. Your crash trace made the problem immediately identifiable.

About the endpoint-list idea

Your broader suggestion about giving xySat an explicit list of endpoints is reasonable, especially for a topology where workers should try a load balancer first and then fall back to individual conductors.

The current xySat model has:

• A hosts list containing the conductor hosts.
• A single global port setting.
• A single global secure setting.
• An optional host value that overrides the conductor list for special network topologies.

As you correctly observed, this cannot cleanly express a sequence such as:

loadbalancer.example.com:443
server1.example.com:5523
server2.example.com:5523

with different routing behavior for each endpoint. When the static host override is present, it deliberately takes precedence over the distributed hosts list rather than participating in it as an additional fallback.

If this area were redesigned, a list of full endpoint URLs might be clearer and more flexible than separate host, port, and secure properties. For example:

{
	"endpoints": [
		"wss://loadbalancer.example.com:443",
		"wss://server1.example.com:5523",
		"wss://server2.example.com:5523"
	]
}

Each endpoint would then carry its own protocol and port.

There are some xyOps-specific details that would need careful consideration. In particular, xySat does not assume that the first conductor in its list is primary. It can connect to a conductor, learn which conductor currently owns the primary role, and reconnect appropriately. The conductor list can also be updated automatically when the cluster membership changes. A load balancer endpoint would need to coexist with that discovery and failover behavior without accidentally leaving workers connected to a backup conductor.

Still, the use case you described is valid, and I appreciate the suggestion. I would consider that a separate feature proposal from the crash itself, but it is useful feedback on where the current host versus hosts model becomes difficult to reason about.

And finally, thank you for confirming the XYOPS_masters behavior. Your latest test matches the expected behavior: once the stable conductor hostname is explicitly configured and matches the master entry, xyOps recognizes the single conductor as itself and does not try to contact a phantom conductor based on a random container ID.

Thanks again! I really appreciate all your work and detail in these posts.

[s7a7ic]

Thank you for your extensive answers.

You confirm the mistake I made while manually edit the overrides.json file.
I finally looked deeper into the configuration menu, as I had more time yesterday, and found the xySat "Edit JSON..." button.
After changing the values there, everything works as intended.
Please excuse my "user error", and I'm glad that it at least helped to make xyOps more resilient.

Now it's time for me to really get into xyOps and create some useful workflows.

Even if I've just started, I can say that it is really impressive software, and I wish you great success with it.

[jhuckaby]

Thank you so much! I am very happy you are enjoying it.

Let me know if you run into any more issues!