If you use the Warden Agent, or connect an AI assistant to your PodWarden instance through Hub, you may have hit this:
Instance is not currently reachable on the tunnel
And you may have found it maddening, because your dashboard showed the instance as CONNECTED, with a heartbeat from seconds ago. Both things were true at the same time. Here is what was actually happening, and what we changed.
One connection, several front doors
Your instance connects to Hub over a secure WebSocket tunnel. That tunnel is what lets Hub reach into your instance without you opening a single port to the internet.
Hub itself runs on several nodes, for redundancy. Ordinary web requests are spread across all of them — that is the point. But a tunnel is a long-lived connection, so it lives in the memory of exactly one node: whichever one your instance happened to reach when it connected.
So Hub had two facts that could disagree. The dashboard badge came from the shared database and was cluster-wide, which is why it correctly said "connected". The agent's ability to act depended on your request happening to land on the one node holding your socket. When it did not, you got an error about reachability — about the only thing that was not actually wrong.
Why it stuck around
The frustrating part was that it did not fix itself.
A tunnel reconnects whenever we deploy or the network hiccups. If the node it had been using was briefly busy restarting, your instance would land somewhere else — and then stay there, because a WebSocket does not move once established. Meanwhile your browser kept being routed to the original node.
The practical effect: a Hub deploy could break the agent for you, and leave it broken for hours, until something happened to bounce the connection back. The workaround was to restart your PodWarden service and hope it landed better. That is not a workaround anyone should need.
What we changed
Every Hub node can now serve every instance.
When a request arrives at a node that does not hold your tunnel, that node checks that you are allowed to make the request — your organization, your credentials, exactly the same checks as before — and then forwards it over an internal, mutually-authenticated connection to the node that does hold it. The result comes back the same way.
There is nothing to enable and nothing to configure. The only difference you should notice is that things which used to fail now work.
Your actions still run at most once
Forwarding a request between machines raises a fair question, especially if you use the agent to change things: if the forward fails, did it happen or not?
We took the careful answer. A forwarded call is attempted once. Hub does not quietly retry it somewhere else, because retrying "restart this container" is not a free action.
When something does go wrong, Hub tells you which kind of failure it was: one where the request provably never reached your instance and is safe to try again, or one where the outcome is genuinely unknown. In the second case it says so, rather than guessing on your behalf. If you see it during a change, check the state of the thing you were changing before retrying.
The error message still exists — and now it is honest
If you see "not currently reachable" today, it means what it says: your instance is not connected. Check that the service is running, that the tunnel is enabled in Settings → MCP, and that the dashboard heartbeat is recent.
If the heartbeat is recent and you still see that error, that is now a real bug rather than an expected annoyance, and we would like to hear about it.
For the full picture — including how to read the connection state and what to try first — see Tunnel Reliability in the docs.