davd

What it is

In plain terms, davd is like turning an agent’s folder into a network drive you can open in Finder or Explorer. You edit the agent’s files from your own machine, no logging into the server.

davd is a WebDAV server over each instance’s groups/ directory — WebDAV is the standard way to expose a folder as a network drive. The whole daemon is the sigoden/dufs Rust binary wrapped in an alpine image (for the standard wget healthcheck), launched with --port 8080 /data. The mount point /data is bind-mounted from <data-dir>/groups/.

davd itself has no notion of identity. Authentication and per-group scoping happen one hop earlier in proxyd.

Why it exists

The folder davd serves is the folder the agent reads each turn — PERSONA.md, MEMORY.md, facts/, custom skills, diary entries. Operators need a way to edit those files from a real editor (Finder, vim, VS Code, rclone) without shelling into the host.

WebDAV gives that for free: standard verbs (PROPFIND, PUT, DELETE, MKCOL) every OS already speaks. Without davd, the only way to edit a group’s files is direct filesystem access on the server, or a custom REST surface that re-invents what WebDAV already standardises.

How it fits

operator (Finder, vim, rclone, curl)
   |  WebDAV request to https://<host>/dav/<group>/...
   v
 proxyd
   |  verify JWT (cookie or Bearer)
   |  check group claim against URL path
   |  davAllow: reject writes to .env, *.pem, .git/, logs/
   v
 davd  (dufs on :8080, serving /data)
   |
   v
 <data-dir>/groups/<group>/…

Inputs: WebDAV verbs forwarded by proxyd. Outputs: bytes from (or writes into) the group’s folder on disk. The same bytes the agent reads on its next turn — no deploy, no restart.

Hard deps: a bind-mount of the data dir at /data, and proxyd in front for any non-local exposure. Direct access to davd is the same as root access to every group folder.

Concepts: concepts/webdav covers the proxyd write-block guard, the per-group path check, and end-to-end client examples.

Standalone usage

Yes, but with a warning: davd has no auth. Never bind it to a public interface without proxyd (or another auth layer) in front.

# run davd against a local directory
docker run --rm -p 8080:8080 \
  -v /srv/data/myinstance/groups:/data \
  arizuko-davd:latest

# probe (read-only PROPFIND on the root)
curl -s -X PROPFIND -H 'Depth: 1' http://localhost:8080/

# mount it with rclone
rclone mount :webdav,url=http://localhost:8080: ~/mnt/groups \
  --vfs-cache-mode writes

GET / returns 200 (the dufs index); the healthcheck probes that with a 3-second wget timeout. There is no /health route specific to davd.

Key env vars

None on davd itself — the container is launched with fixed flags (--port 8080 /data).
The toggles that matter live on the compose generator: WEBDAV_ENABLED turns the daemon on, DAV_ADDR picks the host port. Write-block rules and the /dav/<group>/ path check live in proxyd.

Full list and defaults in reference/env.

Go deeper

concepts/webdav — auth flow, write-block guard, client recipes.
davd/README.md — the wrapper image and dufs invocation.
specs/5/M-webdav.md — routing, auth model, write-block rules.
components/proxyd — the layer that gates every /dav/ request.