Daemion docs

How do I manage apps through the API?

Auth: Bearer token from device pairing
Base URL: http://localhost:3001
All examples tested against live gateway

Apps are extensions of type app stored in ~/.daemion/apps/<name>/. Apps are Vite projects — not raw HTML files. Two subtypes (fullstack and interactive) run a Vite dev server managed by the gateway. The runtime API lets you start, stop, restart, and check status on those dev servers, and access the running app through a built-in dev proxy.


How do I check an app’s runtime status?

GET /apps/:name/status Auth required

Return the current runtime state for a named app.

bash
Verified

curl “http://localhost:3001/apps/my-dashboard/status
-H “Authorization: Bearer $DAEMION_TOKEN”

Response shape:

json

{ “status”: “running”, “port”: 5173, “pid”: 84201, “subtype”: “interactive” }

Possible status values: running, stopped, crashed, starting. port and pid are null when not running.


How do I start an app’s dev server?

POST /apps/:name/start Auth required

Start the Vite dev server for an app. Only works for fullstack and interactive subtypes.

bash
Verified

curl -X POST http://localhost:3001/apps/my-dashboard/start
-H “Authorization: Bearer $DAEMION_TOKEN”

Response on success:

json

{ “status”: “running”, “port”: 5173, “pid”: 84201 }

The gateway allocates a port from the range 5173–5273, waits up to 5 seconds for Vite to signal readiness, then returns. If the dev server is already running, it is stopped first before restarting.

Only apps with subtype fullstack or interactive have a dev server. Calling start on other subtypes returns 400 {“error”: “<subtype> apps do not use a dev server”}.


How do I restart an app’s dev server?

POST /apps/:name/restart Auth required

Stop and restart the Vite dev server for an app. Only works for fullstack and interactive subtypes.

bash
Verified

curl -X POST http://localhost:3001/apps/my-dashboard/restart
-H “Authorization: Bearer $DAEMION_TOKEN”

Returns the same shape as /start: &#123; "status": "running", "port": 5173, "pid": 84201 &#125;.


How do I stop an app’s dev server?

POST /apps/:name/stop Auth required

Stop the running Vite dev server for an app.

bash
Verified

curl -X POST http://localhost:3001/apps/my-dashboard/stop
-H “Authorization: Bearer $DAEMION_TOKEN”

Returns &#123; "status": "stopped" &#125;. The gateway sends SIGTERM and waits up to 3 seconds; if the process has not exited by then, it sends SIGKILL.


How do I access a running app remotely?

GET /apps/:name/dev/*

Proxy requests to the app's running Vite dev server. Allows remote clients (phone, tablet) to access the app through the gateway without exposing the dev server port directly.

bash
Verified

The gateway forwards the request to http://127.0.0.1:<port>/<path> with a 10-second timeout. Query strings are preserved. The response content type and status code are passed through unchanged.

The dev proxy endpoint does not require a bearer token. This allows the Daemion mobile app to render apps without embedding credentials in asset requests. The dev server itself is bound to 127.0.0.1 and is not directly accessible remotely.


How does the proxy allowlist work?

Some apps fetch external data at runtime. The gateway includes a CORS proxy at GET /apps/:name/proxy?url=<target> that forwards HTTPS requests on behalf of the app. Only origins listed in data/.proxy-allowlist are permitted — one origin per line. The file is re-read on every request, so you can add origins without restarting the gateway.

bash
Verified

Add an origin to the allowlist

echo “https://api.github.com” >> data/.proxy-allowlist

Proxy a request through the gateway

curl “http://localhost:3001/apps/my-dashboard/proxy?url=https://api.github.com/repos/octocat/hello-world
-H “Authorization: Bearer $DAEMION_TOKEN”

The proxy only permits HTTPS targets. HTTP URLs return 403.


Q What subtypes support a dev server?
fullstack and interactive. Apps with other subtypes (e.g. html) are served statically from disk — they do not have a runtime process to start or stop.
Q What port range does the gateway use?
Ports 5173–5273. The gateway probes for an available port in that range, skipping any already claimed by a running app. If the range is exhausted, start returns a 500 error.
Q Are apps Vite projects?
Yes. Apps are Vite projects located at ~/.daemion/apps/<name>/. The gateway looks for a local node_modules/.bin/vite binary first; if absent, it falls back to npx vite.
Q What happens if the dev server crashes?
The runtime status transitions to crashed. Call POST /apps/:name/restart to bring it back up. The gateway logs the exit code.
Q Do all dev servers stop when the gateway shuts down?
Yes. The gateway registers SIGTERM and SIGINT handlers that kill all running dev server processes before exiting.

What can go wrong

Common errors

404 &#123;"error": "app not found", "name": "..."&#125; — No app extension with that name exists in the database. Register the app as an extension first (type app).

400 &#123;"error": "html apps do not use a dev server"&#125; — Start/stop/restart only apply to fullstack and interactive subtypes. Check the app’s subtype field via /apps/:name/status.

500 &#123;"error": "Failed to start: ..."&#125; — Vite failed to launch. Common causes: missing node_modules (run npm install in the app directory), missing vite.config.ts, or no available port in the 5173–5273 range.

502 &#123;"error": "Dev server proxy failed"&#125; — The dev proxy could not reach the Vite process. The server may have crashed — check /apps/:name/status and restart if needed.

404 &#123;"error": "No running dev server for ..."&#125; — A dev proxy request was made but the app is not running. Call POST /apps/:name/start first.

403 &#123;"error": "Origin not in allowlist. Add ... to data/.proxy-allowlist"&#125; — The CORS proxy blocked the target origin. Add the full origin (e.g. https://api.example.com) to data/.proxy-allowlist.

401 &#123;"error": "unauthorized"&#125; — Bearer token is missing or invalid on a mutating endpoint (start/stop/restart/status). The dev proxy (/dev/*) does not require auth.


What’s next?

  • Extensions API — register an app extension before managing its runtime
  • Projects API — group apps with threads and agents into workspaces
  • System API — reseed, daemon control, and filesystem browsing