Ports and hosts are emitted with wrong coordinates depending on deployment
Nebula always emits host-mapped (external) ports and a host derived from TestContainers' container.host, then patches the host after the fact by string-replacing it with the consumer's HTTP Host header (updateHostReferences). This breaks depending on where the consumer sits relative to the spawned containers, and forces workarounds (/etc/hosts entry mapping nebula → localhost, TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal, host-networking).
The real variable isn't where Nebula runs — it's where the consumer reaches the containers from:
| Consumer vantage point |
Host |
Port |
| Host machine (dev CLI, Linux host-mode compose) |
localhost |
mapped/external port |
Inside nebula_network (Orbital in compose) |
container network alias (componentName) |
internal port |
If the compose deployment emits in-network coordinates, Orbital talks to containers directly over nebula_network and the host.docker.internal / host-networking / /etc/hosts workarounds become unnecessary.
Proposed change
- Add a connectivity mode flag:
--connectivity=host|network (NEBULA_CONNECTIVITY), default host (preserves current CLI behaviour); compose sets network. Wire into NebulaConfig.
- Add a single coordinate resolver returning
(host, port) per mode:
HOST → container.host + getMappedPort(internalPort)NETWORK → componentName (network alias) + internalPort
- Emit a discrete
host + port per component, and rebuild jdbcUrl / bootstrapServers / S3 endpoint from the same resolved endpoint so embedded strings can't drift.
- Kafka: advertise
alias:<internal-port> in network mode vs mapped port in host mode.
- Remove
updateHostReferences / HostNameAwareContainerConfig and the HTTP-host-header rewrite entirely (replaced by mode-driven construction). Removes the need for the /etc/hosts hack.
Notes
- Nebula's own internal clients (Hikari, Kafka admin) keep using the TestContainers host-mapped path — unchanged.
TESTCONTAINERS_HOST_OVERRIDE remains relevant only for Nebula's self-connection on non-Linux compose.
- Follow-up: in
network mode, two stacks sharing a network with the same component name will collide on alias — may need to namespace the alias (${stack}-${componentName}).
Ports and hosts are emitted with wrong coordinates depending on deployment
Nebula always emits host-mapped (external) ports and a host derived from TestContainers'
container.host, then patches the host after the fact by string-replacing it with the consumer's HTTPHostheader (updateHostReferences). This breaks depending on where the consumer sits relative to the spawned containers, and forces workarounds (/etc/hostsentry mappingnebula → localhost,TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal, host-networking).The real variable isn't where Nebula runs — it's where the consumer reaches the containers from:
localhostnebula_network(Orbital in compose)componentName)If the compose deployment emits in-network coordinates, Orbital talks to containers directly over
nebula_networkand thehost.docker.internal/ host-networking //etc/hostsworkarounds become unnecessary.Proposed change
--connectivity=host|network(NEBULA_CONNECTIVITY), defaulthost(preserves current CLI behaviour); compose setsnetwork. Wire intoNebulaConfig.(host, port)per mode:HOST→container.host+getMappedPort(internalPort)NETWORK→componentName(network alias) +internalPorthost+portper component, and rebuildjdbcUrl/bootstrapServers/ S3 endpoint from the same resolved endpoint so embedded strings can't drift.alias:<internal-port>innetworkmode vs mapped port inhostmode.updateHostReferences/HostNameAwareContainerConfigand the HTTP-host-header rewrite entirely (replaced by mode-driven construction). Removes the need for the/etc/hostshack.Notes
TESTCONTAINERS_HOST_OVERRIDEremains relevant only for Nebula's self-connection on non-Linux compose.networkmode, two stacks sharing a network with the same component name will collide on alias — may need to namespace the alias (${stack}-${componentName}).