Skip to main content
Most people can use Clawdi without running a backend, database, or dashboard. Self-hosting is for advanced users who want to operate the shared open-source service themselves.

​
What self-hosting changes

Self-hosting changes who operates Clawdi’s shared service. It does not change the meaning of a Connected Agent or Cloud Agent, and it is independent of the Agent software you choose. The public open-source repository includes the CLI, backend, dashboard, database schema, and migrations. When you self-host the shared service, you take responsibility for its dependencies, authentication, encryption configuration, upgrades, and backups.
Self-hosting the open-source service does not include the remote infrastructure that Clawdi runs for Cloud Agents. Do not use clawdi deploy as a way to add that infrastructure to a self-hosted service.

​
Start from the public runbook

Use the current public repository as the source of truth for prerequisites and local end-to-end setup:

Open the self-hosting guide

Review the current open-source setup instructions before operating the service yourself.
After your backend is running, point the CLI at it before signing in. For Clerk OAuth, enable the device grant as described in Self-hosted authentication, then use clawdi auth login. If you already have an API key, use the manual fallback:
The localhost URL is for local setup. This user guide does not prescribe a production architecture; use the public repository’s current self-hosting guidance for the release you operate.

​
Decide whether to self-host

  • Use Clawdi without operating infrastructure when you want the shortest path to connecting Agents and working with shared objects.
  • Self-host when you need to inspect or change the open-source service and are prepared to operate its dependencies.
  • Choose where each Agent runs separately. To have Clawdi run an Agent remotely, start with Cloud Agents.
Last modified on August 3, 2026