Quickstart

Install the desktop app to see what AI is running on a machine, or stand up a server your whole team reports to.

damn.dev is self-hosted, so "getting started" means standing up your own instance. Two of them are worth your time, and which one depends on what you are trying to do right now.

Pick your path#

You want toInstallRuns as
See what AI is running on a machineThe desktop appA bundled sidecar, plus the sensor that does the scanning
Put your team on itdocker-vps, one commandContainers behind Caddy (auto-TLS)

Most people do both: look with the app, then stand up the server once they have seen enough.

The CLI paths scan nothing. npm and docker-local are still supported, but the endpoint sensor ships only in the desktop app, so a laptop workspace installed by script shows an empty Registry until the app or the browser extension feeds it. A teammate cannot reach either one. See Install & deploy before choosing one.

Note: All install paths share one data directory at ~/.damn-dev/ and one agent directory at ~/.openclaw/. You can move between paths (for example, install the CLI first, then add the desktop app) and they compose cleanly.

Install (one-command scripts)#

bash
# The one to use: a server your team reaches. Needs a domain pointed at it.
curl -fsSL install.damn.dev/vps | bash

To look at a single machine first, install the desktop app instead. It scans that machine and shows you the AI on it in about a minute, with no account and no server.

The two laptop paths below still work and are still supported, but neither scans anything (the sensor ships only in the app) and a teammate cannot reach either. See Install & deploy before picking one.

bash
curl -fsSL install.damn.dev/docker | bash   # docker-local
curl -fsSL install.damn.dev/npm    | bash   # npm CLI

Installing the CLI by hand#

The one-command scripts above do this for you. This is the manual version, and it applies to the two laptop paths only: docker-vps runs in containers and needs no CLI on your machine.

The CLI is published as @damn-dev/cli.

Warning: The CLI must be installed with pnpm, not npm. A native dependency hard-fails any npm-based global install. Using npm will abort partway through with an only-allow … pnpm error.

bash
# Enable pnpm (bundled with Node 22 via corepack)
corepack enable

# Install the CLI
pnpm add -g @damn-dev/cli

# Start your workspace
damn-dev start

Then open the printed URL (the workspace serves on port 3001 in production).

First-run notes & ceilings#

Ceiling: A few things to expect on first run:

  • The browser skill is a one-time ~363 MB download. The first time an agent uses the built-in browser, it fetches a stealth Firefox build (~298 MB) plus GeoIP data (~65 MB). Docker images pre-bake it; npm and Tauri download it on first use. Budget for the delay and ~150 MB RAM per active browsing agent.
  • docker-vps needs DNS + TLS. A server install terminates TLS at Caddy and expects a hostname; local and desktop installs are fine on localhost or a private network.
  • Provider API keys go in the right place. Set model provider keys (Anthropic, OpenRouter, etc.) in Settings → AI & Models → Model Providers, not the generic Secrets tab. The Secrets tab stores the key but doesn't route it into the runtime. See Models, providers & secrets.

Your first 15 minutes#

Once the workspace is up, the fastest way to understand it is to run the core loop once: chat → the agent proposes an action → you approve → it happens, and it's logged.

  1. Set your security posture. As the first user you're the operator, so onboarding asks you to pick a governance baseline, Regulated (secure default), Standard, or Open. Choose one (you can change it anytime in Oversight → Policy). Nothing is enforced until you do. Onboarding is governance-first and ends there; setting up a runtime and models happens later, only if you build your own agents.
  2. Turn on the agent builder. Console → Overview → "Build & run your own agents". It walks you through a runtime and a model, then drops you into the COO chat. Running your own agents is a licensed capability, so this door explains what it is and how to ask for it, see Licensing.
  3. Create an agent. Sidebar → Agents → New agent. Name it, describe its job, pick a model. It gets you as its accountable owner by default.
  4. Chat with it. Open its channel and ask it to do something within its job. It keeps its own memory and identity across turns.
  5. Watch it request an action. Ask it to do something that touches reality, run a shell command, or hand work to another agent. Instead of doing it silently, it emits an approval card inline: what it wants to do, a plain-English summary of why and the risk, and Approve / Deny.
  6. Approve it. The action runs, the result posts back into the channel, and the decision is written to the Trace audit log. Deny, and nothing happens.

Ceiling: The "Always allow" affordance on a card is operator-only, creating a standing auto-approve rule is an operator action. A small set of action types (editing an agent's prompt, installing a skill, merging code) can never auto-approve, no matter what. See Core concepts.

Next#

Previous← What is damn.devNextCore concepts →