SwarmClaw: a self-hosted agent runtime for teams that want their swarm on their own box

What SwarmClaw is for, and who ends up running it

The README describes SwarmClaw as "the self-hosted AI agent runtime and multi-agent framework for autonomous agents." The problem it targets is not chat. It is the gap between a single LLM call and a system that keeps working while you are not watching: an agent that remembers earlier sessions, calls external tools, hands work to another agent, and wakes up on a schedule. The repository's own framing is a "practical Claude Code and LangChain alternative," which tells you the intended audience. If you already have Claude Code or a LangChain graph and you want the orchestration layer under your own control, this is aimed at you.

The secondary audience is less technical. The README offers a one-click desktop installer for macOS, Windows and Linux and labels it "recommended for non-technical users." That is an unusual split for an agent framework, and it shows in the repository layout: an electron/ directory and electron-builder.yml sit next to a Dockerfile and a docker-compose.yml. The same product is packaged three ways, and the data directories do not overlap. Desktop data lives in the OS app-data path; CLI and Docker installs keep their own state. Pick one path and stay on it, because the README does not describe a migration between them.

How the runtime is put together: agents, memory, tools, delegation

The mechanism visible in the repository is a Next.js application with an Electron shell. package.json sets "main" to electron-dist/main.js, the build scripts run Next, and the Dockerfile copies .next/standalone plus a server.js entry point. So the runtime is a long-lived Node process serving an HTTP surface, not a library you import into your own program. The compose file exposes two ports, 3456 and 3457, and the Dockerfile sets PORT=3456 and HOSTNAME=0.0.0.0. Port 3456 serves the app and the health endpoint at /api/healthz; 3457 is exposed alongside it, and the README does not explain what it carries.

On top of that process sit the features the README names: agent memory, MCP tools, skills, delegation and schedules. The org chart screenshot in doc/assets/screenshots shows named agents (CEO, Developer, Researcher) with delegation edges and live activity, which is the mental model the project wants: you define roles, they hand tasks to each other, and the UI shows the traffic. Two details are worth pulling out. First, skills are learned from conversations and then reviewed, described as "reviewed conversation-to-skill learning," which means a human gate sits between a conversation and a reusable skill. Second, the provider list is broad by design: Anthropic, OpenAI, Gemini, OpenRouter, Ollama, DeepSeek, Groq, Together, Mistral, xAI, Fireworks, Nebius and DeepInfra appear in the logo table, and the README also lists delegated CLI backends including Claude Code, Codex, OpenCode, Gemini CLI, Copilot, Factory Droid, Cursor Agent, Qwen Code and Goose. Those two things are different: a provider is an API you send prompts to, a CLI backend is a program SwarmClaw drives. The README does not say how it decides between them, and that is a gap worth knowing about before you build a workflow around one.

Installing SwarmClaw with npm and getting an agent to answer

The README lists the requirements plainly: Node.js 22.6+ (the .nvmrc matches CI, so `nvm use` picks the right version), npm 10+ or another supported package manager, and Docker Desktop recommended for sandbox browser execution. Provider CLIs are optional and only needed if you want the delegated CLI backends.

For a global install the README gives two commands, one for npm and one for yarn:

npm i -g @swarmclawai/swarmclaw
swarmclaw

yarn global add @swarmclawai/swarmclaw
swarmclaw

Running `swarmclaw` starts the runtime and opens the dashboard, which is where the org chart, agent chat and operator controls live. Expect a browser tab on the local port rather than a terminal prompt; the CLI is a launcher for the app, not a REPL.

If you would rather run it as a service, the repository ships a compose file. It pulls ghcr.io/swarmclawai/swarmclaw:latest, maps 3456 and 3457, mounts ./data into /app/data, and reads an optional ./.env.local:

services:
  swarmclaw:
    image: ghcr.io/swarmclawai/swarmclaw:latest
    ports:
      - "3456:3456"
      - "3457:3457"
    volumes:
      - ./data:/app/data
    env_file:
      - path: ./.env.local
        required: false

Two things to notice. The healthcheck curls http://localhost:3456/api/healthz every 30s with 3 retries and a 10s start period, so you can tell a broken container from a slow one. And env_file is marked required: false, which means the container will start without any provider credentials and simply have nothing to talk to. Put your keys in .env.local before you expect an agent to reply.

The README also documents a setup script pair for source checkouts, `npm run setup:easy` and `npm run quickstart`, but it does not spell out what each one does beyond the script names.

Where SwarmClaw gets in your way

