Deploy websocketd

Pick the page that matches your environment. Each one gives you a working configuration first.

The proxy pages solve the same problem three ways: your public server terminates the connection, and the WebSocket upgrade has to survive the trip to websocketd. Choose the one you already run.

• Serve behind nginx — Proxy WebSocket upgrades to websocketd through nginx, with the two headers nginx drops and the timeout that kills idle connections.
• Serve behind Apache — Proxy WebSocket upgrades to websocketd through Apache httpd using mod_proxy_wstunnel.
• Serve behind HAProxy — Carry WebSocket upgrades to websocketd through an HTTP-mode HAProxy backend, with the timeouts long-lived connections need.
• Start at boot with systemd — A complete systemd unit that runs websocketd as an unprivileged service, starts it at boot, and restarts it on failure.
• Run in a container — Package websocketd and your script into a container image, with the no-pty limitation and PID 1 signal handling.
• Deploy to Kubernetes — A Deployment, a Service, and a WebSocket-aware Ingress for websocketd, with the probe that actually works.
• Serve over wss:// — Terminate TLS in websocketd with --ssl, require client certificates with --sslca, or terminate at a proxy and keep the origin policy working.
• Coexist with another web server — Serve websocketd and another application on one public port by putting a reverse proxy in front of both.
• Check before exposing it publicly — A checklist of decisions to settle before websocketd is reachable from anywhere but localhost.