Tunnel Reliability

Your PodWarden instance connects to Hub over a secure WebSocket tunnel. The tunnel is what lets Hub — and the AI assistants you connect to it — reach your instance without you exposing it to the internet.

Hub runs on several nodes for redundancy. This page explains what that means for the tunnel, what changed in August 2026, and how to read the errors you might still see.

The tunnel lives on one node

Hub is not a single machine. Requests to www.podwarden.com and mcp.podwarden.com are spread across several nodes, and any of them can serve you.

A tunnel is different. It is a long-lived connection, so it is held in the memory of exactly one node — whichever one your instance happened to reach when it connected. It stays there until it reconnects.

That difference — requests spread out, tunnels pinned — is the whole story.

What changed

Before August 2026, only the node holding your tunnel could act on it. When a request landed on any other node, Hub answered:

Instance is not currently reachable on the tunnel

That message was misleading. Your instance was connected the whole time and the dashboard correctly showed CONNECTED. Only the node was wrong.

It also tended to persist. A tunnel reconnects when Hub deploys or the network blips, and it may land on a different node than before — then stay there for hours while your requests kept arriving at the original one. The usual fix was to restart your instance's connection until it landed somewhere useful.

Now, every node can serve every instance. A node that does not hold your tunnel checks that you are allowed to make the request, then forwards it over an internal, mutually-authenticated connection to the node that does.

You should not notice any of this. There is no setting to enable and nothing to configure — the only visible difference is that requests which used to fail now succeed.

What this does and does not fix

The error message still exists, and it still means something — it just means what it says now. If you see it, your instance really is not connected.

Your request runs at most once

Forwarding a request between nodes introduces a question that matters if you use the AI assistant to change things: if a forward fails, did the action happen?

Hub is deliberate about this. A forwarded call is attempted once. Hub never silently retries it on another node, because a retry of something like "restart this container" or "delete this volume" is not free.

Every failure tells you which side of the line it fell on:

• Provably not run — the request never reached your instance. Safe to retry.
• Outcome unknown — the request may have reached your instance and may have already taken effect. Hub will not retry this for you.

When the outcome is unknown, Hub says so rather than guessing. If that happens during a change, check the current state of the thing you were changing before you try again.

If you still see "not currently reachable"

Work through these in order.

1. Check the instance is actually up. On the machine running PodWarden, confirm the service is running and has network access.
2. Check the dashboard badge. Hub Dashboard shows a connection state and a last-heartbeat time for each instance. A stale heartbeat means the tunnel is genuinely down, not misrouted.
3. Check the tunnel is enabled. Settings → MCP on your instance, and Settings → Hub for the instance key.
4. Reconnect the instance if the heartbeat is stale — restart the PodWarden service to force a fresh tunnel.

If the dashboard shows a recent heartbeat and you still get the error, that is worth reporting: since this change, those two things should no longer disagree. Include the instance ID and the time.

Related

• Connecting to Hub — set up the instance key
• Hub MCP Proxy — connect an AI assistant
• Hub Dashboard — where connection state is shown