Data, backups, networking & updates
Where your data lives, the backups that matter (one of them irreplaceable), how networking and TLS work per install, and how updates land.
The operational essentials for keeping a self-hosted instance healthy.
The data directory#
Everything lives under ~/.damn-dev/, shared across every install path:
damn.db, the SQLite database (channels, agents, approvals, the audit log).secrets.key, the AES-256-GCM key that encrypts your secrets..env, plaintext infrastructure config.
Agent files (souls, memory, skills) live under ~/.openclaw/.
Backups, what to save#
Warning: Losing
secrets.keymakes every secret permanently unrecoverable, there is no other copy. Back it up off the host. Settings → Secrets has a Download key button, and Settings → Environment has Download .env; for a no-shell managed install those buttons are your backup path. Also back updamn.dbto preserve history and configuration.
Because the instance is yours, backups are your responsibility, the same trade that gives you full data sovereignty.
Networking & TLS#
| Install | Networking |
|---|---|
| npm / docker-local / Tauri | Listens on this machine only (loopback) by default, so nothing on the same Wi-Fi can reach it. Turning on Tailscale or a custom hostname in Settings → Network opens it to the network on purpose. On Linux with Docker it listens more widely, because containers reach the host over the Docker bridge. DAMN_DEV_BIND_HOST overrides the choice. Transport security beyond that is the deployer's responsibility |
| docker-vps | Caddy terminates TLS automatically (Let's Encrypt); expects a real hostname |
Hostname, Tailscale, and custom-domain options are in Settings → Network.
Updating#
Nothing updates itself. On any install path. No background check-and-install, no scheduled pull, no image swapped under you overnight. A banner tells you a version is available; the software changes when a person clicks, and never otherwise.
That's a commitment, not an accident of configuration, replacing the software that enforces your policy is exactly the kind of change that shouldn't happen while nobody is looking.
When you do click, one in-product flow handles it per install path, pulling new images on Docker, updating the global package on npm, or handing off to the native updater on desktop (macOS builds are signed and notarized).
You're told before you click, and it's recorded after#
A release that changes what gets blocked, or changes a default, says so up front, in its own section, unfolded, before the button. A change to enforcement behaviour is not a feature note, and finding out afterwards is the wrong way round.
The update itself lands in your audit trail, with the attempt and the outcome recorded separately. A failure names the step it failed at, which is what makes a half-migrated box actionable. And success isn't claimed by the process that promised it: the version change is recorded at the next start, by whatever actually came back. Evidence rather than a claim.
A governance product that audits an agent running a shell command, but not its own replacement, has a hole precisely where a reviewer will look.
On desktop#
The desktop app and the server it's pointed at are two different versions, and the banner says so separately. Screens come from the server, so a current server is genuinely up to date for most of what you do, but anything that writes to your machine (connecting a coding agent, an MCP entry, the discovery sensor) lives in the app itself and simply doesn't exist until the app updates.
One manual download, once. Desktop builds before 0.48.1 shipped an update button that never worked: the app's own permissions refused it, and it fell back to telling you to download. If you're on one of those, download 0.48.1 from the download page and replace the app. From then on, Update now installs the new signed build and restarts into it. The version and download source are fixed inside the app, so the server a desktop app is pointed at can't redirect it to a different build or an older one.
Ceiling: Two things aren't built yet, and it's better you hear it here. There's no version pinning (you can't sit on a minor and take only patches) and there's no rollback: on a server install, going back means re-pinning images by hand. Don't plan around updates being cheaply reversible.
The version check also sends an anonymous install analytics ping (a random id and a version number, nothing about your workspace) with a single switch to turn it off.
Next#
- Doctor & troubleshooting, diagnosing a sick instance.
- Enforced vs Trusted, why host access is the trusted boundary.