Daemon Management
Define and maintain the set of daemon programs on a container. Create new programs, update their command and environment, list every configured daemon, and remove entries that are no longer needed.
Hoody Daemon
Section titled “Hoody Daemon”The Hoody Daemon service provides API access to background process management, enabling you to programmatically define, control, and monitor long-running programs across your Hoody environment. Program definitions persist. Whether a program starts on its own depends on enabled, boot and lazy_load, and new programs default to enabled: true and boot: false; whether it restarts follows autorestart, which defaults to "unexpected". Every program exposes its status for observability.
Use the Daemon API when you need to:
- Register a new background service (for example, a worker, scheduler, or sidecar proxy) and keep its configuration in sync with your application code.
- Toggle a program between enabled and disabled states, or trigger an immediate start or stop outside the normal lifecycle.
- Poll program status, retrieve uptime metrics, and inspect recent log output for operational dashboards and alerting.
The Daemon API is split into three logical groups:
Program Control
Drive runtime state changes for a daemon program. Enable or disable a program to decide whether it may run, and start or stop it explicitly. A disabled program must be enabled before it can start.
Status & Monitoring
Inspect what a program is doing right now. Retrieve live status, process identifiers, and recent log lines to power dashboards, health checks, and incident response.
All Daemon API operations are scoped to a specific container, and you reach them through that container’s published hostname.
The daemon itself does not verify tokens and knows nothing about projects. Every request, the health probe included, passes the Source IP Guard: Hoody Kit programs are reached through their URLs only. Access control on the published hostname is the proxy’s job, not the daemon’s, so never expose a daemon port directly.
Responses are endpoint-specific rather than a single envelope. Listing programs returns { "programs": [ ... ] }. Most operations return an object with success plus fields for that operation, and a controller failure returns { "success": false, "error": "..." }. Health returns its own object. Errors raised before a handler runs, by a request extractor or by the middleware, can be plain text rather than JSON. The add and edit bodies are parsed by their handlers, so their parse errors carry the JSON envelope.
Besides these operations the daemon serves two utility routes: GET / (service metadata) and GET /ui (a 302 redirect to /index.html). Quick-start programs are managed on the Daemon Management page. There is no HTTP endpoint for event streams; per-program webhooks are configured through add and edit.