### Install Dev Build and Start Supervisor

Source: https://github.com/endevco/pitchfork/blob/main/AGENTS.md

Installs the development build and starts the supervisor with debug logging enabled.

```bash
# Install dev build and start supervisor with debug logging
mise run install-dev
```

--------------------------------

### Global Configuration Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/namespaces.md

Shows how to start and view logs for daemons defined in the global configuration file using their qualified IDs.

```bash
pitchfork start global/postgres
pitchfork logs global/redis
```

--------------------------------

### Run Your First Daemon

Source: https://github.com/endevco/pitchfork/blob/main/docs/quickstart.md

Start a background process with a single command. This example starts a Python HTTP server labeled 'myserver'.

```bash
pitchfork run myserver -- python -m http.server 8000
```

--------------------------------

### Example Project Structure

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/namespaces.md

Illustrates a common project setup where multiple projects contain daemons with the same name.

```text
~/projects/
├── frontend/
│   └── pitchfork.toml    # defines "api" daemon
└── backend/
    └── pitchfork.toml    # also defines "api" daemon
```

--------------------------------

### Typical Pitchfork Boot Setup

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/boot-start.md

A common setup sequence to enable boot start and configure daemons. Includes enabling boot start, adding daemons to the global config, and verifying the setup.

```bash
pitchfork boot enable
```

```toml
[daemons.postgres]
run = "postgres -D /usr/local/var/postgres"
boot_start = true
ready_output = "ready to accept connections"
```

```bash
pitchfork boot status
pitchfork list
```

--------------------------------

### Example Dockerfile for Container Mode

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/container-mode.md

A sample Dockerfile demonstrating how to install Pitchfork and set it as the entrypoint in container mode.

```dockerfile
FROM debian:bookworm-slim

# Install pitchfork
COPY --from=ghcr.io/jdx/pitchfork:latest /usr/local/bin/pitchfork /usr/local/bin/pitchfork

# Copy your configuration
COPY pitchfork.toml /app/pitchfork.toml
WORKDIR /app

# Run pitchfork as PID 1 in container mode
ENTRYPOINT ["pitchfork", "supervisor", "run", "--container"]
```

--------------------------------

### Serve Web UI with Path Prefix

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Configure the web UI to be available under a sub-path, useful for reverse proxy setups. This example uses the CLI flag.

```bash
pitchfork supervisor run --web-port 3120 --web-path ps
```

--------------------------------

### Install Pitchfork using Mise

Source: https://github.com/endevco/pitchfork/blob/main/README.md

Use mise-en-place to globally install pitchfork. This is the recommended installation method.

```sh
$ mise use -g pitchfork
```

--------------------------------

### Enable Pitchfork Boot Start

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/boot-start.md

Enables pitchfork to start automatically when you log in. Use with sudo for system-level registration.

```bash
pitchfork boot enable
```

```bash
sudo pitchfork boot enable
```

--------------------------------

### Enable Web UI via Environment Variable

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Start the web UI using an environment variable, compatible with both 'run' and 'start' commands.

```bash
PITCHFORK_WEB_PORT=3120 pitchfork supervisor start --force
```

--------------------------------

### Complete Pitchfork Configuration Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

A comprehensive example demonstrating the configuration of various daemons including database, cache, API server, frontend dev server, and scheduled backups. This includes settings for run commands, readiness checks, dependencies, hot reloading, environment variables, and hooks.

```toml
# Database - starts on boot, no auto-stop
[daemons.postgres]
run = "postgres -D /var/lib/pgsql/data"
ready_output = "ready to accept connections"
boot_start = true
retry = 3

# Cache - starts with API
[daemons.redis]
run = "redis-server"
ready_output = "Ready to accept connections"

# API server - depends on database and cache, hot reloads on changes
[daemons.api]
run = "npm run server"
dir = "api"
depends = ["postgres", "redis"]
watch = ["src/**/*.ts", "package.json"]
ready_http = "http://localhost:3000/health"
auto = ["start", "stop"]
retry = 5
port = { expect = [3000], bump = true }
env = { NODE_ENV = "development", PORT = "3000" }
memory_limit = "2GiB"
cpu_limit = 200

[daemons.api.hooks]
on_ready = "curl -X POST https://alerts.example.com/ready"
on_fail = "./scripts/alert-failure.sh"

# Frontend dev server in a subdirectory
[daemons.frontend]
run = "npm run dev"
dir = "frontend"
env = { PORT = "5173" }

# Scheduled backup
[daemons.backup]
run = "./scripts/backup.sh"
cron = { schedule = "0 0 2 * * *", retrigger = "finish" }
```

--------------------------------

### Example Workflow: Auto Daemon Management

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/shell-hook.md

Demonstrates entering a project directory to trigger auto-start and leaving to trigger auto-stop of daemons.

```bash
# Enter your project directory
cd ~/projects/myapp
# api daemon starts automatically

# Work on your code...

# Leave the project
cd ~
# After a delay, api daemon stops (if no other terminals are in ~/projects/myapp)
```

--------------------------------

### on_ready Hook Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Execute a command when the daemon passes its readiness check. This example uses curl to send a POST request to a Slack webhook.

```toml
[daemons.api.hooks]
on_ready = "curl -s -X POST https://slack.example.com/webhook -d '{"text": "API is up"}'"
```

--------------------------------

### Delay Check CLI Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Use the --delay flag to specify a fixed number of seconds to wait after starting the daemon. This is useful for simple services where a time delay is sufficient.

```bash
pitchfork run myapp --delay 5 -- node server.js
pitchfork start myapp --delay 10
```

