Deployments
Deploy Coven on headless hosts, service managers, containers, or Nix-managed environments without changing its local daemon contract.
3 min read
Use this page after install when the main question is where the daemon lives. Deployments do not change the runtime contract: Coven still runs as a same-user local daemon with local-only daemon IPC.
Docker, Podman, and Nix coverage on this page describes manual or experimental integration patterns. They are not tested first-class packaged Coven install targets, and this docs set does not ship official Dockerfiles, Containerfiles, images, or Nix artifacts for them.
Deployment Routes
| Route | Use when | Key rule |
|---|---|---|
| Headless or cloud host over SSH | You will run Coven without a desktop. | Sign in as the same OS user that owns COVEN_HOME, then keep remote access behind SSH. |
launchd | You want Coven to start automatically for a macOS user. | Preserve the same PATH and COVEN_HOME that passed coven doctor manually. |
systemd --user | You want a Linux user service. | Preserve the same PATH and COVEN_HOME that passed coven doctor manually. |
| Docker or Podman | You are composing a manual or experimental container integration inside one shared trust boundary. | Bring your own image definition, mount a persistent COVEN_HOME, and keep the daemon local to that boundary. |
| Nix | You are composing a manual or experimental Nix-managed environment or build route. | Bring your own Nix expression and treat Nix as an environment or build route, not a different runtime contract. |
Headless And Cloud Hosts
Operate headless or cloud machines over SSH as the same OS user that owns COVEN_HOME. Use coven doctor to confirm the environment from that login shell, then inspect the live endpoint with coven daemon status.
coven doctor
coven daemon statusThe daemon IPC is local-only. Do not expose it directly on the public internet or treat it as a public service. For remote-access patterns and trust boundaries, read Daemon Security.
Service Managers
launchd on macOS and systemd --user on Linux are wrappers around the same local daemon. Only add them after a manual shell session already works, and make sure the service preserves the same PATH and COVEN_HOME values that passed coven doctor.
If the supervised service cannot see coven or a harness CLI that works in your shell, fix the service environment instead of sharing one COVEN_HOME across multiple users.
Docker And Podman
Docker and Podman do not create a different Coven networking model. These are manual or experimental integration patterns, not tested first-class packaged install targets, and Coven does not publish an official Dockerfile, Containerfile, or container image for them. If you package Coven into your own container, keep it within one same-user shared trust boundary, mount a persistent COVEN_HOME, mount the project root you want to supervise, and avoid direct public exposure of the daemon IPC.
Containers are most appropriate when you already control the image, the harness CLIs inside it, and the users who can reach that boundary.
Nix
Nix is useful for building or pinning the environment around Coven, especially Node.js, Rust, and harness tooling. Treat it as a manual or experimental integration pattern, not a tested first-class packaged install target, and do not assume an official Coven flake, derivation, or module exists. Once inside your Nix environment, Coven still uses the same COVEN_HOME, the same local-only daemon IPC, and the same-user verification flow.
Before You Call The Deployment Healthy
- Log in as the OS user that owns
COVEN_HOME. - Run
coven doctor. - Check
coven daemon status. - Confirm the service or container preserves
PATHandCOVEN_HOME. - Keep remote access behind SSH or another private control plane; never allow direct public exposure.
Last updated on