The desktop install is the weakest documented path, and the README admits it. macOS releases are signed and notarized only "when Apple credentials are configured"; otherwise the build is ad-hoc signed and macOS may refuse it. The README gives two different remedies depending on the message you see. If Finder warns about an unidentified developer, right-click the app and choose Open. If macOS instead says the app is damaged, the cause is a quarantine attribute from Safari, and the fix is:

xattr -dr com.apple.quarantine /Applications/SwarmClaw.app

That is a reasonable workaround to document, but it is also a signal: if you are deploying to people who cannot run a terminal command, the signed build is the one you need, and the README does not promise it will exist for every release.

The larger limitation is structural. SwarmClaw is a long-running server with a database and a data directory. The Dockerfile installs git, python3, make and g++ specifically because better-sqlite3 needs to compile, and it retries `npm ci` up to three times. That is a build that wants a real machine, not a serverless function. The compose file binds ./data to /app/data, and nothing in the README describes rollback, backup or schema migration for that directory. If you run agents that accumulate memory over months, you own that data and its upgrades yourself.

Finally, the provider breadth cuts both ways. Twenty-three providers and nine CLI backends is a lot of surface to keep working, and the README does not publish a compatibility matrix saying which combinations are supported together. The release cadence visible in the tags (v1.9.38 on 2026-06-08, v1.9.39 on 2026-06-11, v1.9.40 on 2026-06-30) suggests active work, but the last push to the repository was on 2026-06-30, so treat the current state as a snapshot rather than a moving target you can rely on for daily fixes.

SwarmClaw against CrewAI and LangChain

The README positions SwarmClaw against LangChain and Claude Code, and the search data shows people comparing it to CrewAI as well. The difference is where the runtime lives. LangChain is a Python library: you write the orchestration code, you own the process, and the framework is a dependency inside your application. CrewAI follows a similar shape, defining crews and tasks in Python and executing them in your script. SwarmClaw inverts that. The orchestration is the product, it runs as a server you deploy, and you configure agents through a dashboard instead of composing them in code. That is a real trade. You get persistence, schedules and a UI for free; you give up the ability to embed the agent loop in an existing Python service.

Against Claude Code the split is narrower. Claude Code is a coding agent in a terminal, and SwarmClaw lists it as one of the CLI backends it can delegate to. So the honest comparison is not either/or: SwarmClaw can drive Claude Code as one worker among several. What SwarmClaw adds is the layer around it, which is memory, scheduling and multi-agent delegation. If your work is one developer pair-programming in one repository, that layer is overhead. If your work is several agents with different roles and a queue of recurring jobs, it is the part you would otherwise write yourself.

Maintenance, licensing and what an upgrade actually costs

SwarmClaw is MIT licensed, and package.json declares "license": "MIT" with publishConfig pointing at the public npm registry. MIT is permissive: you can run it commercially, modify it and ship it inside a product, provided you keep the copyright and licence notice. That is the whole of it. Nothing here is legal advice, and if you are embedding it in something you sell, read the LICENSE file in the repository root rather than this paragraph.

The maintenance picture is mixed and worth stating plainly. The repository is not archived. The last push was on 2026-06-30, and the most recent release tag is v1.9.40 from the same day. There is a CI workflow, a CONTRIBUTING.md, a CLAUDE.md and a tests/ directory, so the project has the furniture of a maintained codebase. But the version numbers move in small increments (1.9.38 to 1.9.39 to 1.9.40 inside three weeks), which usually means frequent patch releases rather than long stable plateaus. Budget for upgrading more often than you would for a library that ships twice a year.

The upgrade cost itself is the data directory. The compose file mounts ./data into the container, the Dockerfile creates /app/data, and the desktop app keeps its state in the OS app-data path instead. Upgrading the image replaces the code, not the volume, so your agents' memory survives an image pull. What the README does not document is whether a newer version migrates that data forward, or what happens if it does not. Snapshot ./data before you pull a new tag, and check the health endpoint at /api/healthz after the container comes back, because that is the only readiness signal the compose file defines.

Editorial conclusion

Adopt SwarmClaw if you want a self-hosted runtime where agents keep durable memory, call MCP tools and delegate to each other, and you are comfortable running Node 22.6+ or the Docker image on port 3456. Skip it if you need a managed service with an uptime commitment, or if you only want a coding assistant inside one editor. Verify first that your provider keys work, that ./data is mounted on a volume you actually back up, and that the /api/healthz healthcheck passes before you point anything real at it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. swarmclawai/swarmclaw on GitHub