Skip to main content

Daemon Management

The OpenFang daemon is the core service that runs the kernel, manages agents, and provides the HTTP API and web dashboard.

Starting the Daemon

openfang start

Start the OpenFang daemon (kernel + API server).
Options: Behavior:
  1. Checks if a daemon is already running; exits with an error if so
  2. Boots the OpenFang kernel:
    • Loads configuration from ~/.openfang/config.toml
    • Initializes SQLite database
    • Loads persisted agents
    • Connects to configured MCP servers
    • Starts background tasks
  3. Starts the HTTP API server on the configured address (default: 127.0.0.1:4200)
  4. Writes daemon.json to ~/.openfang/ for daemon discovery
  5. Blocks until interrupted with Ctrl+C
Example Output:
The daemon runs in the foreground by default. For background operation, use a process manager like systemd, pm2, or run in a screen/tmux session.

Starting with Custom Config

Docker Configuration

When running in Docker, bind to 0.0.0.0 to allow external connections:
Or use the environment variable:

Stopping the Daemon

openfang stop

Stop the running daemon gracefully.
Behavior:
  1. Reads daemon.json to locate the daemon
  2. Sends POST /api/shutdown to the daemon
  3. Waits up to 5 seconds for graceful shutdown
  4. If daemon doesn’t stop, force-kills via PID
  5. Removes daemon.json
Example Output:
If the daemon doesn’t respond within 5 seconds, it will be force-killed using kill -9 (Unix) or taskkill /F (Windows).

Stopping from the Same Terminal

If you started the daemon in the foreground, simply press Ctrl+C:

Checking Daemon Status

openfang status

Show the current kernel/daemon status.
Options: Behavior:
  • If daemon is running: Queries GET /api/status and displays:
    • Agent count
    • Provider and model
    • Uptime
    • API URL
    • Data directory
    • List of active agents
  • If no daemon is running: Boots an in-process kernel and shows persisted state with a warning
Example Output (Daemon Running):
Example Output (No Daemon):

JSON Output

Scripting with JSON:

Health Checks

openfang health

Quick daemon health check.
Example Output:
JSON Output:
openfang health performs a lightweight check (just the HTTP health endpoint), while openfang status provides comprehensive system information.

Diagnostic Checks

openfang doctor

Run comprehensive diagnostic checks on the OpenFang installation.
Options: Checks Performed:
  1. OpenFang directory - ~/.openfang/ exists
  2. .env file - exists and has correct permissions (0600 on Unix)
  3. Config TOML syntax - config.toml parses without errors
  4. Daemon status - whether a daemon is running
  5. Port availability - if daemon is not running, checks if port 4200 is free
  6. Stale daemon.json - leftover file from a crashed daemon
  7. Database file - SQLite magic bytes validation
  8. Disk space - warns if less than 100MB available (Unix only)
  9. Agent manifests - validates all .toml files in ~/.openfang/agents/
  10. LLM provider keys - checks env vars for all providers, performs live validation
  11. Channel tokens - format validation for Telegram, Discord, Slack tokens
  12. Config consistency - checks that api_key_env references match actual env vars
  13. Rust toolchain - rustc --version
Example Output:

Auto-Repair Mode

--repair mode will prompt before making any changes. It can create missing directories, remove stale files, and fix file permissions.

Gateway Commands

The gateway subcommand provides an alternative interface to daemon management:

Dashboard Access

openfang dashboard

Open the web dashboard in the default browser.
Behavior:
  1. Requires a running daemon
  2. Opens the daemon URL (e.g. http://127.0.0.1:4200/) in the system browser
  3. Copies the URL to the system clipboard
Example Output:
The dashboard is an Alpine.js single-page application served directly by the daemon.

Daemon Auto-Detection Details

The CLI uses a two-step mechanism to detect a running daemon:

Step 1: Read daemon.json

On startup, the daemon writes ~/.openfang/daemon.json:
The CLI reads this file to discover the daemon’s listen address.

Step 2: Health Check

The CLI sends GET http://<listen_addr>/api/health with a 2-second timeout:
If the health check succeeds, the daemon is considered running.

Fallback to In-Process Mode

If either step fails (no daemon.json, stale file, health check timeout), the CLI falls back to in-process mode for commands that support it. Commands that require a daemon:
  • workflow commands
  • trigger commands
  • channel test/enable/disable
  • dashboard
These will exit with an error and a helpful message if no daemon is found.

Troubleshooting

Daemon Won’t Start

Port Already in Use:
Solutions:
  • Kill the process using port 4200
  • Change the port in config.toml: api_listen = "127.0.0.1:4201"
Database Locked:
Solutions:
  • Check for other OpenFang processes: ps aux | grep openfang
  • Remove stale lock: rm ~/.openfang/data/openfang.db-shm
Config Parse Error:
Solutions:
  • Validate TOML syntax with openfang doctor
  • Restore default config: rm ~/.openfang/config.toml && openfang init --quick

Daemon Won’t Stop

This happens when the daemon is unresponsive. The CLI will automatically force-kill it.

Stale daemon.json

If the daemon crashes, daemon.json may be left behind:

Production Deployment

Systemd Service (Linux)

Create /etc/systemd/system/openfang.service:
Enable and start:

Docker Compose

PM2 (Node.js Process Manager)

Next Steps

Agent Commands

Learn how to create and manage agents

Configuration

Configure providers, models, and channels