COCKPIT-WS(8)

๐Ÿ’… COCKPIT-WS(8) โ€” the cockpit manual, bestie edition โœจ

okay so. <rainbow>cockpit-ws</rainbow>?? That's the Cockpit web service, and it's section 8 of the cockpit manual. sit down, hydrate, and let's get into it ๐Ÿซถ


โœจ NAME โœจ

cockpit-ws โ€” the Cockpit web service, aka the little guy doing all the talking ๐Ÿ’ฌ


๐ŸŽ€ SYNOPSIS ๐ŸŽ€

cockpit-ws [--help] [--port PORT] [--address ADDRESS] [--no-tls]
[--for-tls-proxy] [--local-ssh] [--local-session BRIDGE]

that's the whole vibe. onto the details ๐Ÿ‘‘


๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

cockpit-ws is the web service component. It's the thing that handles communication between your browser app and all the various configuration tools and services like cockpit-bridge(1). So it's basically the mutual bestie connecting two friend groups ๐Ÿ’ž

IMPORTANT: users and administrators should never need to start this program themselves. It gets started automatically by systemd(1) on boot up, through cockpit-tls(8). It starts itself. It's independent. main character energy, no notes ๐Ÿ’…


๐Ÿ” TRANSPORT SECURITY ๐Ÿ”

normally cockpit-ws runs behind the cockpit-tls TLS terminating proxy, and it only deals with unencrypted HTTP by itself. periodt.

BUT (and this is the plot twist ๐ŸŽฌ) for backwards compatibility it can also handle TLS connections by itself if you run it directly. and if you wanna know how to configure certificates? bestie, go read the cockpit-tls(8) documentation. iykyk ๐Ÿ“œ


โฐ TIMEOUT โฐ

when it's started via systemd(1), cockpit-ws will exit after 90 seconds if nobody logs in. or after the last user is disconnected. it simply will not wait around for you, bestie. it has boundaries โœ‹๐Ÿ’€


๐Ÿ‘‘ OPTIONS ๐Ÿ‘‘

  • --help โ€” shows the help options. the classic. the icon ๐Ÿซถ
  • --port PORT โ€” serve HTTP requests on PORT instead of port 9090. but lowkey: usually Cockpit is started on demand by systemd socket activation, so this option has no effect. in that case you update the ListenStream directive in the cockpit.socket file in the usual systemd manner. (yes, the socket file. not a typo, it's the systemd way ๐Ÿ’…)
  • --address ADDRESS โ€” bind to address ADDRESS instead of binding to all available addresses. same deal as above: usually Cockpit starts on demand via systemd socket activation, so this option has no effect. in that case, update the ListenStream directive in the cockpit.socket file in the usual systemd manner.
  • --no-tls โ€” disable the http to https redirection. simple. clean. no drama ๐Ÿšซ๐Ÿ”’
  • --for-tls-proxy โ€” tells cockpit-ws that it's running behind a local reverse proxy doing the TLS termination. then Cockpit puts https:// URLs into the default Content-Security-Policy, and accepts only https:// origins instead of http: ones by default. HOWEVER โ€” if Origins is set in the cockpit.conf(5) configuration file, that will override this default. the config file said "not today" ๐Ÿ˜ญ
  • --local-ssh โ€” normally cockpit-ws uses cockpit-session and PAM to authenticate the user and start a user session. with this option enabled, it will instead authenticate via SSH at 127.0.0.1 port 22. plot twist, but make it SSH ๐Ÿงš
  • --local-session BRIDGE โ€” skips all authentication and cockpit-session, and launches the cockpit-bridge specified in BRIDGE in the local session. if BRIDGE is specified as - then expect an already running bridge that's connected to stdin and stdout of this cockpit-ws process. this lets the web server run as any unprivileged user in an already running session โœจ

this mode implies --no-tls, bestie. so you need to use http:// URLs with this. no cap.

โš ๏ธ WARNING โš ๏ธ with --local-session BRIDGE, you have to isolate the opened TCP port somehow โ€” for example in a network namespace โ€” otherwise all other users (or even remote machines, if the port isn't just listening on localhost) can access the session!! that's not a vibe. that's a security incident ๐Ÿ’€๐Ÿ”ฅ

๐ŸŒˆ ENVIRONMENT ๐ŸŒˆ

the cockpit-ws process will use the XDG_CONFIG_DIRS environment variable from the XDG basedir spec (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) to find its cockpit.conf(5) configuration file ๐Ÿ“‚

in addition, the XDG_DATA_DIRS environment variable from the XDG basedir spec (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) can be used to override the location to serve static files from. these are the files that get served to a non-logged in user. mysterious. anonymous. love that for them ๐Ÿ‘ป


๐Ÿ’€ BUGS ๐Ÿ’€

please send bug reports to either the distribution bug tracker or the upstream bug tracker at https://github.com/cockpit-project/cockpit/issues/new โ€” they wanna hear it, fr fr ๐Ÿ™ˆ


๐Ÿ’– AUTHOR ๐Ÿ’–

Cockpit has been written by many contributors ๐ŸŒธ โ€” https://github.com/cockpit-project/cockpit


๐Ÿ”ฅ SEE ALSO ๐Ÿ”ฅ


and that's the whole page bestie, we ate and left no crumbs ๐Ÿ“ this gorgeous little thing came out of cockpit and it's dated 2026-10-22 โ€” so go forth, never start cockpit-ws by hand, and slay ๐Ÿ’…โœจ๐Ÿ‘‘

๐Ÿ“ฆ where this page comes from