| name | relay-admin-console |
| description | Open (or close) the gateway admin console โ forward the VPS's loopback admin port over your secure SSH path (e.g. Google IAP) to a local port and browse it, or read usage from the CLI without a browser. Handles the recurring "console page won't load" problem (the SSH forward must run in the user's OWN terminal and stay open). Use when the user wants to open the admin UI / dashboard / server UI, log in to the gateway, or check usage and spend. |
| allowed-tools | Read, Bash, Agent |
Open the gateway admin console
The console binds to loopback only on the VPS โ nothing is exposed on the network; you reach it by
forwarding the port over your secure SSH path. Replace relay-vps/us-central1-a/8080 with your own.
The key constraint (why this keeps "breaking")
The forward lives only as long as its SSH process. On Windows gcloud drives plink, which can exit on
its own. Do not launch the forward as a background task from here โ it will die. Give the user the
exact command to run in their own terminal, left open.
Open (web UI)
- Tell the user to run this in their own terminal and keep it open (IAP example):
gcloud compute ssh relay-vps --zone=us-central1-a --tunnel-through-iap -- -L 8088:127.0.0.1:8080 -N
(Bastion/plain SSH equivalent: ssh -L 8088:127.0.0.1:8080 -N <user>@<host>.)
- Then browse http://127.0.0.1:8088 and log in as the gateway admin.
- If the page stops loading, the SSH process exited โ just re-run the command.
Usage from the CLI (no browser)
Delegate to the relay-operator agent (or have the user SSH in) to run the bundled usage script
(vps/cache-usage.sh --summary for a 24h rollup, --watch to tail live).
Close
Stop the SSH process in the terminal where it runs (Ctrl-C / close the window). Nothing persistent is
left open; the console was never exposed beyond loopback.
Guardrails
- Never expose the admin port beyond loopback or add an inbound firewall rule to "make it reachable".
- Never print the admin password or any key.