--------------------------------

### Working Within a Project Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/namespaces.md

Demonstrates the usage of short IDs for managing daemons when the current directory is within the project.

```bash
cd ~/projects/frontend

# Short IDs work here
pitchfork start api
pitchfork logs api
pitchfork stop api
```

--------------------------------

### Start Specific Daemons

Source: https://github.com/endevco/pitchfork/blob/main/docs/first-daemon.md

Start individual daemons by listing their names after the 'pitchfork start' command.

```bash
pitchfork start api redis
```

--------------------------------

### Managing Multiple Projects Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/namespaces.md

Provides a sequence of commands for managing daemons across different projects from various locations.

```bash
# Start services in both projects
cd ~/projects/frontend && pitchfork start api
cd ~/projects/backend && pitchfork start api

# Check status of all daemons
pitchfork list
# Output:
# frontend/api  12345  running
# backend/api   12346  running

# View logs for a specific project's daemon
pitchfork logs frontend/api

# Stop a specific daemon from anywhere
pitchfork stop backend/api
```

--------------------------------

### Example with Chained Daemon Dependencies

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

Illustrates a scenario with multiple levels of daemon dependencies, showing parallel startup of independent services and sequential startup based on dependencies.

```toml
[daemons.database]
run = "postgres -D /var/lib/pgsql/data"
ready_port = 5432

[daemons.cache]
run = "redis-server"
ready_port = 6379

[daemons.api]
run = "npm run server"
depends = ["database", "cache"]

[daemons.worker]
run = "npm run worker"
depends = ["database"]
```

--------------------------------

### Debug Setup: Supervisor and Web UI

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/environment-vars.md

Start the Pitchfork supervisor with debug logging enabled and the web UI accessible on a specific port for a single invocation. View supervisor logs using the 'pitchfork logs pitchfork' command.

```bash
PITCHFORK_LOG=debug PITCHFORK_WEB_PORT=19876 pitchfork supervisor start --force

# View supervisor logs
pitchfork logs pitchfork
```

--------------------------------

### Start Pitchfork Supervisor

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/port-management.md

Start the Pitchfork supervisor. Use sudo if binding to privileged ports like 80 or 443.

```bash
sudo pitchfork supervisor start --force
```

--------------------------------

### Configure Daemons to Start on Boot

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/boot-start.md

Configures specific daemons to start automatically when pitchfork boots. Add this to your global config file.

```toml
[daemons.postgres]
run = "postgres -D /usr/local/var/postgres"
boot_start = true
```

```toml
[daemons.redis]
run = "redis-server"
boot_start = true
```

```toml
[daemons.my-app]
run = "npm start"
boot_start = false  # Won't start at boot
```

--------------------------------

### Enable Web UI via CLI

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Start the web UI for a single session using the CLI flag.

```bash
pitchfork supervisor run --web-port 3120
```

--------------------------------

### Start All Services

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/how-it-works.md

Use this command to initiate all defined services managed by Pitchfork.

```bash
pitchfork start --all
```

--------------------------------

### Start a Daemon

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Initiate the startup process for a specified daemon using a POST request to the API. The response indicates success or failure.

```bash
curl -X POST http://127.0.0.1:3120/api/daemons/myproject/api/start
```

--------------------------------

### Enable Auto-Start and Auto-Stop

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

Configure a daemon to automatically start and stop with shell hooks. Use an array with 'start' and 'stop' options.

```toml
[daemons.api]
run = "npm run server"
auto = ["start", "stop"]  # Both auto-start and auto-stop
```

--------------------------------

### Start MCP Server

Source: https://github.com/endevco/pitchfork/blob/main/docs/cli/mcp.md

This command starts the MCP server. It is typically used as a subprocess by AI assistant tools.

```bash
pitchfork mcp
```

--------------------------------

### POST /api/daemons/{id}/start

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Starts a specified daemon.

```APIDOC
## POST /api/daemons/{id}/start

### Description
Start a daemon.

### Method
POST

### Endpoint
/api/daemons/{id}/start

### Parameters
#### Path Parameters
- **id** (string) - Required - The qualified ID of the daemon to start.

### Response
#### Success Response (200)
- **ok** (boolean) - Indicates if the operation was successful.
- **error** (string or null) - Contains an error message if the operation failed.

### Response Example
{
  "ok": true,
  "error": null
}
```

--------------------------------

### Start Daemon with Slug

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/port-management.md

Start a specific daemon using its registered slug.

```bash
pitchfork start api
```

--------------------------------

### Global Slug Configuration Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/port-management.md

Example of how slugs are mapped to project directories and daemon names in the global Pitchfork configuration.

```toml
[slugs]
api = { dir = "/home/user/my-api", daemon = "server" }
frontend = { dir = "/home/user/my-app", daemon = "dev" }
docs = { dir = "/home/user/docs-site" }
```

--------------------------------

### on_output Full Form with Filter

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Execute a command when the daemon writes a line containing a specific filter string. This example runs a curl command when 'Server started' is detected in the output.

```toml
on_output = { filter = "Server started", run = "curl https://monitor.example.com/up" }
```

--------------------------------

### Multi-Service Setup with Dependencies

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/file-watching.md

Configure multiple services, including a database and two applications, with dependencies and file watching. Ensures services restart correctly when their watched files change.

```toml
[daemons.postgres]
run = "postgres -D /var/lib/pgsql/data"
ready_port = 5432
# No watch - database doesn't need hot reload

[daemons.api]
run = "npm run dev"
depends = ["postgres"]
watch = ["src/**/*.ts", "package.json"]
ready_http = "http://localhost:3000/health"

[daemons.worker]
run = "npm run worker"
depends = ["postgres"]
watch = ["src/worker/**/*.ts", "package.json"]
```

