Repository navigation
[Bug]: Loopback-only apps unreachable through the edge + port check gives false positive #1022
Description
Description
Deployment containers are published as 127.0.0.1:<hostPort>->3000/tcp, i.e. Docker forwards to the container's eth0 address. Apps that intentionally bind only 127.0.0.1 inside the container (OpenMausBot documents exactly this: "The server only ever listens on loopback… never publish that port yourself", with an in-namespace Caddy sidecar as the intended pattern) end up behind 502 openship-edge-upstream-down.
Meanwhile the deploy log reports Port check: port 3000 is listening. — because the check probes 127.0.0.1:3000 inside the container, which is not how the edge reaches the app. A green port check with a dead app is a misleading success signal.
Steps to reproduce
- Deploy any app that binds
127.0.0.1:PORTonly (e.g.ghcr.io/milind-soni/openmausbot:latestwithOMB_PORT=3000). curl http://127.0.0.1:<hostPort>/→ no response; edge returns 502.- Deploy log still says
Port check: port 3000 is listening.
Expected
- The port check should validate reachability the same way the edge connects (container IP / published port), not container-internal loopback.
- Ideally: support
network_mode: service:<svc>sidecar compose services (the well-known pattern for loopback-only servers), or detect loopback-only binds and insert a tiny forwarding proxy automatically.
Workaround used
A wrapper container running the app (loopback) plus a small Node TCP/HTTP+WS forwarder bound to 0.0.0.0:3000.
Activity
Metehan-Bicer commentedon Oct 10, 2026
Hi! I'd like to take the port-check part of this. On
main,parseListeningPorts(packages/adapters/src/system/port-listen.ts) reads/proc/net/tcpinside the container but ignores the local address, so a socket bound only to127.0.0.1counts as listening and the deploy log saysPort check: port 3000 is listening.My plan: keep the bind address when parsing, and when a Docker deployment's port is bound only to loopback, log a warning that the edge can't reach it (bind0.0.0.0instead) rather than the green line. On the bare runtime the edge reaches the app on the host, so loopback is fine there and nothing changes. Sidecar /network_mode: service:<svc>support is a bigger feature that needs your call on the design, so I'd leave it out of this PR.fix(deploy): warn when a Docker app only listens on loopback