The machine

The machine

One screen that answers "is anything about to go wrong":

• CPU and load, against the number of cores.
• Memory, with what is cached rather than lost, and swap — the number that actually matters, because a machine swapping under pressure is a machine about to crawl.
• GPUs, memory and temperature, when there are any.
• Every disk, with a plain reading of how close each is to full.
• Uptime, and the busiest thing on the box at the top.

The same reading, in the header

The worst of those numbers again, as a small icon on every screen — not only this one. The point of it is that noticing a disk filling up should not depend on remembering to come back and look: it is read on its own clock, every 30 seconds, whether or not this screen is open, and paused while the tab is in the background.

It is quiet on purpose. A fine reading is a plain icon, the same as any other in the header — nothing pinned there permanently should shout, or it stops being noticed within a day. It picks up amber or red only once the worst number actually crosses into warning or critical, the same thresholds and the same two words this screen uses for its own hero number, and a click opens this screen.

Where it is

At the top, because "which address do I type" is the question people arrive with:

• the hostname, and the user you would ssh in as
• every address it answers on, the one on the default route first and marked as such. Found by asking the kernel which source it would use for a route to nowhere — no packet is sent, it works with the cable out, and it is right where gethostbyname(gethostname()) says 127.0.1.1 and means nothing
• your own address, as the socket saw it. Behind a reverse proxy that is the proxy, so what the proxy claims about you is shown beside it and separately: one is a fact, the other is a header
• what the world sees, only if you press it. The button names the service before you press, because asking somebody what your address is is telling them. ask_outside: false in the config removes the offer altogether

Every value has a copy button. All of them exist to be typed somewhere else, and an address read off a screen and retyped is an address with a digit wrong in it.

Listening ports

Every port with something listening, and what is holding it. A service bound to 127.0.0.1 is unreachable from a phone by design — that is what binding to loopback means.

With --allow-proxy, Argus will stand in front of one: open the port from this screen and it is served under /proxy/<port>/, inside a window or a tab. A loopback URL clicked in a terminal does the same thing on the spot.

Nothing is proxied unless the server was started with --allow-proxy and that particular port was opened by hand. A port bound to loopback was bound there on purpose.

Opening one is remembered, in a small file beside the config, so a restart is not the same as closing every port that was open before it — a job left running for days should not need somebody to come back and press Reach it again each time the machine is rebooted. --allow-proxy still gates all of it on every request, on every restart: losing that flag is exactly as it should be, and this only restores a decision that was already made while it was on.

The address, written out

Every port has a twist that opens three lines under it, whether or not it has been opened yet — because the way to see the address should not be to open the port.

the link	https://this-machine:8090/proxy/11000/?token=…, ready to paste into a new tab on the laptop you are actually working on. It carries the key, exactly like the address Argus itself is opened with, because otherwise it works in this browser and nowhere else. Clicking it opens the port on the way — the same intent as pressing Reach it, and still a decision a person makes rather than something the server does when asked
the ssh line	ssh -N -L 11000:127.0.0.1:11000 you@this-machine, for the two things a proxy in front of HTTP cannot do: a socket that is not HTTP at all, and a page that talks over a WebSocket. One line and not one per platform — the flags differ by client, not by operating system, and Linux, macOS and every Windows since 10 all ship OpenSSH
the command	what is actually holding the port

What the service sees, and does not

Your credentials stop at Argus. The token is taken out of the query before the request is passed on, the cookie and the Authorization header are dropped, and the Referer is rewritten to the service's own address without its query — that last one because a page opened at /proxy/11000/?token=… puts the whole address, token and all, into the referer of every request it makes, and a referer is not hop-by-hop. It would have gone into the service's access log.

What the service does get is a Host of 127.0.0.1:<port>, so it cannot tell it is being stood in front of, and — if it answers HTML — a <base> tag so its relative links work.

Absolute paths are handled too. A <base> cannot fix /static/app.js or /api/dashboard: those ask the root of Argus. The referer says which proxied page asked, so they are sent home — including paths Argus itself has a file for, and including the ones under /api/ that Argus would otherwise refuse before looking. Without that a dashboard renders as bare markup with no script, no style and no data, which is the shape this bug arrives in.

Reaching a port nobody found

The box above the list takes a port number, whether or not anything is listening on it yet — a service that has not started, or one the scan did not see. It shows up in the list either way, marked as opened by hand, so you can close it again.

Rescuing a login that went to the wrong machine

The case this is really for. A tool running on the server starts a browser login whose callback is http://localhost:1455/…. You do the login on your own laptop, where localhost is your laptop, and the callback lands on nothing: This site can't be reached. The port forwarding is not broken — nothing was ever forwarded to your laptop, and nothing can be: Argus is a page in a browser, not an SSH client.

What Argus can do is stand in front of the port on its own machine. Copy the dead URL out of the address bar, paste it into the same box, and it is forwarded — path and query intact — to the port it was always meant for:

http://localhost:1455/auth/callback?code=…&state=…
        ↓
https://your-server/proxy/1455/auth/callback?code=…&state=…

The listener waiting inside the server gets its callback and the login completes. Doing it by hand is the same edit, so nothing here is magic — it just saves getting the prefix wrong while a one-time code expires.

Argus's own credentials stop at the proxy: neither the token in the query nor the Authorization header reaches the service behind it, so a callback URL in somebody's log does not carry your token with it.

Why VS Code can make localhost work and this cannot

VS Code forwards a port so well that localhost:1455 on your laptop simply works. It can do that because it has a piece running on your laptop: the client opens a listening socket on your own 127.0.0.1:1455 and tunnels it to the remote one. Something really is answering there.

A web page cannot do this. A browser does not let a page listen on a TCP port of the machine showing it — nobody gets to, and rightly so. Standing in front of the port from the inside is the only move Argus has.

If you want the literal localhost behaviour, the program VS Code uses under the hood is already on your machine:

ssh -L 1455:127.0.0.1:1455 you@server

While that session is open, the dead callback URL works verbatim, with nothing to rewrite. The proxy is the answer when you have only a browser — a phone, someone else's laptop — and the price is that the address changes.

What this is not

A general proxy. It forwards HTTP to 127.0.0.1:<port> on the machine Argus runs on, one port at a time, for a browser that is already authenticated to Argus. It is not a SOCKS proxy and cannot be one: SOCKS is a TCP listener that a client — a browser, Spotify — is pointed at in its own settings, and none of those clients speak to Argus. For that, ssh -D 1080 user@server gives you a SOCKS5 proxy on your own machine in one command, authenticated by your SSH key, with nothing extra to run on the server.