--------------------------------

### Enable Automatic Daemon Startup on Boot

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

Configure a daemon to start automatically when the system boots. Default is false.

```toml
[daemons.postgres]
run = "postgres -D /var/lib/pgsql/data"
boot_start = true
```

--------------------------------

### Hardcoded Configuration Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/configuration-templates.md

This example shows a configuration with hardcoded values, which can lead to issues when ports are dynamically assigned. It highlights the problem that templates aim to solve.

```toml
[daemons.redis]
run = "redis-server"
port = 6379

[daemons.api]
run = "server --port 3000 --redis-port 6379"  # hardcoded!
env = { DATABASE_URL = "redis://localhost:6379/0" }  # hardcoded!
depends = ["redis"]

```

--------------------------------

### Complete Example pitchfork.toml Configuration

Source: https://github.com/endevco/pitchfork/blob/main/README.md

A comprehensive pitchfork.toml example demonstrating configurations for PostgreSQL, Redis, API server, worker processes, and a cron job for data synchronization.

```toml
# pitchfork.toml
[daemons.postgres]
run = "docker run --rm -p 5432:5432 -e POSTGRES_PASSWORD=dev postgres:16"
auto = ["start", "stop"]
ready_delay = 5

[daemons.redis]
run = "redis-server --port 6379"
auto = ["start", "stop"]
ready_delay = 2

[daemons.api]
run = "npm run dev:api"
auto = ["start", "stop"]
ready_output = "listening on"
depends = ["postgres", "redis"]

[daemons.worker]
run = "npm run dev:worker"
auto = ["start"]
depends = ["postgres", "redis"]

[daemons.sync]
run = "rsync -avz --delete remote:/data/ ./local-data/"
cron = { schedule = "0 */5 * * * *" }  # Run every 5 minutes

```

--------------------------------

### Start All Daemons

Source: https://github.com/endevco/pitchfork/blob/main/README.md

Start all daemons defined in the pitchfork.toml configuration file. This command initiates all configured background processes.

```sh
$ pitchfork start --all
```

--------------------------------

### Fish Completion Installation

Source: https://github.com/endevco/pitchfork/blob/main/docs/cli/completion.md

Installs fish completion scripts for Pitchfork. This command should be run once to set up tab completion for fish.

```fish
pitchfork completion fish > ~/.config/fish/completions/pitchfork.fish
```

--------------------------------

### Start Supervisor Fresh

Source: https://github.com/endevco/pitchfork/blob/main/docs/troubleshooting.md

Start the Pitchfork supervisor process after ensuring any existing instances and stale sockets are removed.

```bash
pitchfork supervisor start
```

--------------------------------

### Verify Manual Daemon Start

Source: https://github.com/endevco/pitchfork/blob/main/docs/troubleshooting.md

Check if your daemon command works correctly when run manually from its project directory.

```bash
cd /path/to/project
npm run server  # or whatever your command is
```

--------------------------------

### Install Pitchfork using Cargo

Source: https://github.com/endevco/pitchfork/blob/main/README.md

Install pitchfork directly using the cargo package manager. Ensure you have Rust and Cargo installed.

```sh
$ cargo install pitchfork-cli
```

--------------------------------

### Starting Cron Daemons via CLI

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/scheduling.md

Demonstrates how to start specific cron daemons or all daemons using the Pitchfork CLI. The supervisor manages the execution based on the defined schedules.

```bash
pitchfork start backup
pitchfork start --all
```

--------------------------------

### Configure Auto Start/Stop

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/how-it-works.md

Configure services to automatically start when entering a project directory and stop when leaving. This is tied to directory changes.

```toml
[daemons.api]
run = "npm run server"
auto = ["start", "stop"]
```

--------------------------------

### Verify Pitchfork Installation

Source: https://github.com/endevco/pitchfork/blob/main/docs/installation.md

Check if Pitchfork has been installed correctly by running the version command.

```bash
pitchfork --version
```

--------------------------------

### Enable a Daemon

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Configure a daemon to be startable by sending a POST request to its enable API endpoint. This prepares the daemon for future starts.

```bash
curl -X POST http://127.0.0.1:3120/api/daemons/myproject/api/enable
```

--------------------------------

### Common PostgreSQL Command Readiness Configuration

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Example TOML configuration for PostgreSQL using ready_cmd to check readiness with pg_isready.

```toml
[daemons.postgres]
run = "postgres -D /var/lib/pgsql/data"
ready_cmd = "pg_isready -h localhost"
```

--------------------------------

### Enable Web UI Persistently via Settings

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Configure the web UI to start automatically with the supervisor by adding settings to the configuration file. Requires supervisor restart.

```toml
[settings.web]
auto_start = true    # Start web UI automatically with supervisor
bind_port = 3120     # Default port (default: 3120)
bind_address = "127.0.0.1"  # Default: localhost only
```

--------------------------------

### Templated Configuration Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/configuration-templates.md

This example demonstrates using Tera templates to dynamically reference the port of the Redis daemon. This avoids hardcoding and adapts to dynamically assigned ports.

```toml
[daemons.redis]
run = "redis-server"
port = 6379

[daemons.api]
run = "server --redis-port {{ daemons.redis.port }}"
env = { DATABASE_URL = "redis://localhost:{{ daemons.redis.port }}/0" }
depends = ["redis"]

```

