Protect Remote Access with an Access Token
Set an OpenCockpit access token to guard remote connections from your LAN or cloud sandbox while keeping local access simple.
Cockpit has always been local-first: it binds to 127.0.0.1, and on your own machine anyone on that machine can use it. That's the right default for a local tool. But sometimes you put Cockpit somewhere else — on your LAN, or in a cloud sandbox — and then "anyone who can reach the port" is too open. This release adds an optional shared access token.
Turn it on
Pass a token when you start the server:
cockpit --token my-secret-value
Or set COCKPIT_TOKEN in the environment. It's off by default — existing local setups don't change at all.
Local stays frictionless
With a token set, loopback requests are still exempt. The CLI, /cg snippets, and a browser on the same machine keep working with no token — only remote requests need it. Turning this on never gets in your own way.
Three ways to present it
| Client | How |
|---|---|
| Browser | First visit with ?token=<value> — Cockpit sets a cookie and redirects to a clean URL, so the secret doesn't linger in the address bar |
| API / WebSocket | Authorization: Bearer <value> header |
| Anything | ?token=<value> query param |
A wrong or missing token is rejected, and tokens are compared in constant time.
Use it when you go remote
The token pairs with network exposure. When you open Cockpit up with COCKPIT_HOST=0.0.0.0 for a LAN or a cloud sandbox, add a token so it isn't wide open:
COCKPIT_HOST=0.0.0.0 cockpit --token my-secret-value
That's the whole feature. Full details are in the CLI reference.
Try it: npm i -g @surething/cockpit · GitHub · Try Online