Hoody Daemon

The Hoody Daemon is an in-container Kit service that acts as a local program supervisor built on supervisord. It manages user-registered daemon programs (long-running services you want kept alive) and ephemeral quick-start programs (short-lived custom commands). The daemon runs inside each container and is reached through the Hoody Proxy — it is not a standalone control-plane endpoint and has no agent, container-management, or workspace concerns of its own.

Use the daemon API when you need to register a custom program with the supervisor, start or stop a registered program, inspect its status or logs, or launch and manage a short-lived ephemeral program. Agents, containers, and other platform resources live under their own namespaces and are not exposed here.

Base URL

The daemon is not exposed on the management API host. All endpoints are served by the container’s daemon process through the Hoody Proxy using the container URL template:

https://{projectId}-{containerId}-daemon-1.{server}.containers.hoody.com

Append the daemon endpoint path under /api/v1/daemon/... to the container URL. For example, to read daemon status the request URL is https://{projectId}-{containerId}-daemon-1.{server}.containers.hoody.com/api/v1/daemon/status.

Note

Keep {projectId} and {containerId} as literal placeholders when constructing URLs. A real project ID and container ID are each exactly 24 lowercase hexadecimal characters, for example 67e89abc123def456789abcd-890abcdef12345678901cdef.

Authentication

The daemon itself does not authenticate requests. The container URL itself is the credential — the Hoody Proxy in front of the daemon authenticates the caller and authorizes the request against the target container. When the proxy is configured to require a bearer credential, attach it to outgoing requests as a standard Authorization header:

Authorization: Bearer <token>

Otherwise, send no Authorization header; the proxy will accept the connection based on the resolved container. The daemon never mints, issues, or validates its own per-launch or locally-issued tokens.

Tip

The /api/v1/daemon/health endpoint is unauthenticated and always returns HTTP 200 when the daemon process is up. It is the recommended probe for liveness checks because it does not require a credential.

Capability groups

The daemon API is organized into four functional groups plus a health probe:

• Programs — register, retrieve, list, edit, and remove custom daemon programs that the supervisor should keep running.
• Control — enable, disable, start, and stop an individual registered program by ID.
• Status and monitoring — read aggregated supervisor status, the status of a single program, and stream a program’s logs.
• Quick-start — launch an ephemeral short-lived program, poll its status, read its logs, and stop it.
• Health — a standardized nine-field health response used for liveness probes.

Program management

List, add, get, edit, remove, and reset custom daemon programs registered with supervisord.

Open the reference →

Program control

Enable, disable, start, and stop a single registered program by ID.

Open the reference →

Status and monitoring

Read aggregated daemon status, per-program status, and stream program logs.

Open the reference →

Endpoint layout

Endpoints are grouped by resource and live under the following top-level paths on the daemon base URL:

Group	Path prefix
Programs	/api/v1/daemon/programs
Program control	/api/v1/daemon/programs/{id}/{enable|disable|start|stop}
Status and monitoring	/api/v1/daemon/status and /api/v1/daemon/programs/{id}/logs
Quick-start	/api/v1/daemon/quick-start and /api/v1/daemon/quick-start/{id}/{status|logs|stop}
Health	/api/v1/daemon/health

The next pages in this section document each group’s operations, parameters, and response shapes in full.