--------------------------------

### Linux Boot Start File Location

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/file-locations.md

The location for the systemd service file on Linux, used for starting pitchfork on boot.

```text
~/.config/systemd/user/pitchfork.service
```

--------------------------------

### Bash Completion Installation

Source: https://github.com/endevco/pitchfork/blob/main/docs/cli/completion.md

Installs bash completion scripts for Pitchfork. This command should be run once to set up tab completion for bash.

```bash
pitchfork completion bash > ~/.local/share/bash-completion/completions/pitchfork
```

--------------------------------

### Common PostgreSQL Readiness Configuration

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Example TOML configuration for PostgreSQL using ready_output to check for the database system readiness message.

```toml
[daemons.postgres]
run = "postgres -D /var/lib/pgsql/data"
ready_output = "database system is ready to accept connections"
```

--------------------------------

### Global Config: Slug Registry Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/file-locations.md

Example of the `[slugs]` section in the global configuration file (`~/.config/pitchfork/config.toml`). This maps reverse proxy slugs to project directories and optional daemon names.

```toml
[slugs]
api = { dir = "/home/user/my-api", daemon = "server" }
docs = { dir = "/home/user/docs-site" }  # daemon defaults to "docs"
```

--------------------------------

### on_fail Hook Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Execute a command when the daemon fails and all retries are exhausted. This example runs a cleanup script.

```toml
[daemons.api.hooks]
on_fail = "./scripts/alert-team.sh"
```

--------------------------------

### POST /api/daemons/{id}/enable

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Enables a daemon, allowing it to be started.

```APIDOC
## POST /api/daemons/{id}/enable

### Description
Enable a daemon so it can be started.

### Method
POST

### Endpoint
/api/daemons/{id}/enable

### Parameters
#### Path Parameters
- **id** (string) - Required - The qualified ID of the daemon to enable.
```

--------------------------------

### macOS Boot Start File Location

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/file-locations.md

The location for the launch agent plist file on macOS, used for starting pitchfork on boot.

```text
~/Library/LaunchAgents/com.pitchfork.agent.plist
```

--------------------------------

### Zsh Completion Installation

Source: https://github.com/endevco/pitchfork/blob/main/docs/cli/completion.md

Installs zsh completion scripts for Pitchfork. This command should be run once to set up tab completion for zsh.

```zsh
pitchfork completion zsh > ~/.zfunc/_pitchfork
```

--------------------------------

### Cron Expression Examples

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/scheduling.md

Provides common examples of cron expressions for various scheduling needs, such as hourly, every 5 minutes, daily, weekly, and weekdays.

```text
- 0 0 * * * *
- 0 */5 * * * *
- 0 0 2 * * *
- 0 0 0 * * 0
- 0 30 9 * * 1-5
```

--------------------------------

### File-based Readiness Command Check Configuration

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Example TOML configuration for a worker service using ready_cmd to check for the existence of a readiness file.

```toml
[daemons.worker]
run = "./start-worker.sh"
ready_cmd = "test -f /tmp/worker.ready"
```

--------------------------------

### Define Daemon Dependencies

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

List other daemon IDs that must be started before this daemon. Dependencies can be in the same or cross-namespace.

```toml
[daemons.api]
run = "npm run server"
depends = ["postgres", "redis"]
```

--------------------------------

### Synchronous Retry Example (Startup Failures)

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/auto-restart.md

Demonstrates pitchfork's synchronous retry behavior during startup. It uses exponential backoff and waits for the daemon to become ready or retries to exhaust.

```bash
$ pitchfork start api
# Daemon fails immediately
# Wait 1 second... retry (attempt 1/3)
# Daemon fails again
# Wait 2 seconds... retry (attempt 2/3)
# Daemon fails again
# Wait 4 seconds... retry (attempt 3/3)
# All retries exhausted
ERROR: daemon api failed with exit code 1
```

--------------------------------

### on_exit Hook Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Execute a command on any daemon termination, including intentional stops, clean exits, or crashes. This example uses docker compose to shut down services.

```toml
[daemons.infra.hooks]
on_exit = "docker compose down --volumes"
```

--------------------------------

### Select File Watcher Backend

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

Choose the backend for file watching. 'auto' prefers native notifications and falls back to polling if setup fails.

```toml
[daemons.api]
run = "npm run dev"
watch = ["src/**/*.ts", "package.json"]
watch_mode = "auto"
```

--------------------------------

### Run a daemon with a command

Source: https://github.com/endevco/pitchfork/blob/main/docs/cli/run.md

Runs a command as a daemon named 'api'. This is a basic usage example.

```bash
pitchfork run api -- npm run dev
```

--------------------------------

### on_retry Hook Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Execute a command before each retry attempt. This example logs the retry attempt count using the PITCHFORK_RETRY_COUNT environment variable.

```toml
[daemons.api.hooks]
on_retry = "echo 'Retrying api (attempt $PITCHFORK_RETRY_COUNT)...'"
```

--------------------------------

### Full Stack App Configuration

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/mise-integration.md

Example configuration for a full-stack application using Pitchfork daemons and Mise tasks for both backend API and frontend development.

```toml
# pitchfork.toml:
[daemons.api]
run = "mise run api:dev"
auto = ["start", "stop"]
ready_http = "http://localhost:3000/health"

[daemons.frontend]
run = "mise run frontend:dev"
auto = ["start", "stop"]
ready_output = "ready in"

# mise.toml:
[tools]
node = "20"
python = "3.11"

[env]
DATABASE_URL = "postgres://localhost/myapp"

[tasks."api:setup"]
run = "pip install -r requirements.txt"

[tasks."api:dev"]
run = "uvicorn main:app --reload"
depends = ["api:setup"]

[tasks."frontend:setup"]
run = "npm install"

[tasks."frontend:dev"]
run = "npm run dev"
depends = ["frontend:setup"]
```

