Data, backups, networking & updates

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.key makes 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 up damn.db to 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	Expected on localhost or a private network; transport security 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.

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.