Binding a Port to Loopback Instead of Writing a Firewall Rule

A monitoring container needed its web UI reachable just long enough to complete a first-run setup wizard, and never again after that. The instinctive way to gate that is a firewall rule — allow the port during setup, close it after — which works, but creates an ongoing obligation: a rule that has to be remembered, and re-verified every time something else on the host changes.

The alternative was a smaller surface, not a bigger rule

Binding the container's port to 127.0.0.1 instead of 0.0.0.0 in the compose file means the port is never reachable from outside the host in the first place — not "blocked," genuinely absent from the network the internet can see. There's no rule to keep in sync with anything else, because there's nothing to open and close.

What made the one-time access possible anyway

An SSH tunnel forwards a local port on the operator's machine to that loopback-bound port on the host, for as long as the tunnel is open and not a second longer. The setup wizard runs through that tunnel exactly as if the port were public, and then the tunnel closes and the port goes back to being unreachable from anywhere, including the operator's own machine.

Why this beats the firewall version

A firewall rule is a second thing that can drift from the intent behind it — left open after setup, or closed too early. A loopback bind has no "after setup" state to forget to revert; the port was never public, so there's nothing to un-expose. The safer default here wasn't a stricter rule, it was removing the class of mistake a rule could make.