Skip to content

v1.6.0: Lifecycle Hooks and Reverse Proxy Support

Choose a tag to compare

@jdx jdx released this 21 Feb 17:22
· 222 commits to main since this release
Immutable release. Only release title and notes can be modified.
5f59d71

Pitchfork v1.6.0 adds daemon lifecycle hooks for reacting to ready, failure, and retry events, along with new environment variables injected into every daemon process. This release also adds support for serving the web UI behind a reverse proxy path prefix and fixes ready_cmd to respect the daemon's working directory.

Highlights

  • Lifecycle hooks: Run custom shell commands when daemons become ready, fail, or retry via a new [daemons.<name>.hooks] config section
  • Daemon metadata env vars: Every daemon process now receives PITCHFORK_DAEMON_ID and PITCHFORK_RETRY_COUNT automatically
  • Reverse proxy path prefixes: Serve the web UI under a custom path using --web-path or PITCHFORK_WEB_PATH

Added

  • Daemon lifecycle hooks -- Configure on_ready, on_fail, and on_retry hooks under [daemons.<name>.hooks] to fire shell commands in response to daemon events. Hooks are fire-and-forget and run in the daemon's working directory. (#245) - @jdx

    [daemons.api]
    run = "node server.js"
    retry = 3
    
    [daemons.api.hooks]
    on_ready = "echo 'api is ready'"
    on_fail = "./scripts/cleanup.sh"
    on_retry = "echo 'retrying...'"
  • Daemon process environment variables -- PITCHFORK_DAEMON_ID and PITCHFORK_RETRY_COUNT are now automatically set for every daemon process and its hooks. The on_fail hook additionally receives PITCHFORK_EXIT_CODE. (#245) - @jdx

  • Web UI path prefix support -- Use --web-path <PATH> or PITCHFORK_WEB_PATH=<PATH> to serve the web UI under a subpath, making it easy to run behind a reverse proxy. All routes, links, HTMX polling, SSE streaming, and static assets work correctly under the prefix. (#244) - @jdx

    PITCHFORK_WEB_PORT=9001 PITCHFORK_WEB_PATH=ps pitchfork supervisor run
    # Web UI is then available at /ps/ on port 9001

Fixed

  • ready_cmd now respects daemon working directory -- The readiness check command (ready_cmd) previously ran in the supervisor's directory rather than the daemon's configured dir. It now correctly uses the daemon's working directory. (#243) - @gaojunran

New Contributors

Full Changelog: v1.5.0...v1.6.0