--------------------------------

### Proxy URL Template Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/configuration-templates.md

Demonstrates using the 'proxy_url' template variable to dynamically insert the proxy's URL for a daemon that has a registered slug.

```toml
[daemons.api]
run = "echo {{ proxy_url }}"
# Renders to: "echo https://myapi.localhost"

```

--------------------------------

### Common Redis Command Readiness Configuration

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Example TOML configuration for Redis using ready_cmd to check readiness with redis-cli ping.

```toml
[daemons.redis]
run = "redis-server"
ready_cmd = "redis-cli ping"
```

--------------------------------

### Basic TOML Configuration

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

Example of a basic TOML configuration file for Pitchfork, including an optional per-file namespace override.

```toml
namespace = "my-project" # optional, per-file namespace override

[daemons.<daemon-name>]
run = "command to execute"
# ... other options
```

--------------------------------

### Port Check Configuration Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Configure the ready_port in the TOML file to specify the TCP port the daemon should listen on for readiness. The check polls by attempting a TCP connection to 127.0.0.1:port.

```toml
[daemons.api]
run = "node server.js"
ready_port = 3000

[daemons.database]
run = "postgres -D /var/lib/pgsql/data"
ready_port = 5432
```

--------------------------------

### Delay Check Configuration Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Configure the ready_delay in the TOML file to set a fixed wait time for the daemon to be considered ready. The CLI default is 3 seconds.

```toml
[daemons.myapp]
run = "node server.js"
ready_delay = 5  # Wait 5 seconds (CLI default: 3)
```

--------------------------------

### on_output Shorthand Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Execute a command when the daemon writes a line to stdout or stderr that matches an optional pattern. This shorthand version runs a script on every line of output.

```toml
on_output = "./scripts/log-activity.sh"
```

--------------------------------

### Delay daemon readiness check

Source: https://github.com/endevco/pitchfork/blob/main/docs/cli/run.md

Waits for 5 seconds before considering the daemon ready after starting. Use the `-d` or `--delay` flag.

```bash
pitchfork run api -d 5 -- ./server
```

--------------------------------

### Example pitchfork.toml for Container Use

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/container-mode.md

A typical TOML configuration file for Pitchfork when used in a containerized environment, including daemon definitions.

```toml
[settings.supervisor]
container = true

[daemons.api]
run = "node server.js"
ready_http = "http://localhost:3000/health"
retry = true

[daemons.worker]
run = "python worker.py"
depends = ["api"]
retry = true
```

--------------------------------

### on_output Full Form with Regex

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Execute a command when the daemon writes a line matching a regular expression. This example runs a script when a line indicating the server is listening on a port is detected.

```toml
on_output = { regex = "listening on port [0-9]+", run = "./scripts/register-port.sh" }
```

--------------------------------

### Disable Pitchfork Boot Start

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/boot-start.md

Disables pitchfork from starting automatically on boot.

```bash
pitchfork boot disable
```

--------------------------------

### Common Node.js HTTP Readiness Configuration

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Example TOML configuration for a Node.js application using ready_http to check a health endpoint.

```toml
[daemons.api]
run = "npm run start"
ready_http = "http://localhost:3000/health"
```

--------------------------------

### Output Check Configuration Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Configure the ready_output in the TOML file to specify a pattern that, when matched in the daemon's output, indicates readiness. This is best for services that print a specific message when ready.

```toml
[daemons.database]
run = "postgres -D /var/lib/pgsql/data"
ready_output = "database system is ready to accept connections"

[daemons.webserver]
run = "python -m http.server 8080"
ready_output = "Serving HTTP on"
```

--------------------------------

### Enable Debug Logging

Source: https://github.com/endevco/pitchfork/blob/main/docs/troubleshooting.md

Enable debug logging to get more detailed logs for diagnosing issues. Use 'trace' for even more detail.

```bash
PITCHFORK_LOG=debug pitchfork supervisor start --force
pitchfork logs pitchfork
```

```bash
PITCHFORK_LOG=trace pitchfork supervisor start --force
```

--------------------------------

### Get Process Tree

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Get the process tree for a daemon, including all child processes.

```APIDOC
## GET /api/processes/{id}/tree

### Description
Get the process tree for a daemon, including all child processes.

### Method
GET

### Endpoint
/api/processes/{id}/tree

### Parameters
#### Path Parameters
- **id** (string) - Required - The ID of the daemon.

### Response
#### Success Response (200)
- **pid** (integer) - The process ID.
- **name** (string) - The name of the process.
- **cmdline** (string) - The command line used to start the process.
- **children** (array) - An array of child process objects.

### Response Example
```json
[
  {
    "pid": 12345,
    "name": "node",
    "cmdline": "node server.js",
    "children": [
      {
        "pid": 12346,
        "name": "node",
        "cmdline": "node worker.js",
        "children": []
      }
    ]
  }
]
```
```

--------------------------------

### Interactive Testing with JSON-RPC

Source: https://github.com/endevco/pitchfork/blob/main/docs/cli/mcp.md

This example demonstrates how to interact with the pitchfork MCP server using JSON-RPC over stdin/stdout for testing purposes. It sends an 'initialize' request and pipes it to the 'pitchfork mcp' command.

```bash
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}' | pitchfork mcp
```

