Daeva — GPU Pod Orchestrator

Daeva routes AI inference jobs (transcription, image generation, OCR, vision) to GPU-backed pods via a REST API and optional MCP server. It handles pod lifecycle, exclusivity groups (automatic GPU contention resolution), and portable pod packages. Daeva can run on the same machine as the agent or on a remote host — the default is localhost, but this is just a fallback.

Resolving the Daeva Base URL

Daeva can run locally or on a remote host. Resolve the base URL using these steps in order:

1. Check environment variables. If DAEVA_URL is set, use it as the full base URL (e.g. http://server.local:8787). If only DAEVA_PORT is set, use http://127.0.0.1:$DAEVA_PORT.
2. Try the default. If neither variable is set, use http://127.0.0.1:8787.
3. Verify with a health check. Hit /health on the resolved URL. If it returns {"ok":true}, proceed.
4. If the health check fails and no env vars were set, ask the user where Daeva is hosted before continuing. Do not guess or retry blindly.

# Resolve base URL from environment, falling back to localhost default
DAEVA_BASE="${DAEVA_URL:-http://127.0.0.1:${DAEVA_PORT:-8787}}"

# Verify the service is reachable
curl -sf "$DAEVA_BASE/health"
# Expected: {"ok":true}

If the service is local and not running, start it:

# Foreground
daeva
# Or: PORT=8787 node dist/src/cli.js

# systemd
systemctl --user start daeva

All endpoints below use $DAEVA_BASE as the base URL. When constructing curl commands, MCP config, or downstream skill URLs, always substitute the resolved value — never hardcode 127.0.0.1 unless the agent is running on the same host as Daeva.

Important: Behavioral Rules

Daeva is a shared service. It is not per-user or per-session. Multiple agents and users may share the same Daeva instance. Treat it like shared infrastructure — don't make assumptions about what's running or why.

Use lifecycle endpoints for pod management. To wake, switch, or stop pods, use the dedicated lifecycle endpoints (/pods/:podId/activate, /pods/:podId/stop, /pods/swap). Never enqueue a dummy or throwaway job just to force a pod swap — that pollutes the job queue and may produce unwanted side effects on a shared service.

Route workload traffic through Daeva's proxy, not raw container ports. When Daeva is installed, downstream skills and clients (e.g. a ComfyUI skill, a Whisper client) should send requests through Daeva's proxy at $DAEVA_BASE/proxy/<podId> — not directly to the pod's container port. For example, if ComfyUI is managed by Daeva, the ComfyUI skill should hit $DAEVA_BASE/proxy/comfyapi instead of http://localhost:8188. This ensures Daeva can handle pod activation, exclusivity switching, and routing transparently. Only bypass the proxy if Daeva is confirmed to not be managing that pod.

Capabilities and Job Types