OpenCockpitOpenCockpit
← Back to blog

Cockpit now takes an access token

Published July 2, 2026 · 2 min read

Cockpit is local-first and fully open on your own machine. When you expose it on a LAN or a cloud sandbox, an optional access token now guards remote access — while local stays frictionless.

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

ClientHow
BrowserFirst 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 / WebSocketAuthorization: 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