--------------------------------

### Listing Daemons and Proxy URLs

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/port-management.md

Example CLI output from `pitchfork list` showing registered daemons, their status, and associated proxy URLs.

```bash
$ pitchfork list
Name   PID    Status   Proxy URL
api    12345  running  https://api.localhost
```

--------------------------------

### Add daemon with auto start/stop hooks

Source: https://github.com/endevco/pitchfork/blob/main/docs/cli/config/add.md

Use this snippet to add a daemon with automatic start and stop hooks based on directory entry/exit.

```bash
pitchfork config add api --run 'npm start' --autostart --autostop
```

--------------------------------

### Viewing Proxy URL for a Daemon

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/port-management.md

Example CLI output showing the proxy URL assigned to a running daemon. This is displayed when the proxy is enabled and the daemon has a registered slug.

```bash
$ pitchfork start api
Daemon 'myproject/api' started on port(s): 3000
  → Proxy: https://api.localhost
```

--------------------------------

### Internal Path Encoding Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/namespaces.md

Demonstrates how Pitchfork internally converts qualified daemon IDs into filesystem-safe paths for logs and other resources.

```text
| Daemon ID | Log Directory | Log File |
|-----------|---------------|----------|
| `frontend/api` | `logs/frontend--api/` | `frontend--api.log` |
| `my-project/web-server` | `logs/my-project--web-server/` | `my-project--web-server.log` |
| `global/postgres` | `logs/global--postgres/` | `global--postgres.log` |
```

--------------------------------

### Define Daemons in pitchfork.toml

Source: https://github.com/endevco/pitchfork/blob/main/README.md

Configure daemons in a pitchfork.toml file using TOML format. This example defines configurations for redis, api, and docs daemons.

```toml
[daemons.redis]
run = "redis-server"

[daemons.api]
run = "npm run server:api"

[daemons.docs]
run = "npm run server:docs"

```

--------------------------------

### File Watching with Auto Start/Stop

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/file-watching.md

Integrate file watching with shell hooks for automated development workflow management. The daemon automatically starts when entering the directory and restarts on file changes.

```toml
[daemons.api]
run = "npm run dev"
watch = ["src/**/*.ts"]
auto = ["start", "stop"]  # Auto-start when entering directory
```

--------------------------------

### Pitchfork Daemon State Persistence Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/architecture.md

Shows the structure of the TOML file used to store persistent state for managed daemons, including PID, status, and configuration.

```toml
[daemons.myapp]
id = "myapp"
pid = 12345
status = "running"
dir = "/path/to/project"
autostop = true
retry = 2
retry_count = 0

[disabled]
# Set of disabled daemon IDs

[shell_dirs]
# Map of shell_pid → working_directory
```

--------------------------------

### Enable Web UI via Environment Variables (Persistent)

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Set environment variables to enable the web UI persistently. Requires supervisor restart.

```bash
export PITCHFORK_WEB_AUTO_START=true
export PITCHFORK_WEB_BIND_PORT=3120
```

--------------------------------

### Start Specific Daemons

Source: https://github.com/endevco/pitchfork/blob/main/README.md

Start only the specified daemons (e.g., redis and api) from the pitchfork.toml configuration. This allows for selective daemon management.

```sh
$ pitchfork start redis api
```

--------------------------------

### on_stop Hook Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Execute a command when the daemon is explicitly stopped by pitchfork. This example runs a script to notify that the daemon has stopped.

```toml
[daemons.api.hooks]
on_stop = "./scripts/notify-stopped.sh"
```

--------------------------------

### Multiple Ports and Template References

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/configuration-templates.md

Demonstrates how to define multiple ports for a service and reference them individually using templates in another service's configuration.

```toml
[daemons.grpc]
run = "grpc-server"
port = [50051, 50052]

[daemons.gateway]
run = "gateway --grpc-port {{ daemons.grpc.ports[0] }} --metrics-port {{ daemons.grpc.ports[1] }}"
depends = ["grpc"]
```

--------------------------------

### Start Supervisor on Privileged Port (HTTPS)

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/port-management.md

Start the Pitchfork supervisor binding to port 443 (HTTPS) using sudo. This is the default behavior.

```bash
sudo pitchfork supervisor start
```

--------------------------------

### Start Supervisor on Privileged Port (HTTP)

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/port-management.md

Start the Pitchfork supervisor binding to port 80 (HTTP) using sudo and disabling HTTPS.

```bash
sudo PITCHFORK_PROXY_PORT=80 PITCHFORK_PROXY_HTTPS=false pitchfork supervisor start
```

--------------------------------

### Command Check Configuration Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Configure the ready_cmd in the TOML file to specify a shell command that must return exit code 0 for the daemon to be considered ready. This check polls every 500ms.

```toml
[daemons.api]
run = "node server.js"
ready_cmd = "curl -sf http://localhost:3000/health"

[daemons.database]
run = "postgres -D /var/lib/pgsql/data"
ready_cmd = "pg_isready -h localhost"
```

--------------------------------

### Verify Shell Hook Installation

Source: https://github.com/endevco/pitchfork/blob/main/docs/troubleshooting.md

Ensure the Pitchfork shell hook is correctly installed in your shell configuration file (e.g., ~/.zshrc for zsh).

```bash
# For zsh, check ~/.zshrc contains:
eval "$(pitchfork activate zsh)"
```

--------------------------------

### Use Ready Output Pattern

Source: https://github.com/endevco/pitchfork/blob/main/docs/troubleshooting.md

Configure the 'ready_output' pattern to wait for a specific string in the daemon's output, indicating it's ready.

