v2.34.0: HTTPS for the web UI and pitchfork completion --install

The web UI can now serve HTTPS directly, and pitchfork completion --install writes shell completions to the right place for you. This release also fixes two bugs that affected daemons started at the same time.

Added

• Serve the web UI over HTTPS (#1104) by @disintegrator. Set web.tls_cert and web.tls_key (or PITCHFORK_WEB_TLS_CERT / PITCHFORK_WEB_TLS_KEY) so the web UI port serves HTTPS with HTTP/2 and HTTP/1.1. This keeps X-Pitchfork-Token encrypted when you bind to a non-loopback address.

  [settings.web]
  auto_start = true
  bind_address = "0.0.0.0"
  tls_cert = "/etc/pitchfork/web.crt"   # PEM, may include the chain (leaf first)
  tls_key = "/etc/pitchfork/web.key"    # PEM: PKCS#8, PKCS#1 or SEC1

  Both settings default to empty, which keeps plain HTTP. You must set both or neither. The web UI won't start if only one is set, or if a file is missing, can't be parsed, or the key doesn't match the certificate. With TLS on:

  • pitchfork supervisor status reports an HTTPS URL.
  • Plain HTTP requests to the port are rejected, not redirected.
  • If the reverse proxy is enabled, it redirects pitchfork.<tld> to the HTTPS URL.

  The standalone API server ([settings.api]) still serves only plain HTTP.

• pitchfork completion <shell> --install (#1105) by @jdx writes the completion script to the location your shell expects, without editing any startup files. If the script is already there, running the command again does nothing or updates it. It won't replace a file it didn't write unless you add --force, which only works together with --install. Supported shells are now bash, zsh, fish, PowerShell (powershell/pwsh), Elvish and Nushell (nu/nushell).

  pitchfork completion fish --install
  pitchfork completion zsh --install --force

Fixed

• Concurrent starts now wait for the daemon to be ready (#1108, fixes #1107) by @jrandolf.

  • A pitchfork start that finds a daemon still running its ready check now waits for that check and returns its result. This includes retries with backoff and restarts triggered by file changes. Previously it reported "already running" right away.
  • Dependent daemons also wait for their dependencies to be ready during retries and restarts.
  • The waiting start uses the readiness deadline of the start already in progress. Its own readiness overrides can't shorten that deadline.
  • Cancelling the start that began the check no longer lets other waiting starts continue early.
  • A readiness timeout is still a failure even if the daemon exits with code 0 while being stopped. If pitchfork can't stop the daemon, it reports that error and doesn't start a replacement while the old process group is still alive.
  • Daemons that are already running now pass their resolved ports to the templates of daemons that depend on them.

• Concurrent starts no longer get the same port (#1114, fixes #1113) by @jdx. Two daemons expecting the same port could both be given it if they started together. One then failed with Address already in use, or with SO_REUSEPORT both bound it and split the traffic. The supervisor now reserves resolved ports until the daemon exits. While a port is reserved, another start moves to the next free port if bump is set, and otherwise fails with port N is reserved by daemon <id>. A standalone ready_port is also reserved when no expected ports are configured. These reservations only cover daemons that pitchfork starts.

Full Changelog: v2.33.1...v2.34.0

💚 Sponsor pitchfork

pitchfork is built and maintained by @jdx, an open source developer at entire.io, the title sponsor of his open source work.

If pitchfork has a place in your development workflow, please consider becoming an individual or company sponsor. Your support funds ongoing development and helps keep pitchfork fast, free, and independent.