```toml
[daemons.api]
ready_output = "listening on"  # Wait for specific output
```

--------------------------------

### Process Tree Response Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Example JSON response structure for the process tree API endpoint, showing process details and their children.

```json
[
  {
    "pid": 12345,
    "name": "node",
    "cmdline": "node server.js",
    "children": [
      {
        "pid": 12346,
        "name": "node",
        "cmdline": "node worker.js",
        "children": []
      }
    ]
  }
]
```

--------------------------------

### Using Qualified IDs from Anywhere

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/namespaces.md

Illustrates how to manage daemons using their fully qualified IDs, regardless of the current directory.

```bash
# From anywhere
pitchfork start frontend/api
pitchfork status backend/api
pitchfork logs frontend/api
```

--------------------------------

### Parse Port from Output and Register

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Parse a port number from the daemon's startup output using a regex and then register it. This uses 'on_output' with a 'regex' to capture the port.

```toml
[daemons.api]
run = "node server.js"

[daemons.api.hooks]
on_output = { regex = "listening on port [0-9]+", run = "sh -c 'echo "$PITCHFORK_MATCHED_LINE" | grep -o "[0-9]*$" | xargs register-port'" }
```

--------------------------------

### GET /api/stats

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Retrieves system-level statistics from the Pitchfork supervisor.

```APIDOC
## GET /api/stats

### Description
Return system-level statistics.

### Method
GET

### Endpoint
/api/stats

### Response
#### Success Response (200)
- **process_count** (integer) - The total number of running processes.
- **cpu_count** (integer) - The number of available CPU cores.
- **total_memory** (integer) - The total system memory in bytes.

### Response Example
{
  "process_count": 42,
  "cpu_count": 8,
  "total_memory": 17179869184
}
```

--------------------------------

### Database Configuration with Startup Retries

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/auto-restart.md

Configuration for a database service that requires multiple startup attempts and checks for a specific output string to confirm readiness.

```toml
[daemons.postgres]
run = "postgres -D /var/lib/pgsql/data"
retry = 3
ready_output = "ready to accept connections"
```

--------------------------------

### Go Service Configuration

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/file-watching.md

Configure a Go service to restart on changes to Go source files, go.mod, and go.sum. Uses a port-based ready check.

```toml
[daemons.server]
run = "go run ./cmd/server"
watch = ["**/*.go", "go.mod", "go.sum"]
ready_port = 8080
```

--------------------------------

### GET /api/daemons

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Lists all daemons managed by the supervisor, including their runtime state.

```APIDOC
## GET /api/daemons

### Description
List all daemons with full runtime state.

### Method
GET

### Endpoint
/api/daemons

### Response
#### Success Response (200)
- **id** (object) - The unique identifier for the daemon.
  - **namespace** (string)
  - **name** (string)
  - **qualified** (string)
  - **safe_path** (string)
- **title** (string) - A human-readable title for the daemon.
- **pid** (integer) - The process ID of the daemon.
- **status** (object) - The current status of the daemon.
  - **type** (string) - The type of status (e.g., "running").
- **dir** (string) - The working directory of the daemon.
- **cpu_percent** (number) - The current CPU utilization percentage.
- **memory_bytes** (integer) - The current memory usage in bytes.
- **uptime_secs** (integer) - The uptime of the daemon in seconds.
- **proxy_url** (string) - The configured proxy URL for the daemon.
- **slug** (string) - A URL-friendly identifier for the daemon.
- **active_port** (integer) - The active port the daemon is listening on.
- **resolved_port** (array of integers) - A list of resolved ports for the daemon.

### Response Example
[
  {
    "id": {
      "namespace": "myproject",
      "name": "api",
      "qualified": "myproject/api",
      "safe_path": "myproject--api"
    },
    "title": "API Server",
    "pid": 12345,
    "status": { "type": "running" },
    "dir": "/home/user/myproject",
    "cpu_percent": 2.3,
    "memory_bytes": 67108864,
    "uptime_secs": 3600,
    "proxy_url": "https://api.localhost",
    "slug": "api",
    "active_port": 3000,
    "resolved_port": [3000]
  }
]
```

--------------------------------

### Daemon Configuration with Hooks

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/lifecycle-hooks.md

Configure various lifecycle hooks for a daemon, including commands to run on ready, fail, retry, stop, exit, and when specific output is detected.

```toml
[daemons.api]
run = "npm run server"
retry = 3
ready_http = "http://localhost:3000/health"

[daemons.api.hooks]
on_ready = "curl -X POST https://alerts.example.com/ready"
on_fail = "./scripts/cleanup.sh"
on_retry = "echo 'retrying api server...'
on_stop = "./scripts/notify-stopped.sh"
on_exit = "./scripts/cleanup.sh"
on_output = { filter = "Server started", run = "./scripts/notify-ready.sh" }
```

--------------------------------

### GET /api/daemons/{id}

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Retrieves detailed information for a specific daemon identified by its qualified ID.

```APIDOC
## GET /api/daemons/{id}

### Description
Get a single daemon by qualified ID.

### Method
GET

### Endpoint
/api/daemons/{id}

### Parameters
#### Path Parameters
- **id** (string) - Required - The qualified ID of the daemon (e.g., "myproject/api").

### Response
#### Success Response (200)
Returns a single `ApiDaemonEntry` object (same shape as `/api/daemons` items).
```

--------------------------------

### Set Daemon Ready Delay

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

Specify the number of seconds to wait before considering a daemon ready after startup. Defaults to 3 seconds if no other readiness check is configured.

```toml
[daemons.api]
run = "npm run server"
ready_delay = 5
```

--------------------------------

### Output Check CLI Example

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/ready-checks.md

Use the --output flag with a regular expression to wait until a specific pattern appears in the daemon's output. This is suitable for services that print a distinct message when ready.

```bash
pitchfork run myapp --output "Server listening" -- node server.js
pitchfork start myapp --output "ready to accept connections"
```

--------------------------------

### Check Pitchfork Boot Status

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/boot-start.md

Checks the current status of pitchfork's boot start configuration.

```bash
pitchfork boot status
```

--------------------------------

### Increase Ready Delay

Source: https://github.com/endevco/pitchfork/blob/main/docs/troubleshooting.md

Increase the 'ready_delay' in the daemon configuration to give your daemon more time to become ready after starting.

```toml
[daemons.api]
ready_delay = 30  # Give more time
```

--------------------------------

### Using Short IDs within a Project

Source: https://github.com/endevco/pitchfork/blob/main/docs/concepts/namespaces.md

Shows how to manage daemons using their short IDs when operating from within the project's directory.

```bash
cd ~/projects/frontend
pitchfork start api        # Starts frontend/api
pitchfork status api       # Shows status of frontend/api
pitchfork logs api         # Shows logs for frontend/api
```

--------------------------------

### Launch TUI Dashboard

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/tui.md

Launches the Pitchfork Terminal UI. The TUI automatically connects to the supervisor, starting it if necessary.

```bash
pitchfork tui
```

--------------------------------

### Add daemon with dependency

Source: https://github.com/endevco/pitchfork/blob/main/docs/cli/config/add.md

Use this snippet to add a daemon that has a dependency on another daemon, ensuring it starts after the dependency.

```bash
pitchfork config add worker --run './worker' --depends api
```

--------------------------------

### Restart a Daemon

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Restart a daemon by sending a POST request to its restart API endpoint. This action will stop and then start the daemon.

```bash
curl -X POST http://127.0.0.1:3120/api/daemons/myproject/api/restart
```

--------------------------------

### Basic Cron Daemon Configuration (Full Form)

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/scheduling.md

Configure a daemon with a cron schedule and specify the 'retrigger' mode using the full inline table format.

```toml
[daemons.backup]
run = "./scripts/backup.sh"
cron = { schedule = "0 0 2 * * *", retrigger = "finish" }
```

--------------------------------

### Run a One-Off Daemon

Source: https://github.com/endevco/pitchfork/blob/main/README.md

Execute a process in the background as an alternative to shell background jobs. Useful for starting development servers.

```sh
$ pitchfork run docs -- npm start docs-dev-server
```

--------------------------------

### Install Shell Hook for Fish

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/shell-hook.md

Add the Pitchfork shell hook to your `config.fish` file to enable automatic daemon management.

```bash
echo 'pitchfork activate fish | source' >> ~/.config/fish/config.fish
```

--------------------------------

### Install Shell Hook for Zsh

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/shell-hook.md

Add the Pitchfork shell hook to your `.zshrc` file to enable automatic daemon management.

```bash
echo 'eval "$(pitchfork activate zsh)"' >> ~/.zshrc
```

--------------------------------

### Install Shell Hook for Bash

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/shell-hook.md

Add the Pitchfork shell hook to your `.bashrc` file to enable automatic daemon management.

```bash
echo 'eval "$(pitchfork activate bash)"' >> ~/.bashrc
```

--------------------------------

### Render CLI Documentation

Source: https://github.com/endevco/pitchfork/blob/main/AGENTS.md

Renders the command-line interface documentation. This is included in the `ci-dev` command.

```bash
# Render CLI docs. It's already included in `ci-dev`
mise run render
```

--------------------------------

### Define Daemon Readiness by Shell Command

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

Use a shell command to check for readiness. The daemon is ready when the command exits with a status code of 0.

```toml
[daemons.postgres]
run = "postgres -D /var/lib/pgsql/data"
ready_cmd = "pg_isready -h localhost"

[daemons.redis]
run = "redis-server"
ready_cmd = "redis-cli ping"
```

--------------------------------

### Get System Statistics

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Retrieve system-level statistics from the API. This endpoint provides information about process count, CPU, and memory.

```bash
curl http://127.0.0.1:3120/api/stats
```

--------------------------------

### Define Daemon Readiness by Output Regex

Source: https://github.com/endevco/pitchfork/blob/main/docs/reference/configuration.md

Use a regular expression to match specific output from the daemon to determine readiness. This is useful for services that log a readiness message.

```toml
[daemons.postgres]
run = "postgres -D /var/lib/pgsql/data"
ready_output = "ready to accept connections"
```

--------------------------------

### Disable a Daemon

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/web-ui.md

Prevent a daemon from being started by sending a POST request to its disable API endpoint. This action marks the daemon as not startable.

```bash
curl -X POST http://127.0.0.1:3120/api/daemons/myproject/api/disable
```

--------------------------------

### Auto-Bumped Port with Template Reference

Source: https://github.com/endevco/pitchfork/blob/main/docs/guides/configuration-templates.md

Shows how to configure a port with auto-bumping and use a template to reference the resolved port, ensuring the correct port is always used.

```toml
[daemons.redis]
run = "redis-server"
port = { expect = [6379], bump = 10 }
# If 6379 is occupied, redis starts on 6380, 6390, etc.

[daemons.api]
run = "server --redis-port {{ daemons.redis.port }}"
# Always uses the actual port, regardless of bumping
depends = ["redis"]
```