Self-hosting
Run SF Claws on your own infrastructure
SF Claws is a Node.js control plane you deploy yourself, plus a Chrome extension you can install from the Chrome Web Store. Your Salesforce refresh tokens, GitHub tokens and model keys stay in your deployment, encrypted per client under a master key you hold.
Key architecture
Three parts, one place where anything agentic runs
The extension and the admin console talk to the control plane over HTTPS and server-sent events. The control plane talks to Salesforce over OAuth and the Metadata API, to GitHub over the Git Data API, and to your model provider over its messages API. Nothing else has credentials.
Chrome MV3, LWC OSS, Tailwind
Chrome side panel
Renders the chat, plan, changes, explorer, notes and GitHub tabs, and reports which Salesforce page the user is on with every message. It never calls Salesforce, GitHub or a model provider itself.
Node.js, Fastify, SQLite
Control plane
Users, roles and approvals, clients and orgs, GitHub per client, model bindings, skills, policies, spend ceilings, the agent runtime and swarm, knowledge sources and the audit log. Everything agentic runs here.
LWC OSS, Tailwind, Vite
Admin console
Where super admins configure providers, models, clients, policies and standing instructions, approve users and extension pairings, and review every session end to end.
Repository layout
An npm workspaces monorepo on Node 22. Build order is shared, server, admin console, extension. The contract package changes first; everything else reads its output.
- packages/shared
- The contract: zod schemas for entities, REST routes, session events and SFDX source-format helpers.
- packages/server
- Control plane and agent runtime. Fastify, better-sqlite3, jsforce, Octokit, and the Anthropic, OpenAI, DeepSeek and DeepInfra providers.
- packages/admin-ui
- The admin console.
- packages/extension
- The Chrome MV3 side panel.
- skills/
- Default markdown skills seeded on first boot: policy, quality and playbooks.
- docs/
- Architecture, tenancy, deployment, admin and user guides.

Deployment steps
From clone to first session
Six steps. The first user to register becomes the super admin; everyone after that is pending until an admin approves them.
- 1
Salesforce Connected App
Once, in any org you control.
- Setup, App Manager, New Connected App. Enable OAuth settings.
- Callback URL:
https://<your-server>/api/v1/oauth/salesforce/callback - Scopes: api, refresh_token and offline_access, web, openid.
- Enable PKCE. Optionally disable "Require secret for Web Server Flow" and leave the client secret empty.
- Copy the consumer key and secret into SF_CLIENT_ID and SF_CLIENT_SECRET.
Each client org is then authorised by an admin clicking Connect to Salesforce in the admin console. The refresh token is stored encrypted. Sandboxes use the test login URL or the My Domain login URL.
- 2
GitHub, per client
Create a fine-grained personal access token, or a GitHub App installation token, with Contents read/write and Pull requests read/write on the client's SFDX repository, and enter it in the client's GitHub tab. The repository must already contain the SFDX project, by default under force-app/main/default.
- 3
AI providers
In the admin console as a super admin: AI, Providers, then set a key for any of Anthropic, OpenAI, DeepSeek or DeepInfra. Enable models and bind them to agent roles. DeepSeek and DeepInfra speak the OpenAI protocol and default to their own endpoints, so a key is all they need. Verify the prices in the models table; the spend ceilings use them.
- 4
The server
Node 22. SQLite on a persistent disk. TLS in front.
git clone <your fork or the SF Claws repository>cd sf-clawsnpm cinpm run buildcd packages/servercp .env.example .env # set PUBLIC_URL, MASTER_KEY, JWT_SECRET, SF_CLIENT_ID, SF_CLIENT_SECRET, CORS_ORIGINSNODE_ENV=production node dist/index.jsGenerate the master key with the one-liner below and keep it in a secret manager. Rotating it needs a re-encryption migration, so treat it as permanent.
node -e "console.log(require('crypto').randomBytes(32).toString('base64'))"The server serves the admin console from the same origin by default, including the extension pairing page and the OAuth result page. Put it behind TLS (nginx, Caddy, a cloud load balancer or the platform router). Server-sent events need the proxy to leave response buffering off. When a proxy terminates TLS, set TRUST_PROXY=true so the audit log and the rate limiter see the real client address. Back up the data directory: the SQLite file and its write-ahead log.
Or with Docker
docker compose up -d --build # env from packages/server/.env, data in the /data volume - 5
The Chrome extension
Use ours, or publish your own.
The quickest path is the SF Claws Chrome Extension on the Chrome Web Store. On first run each admin enters your server URL, grants permission for that origin and pairs the device: the panel shows a code, and the admin console approves it. The user must already be approved by the super admin.
To build and distribute your own, through the Web Store as private or unlisted, or through enterprise policy with ExtensionInstallForcelist:
npm run build -w @sf-claws/extension# load packages/extension/dist unpacked, or publish packages/extension/release/sf-claws.zip - 6
First client, first session
Create a client, connect its org, add its GitHub repository, add the consultants as members, and write its standing instructions: the CLAUDE.md for that client. Link your documentation and product repositories as knowledge sources. Then open a sandbox in Chrome, open the side panel, and ask for something small.
Community
This only works as a community project
3B built SF Claws for one operations team and one product suite. The Salesforce ecosystem has thousands of products, hundreds of metadata types and dozens of ways to host a Node.js service. Nothing product-specific is compiled in by design, and that leaves a lot of room for the people who know their corner of the platform better than we do.
Model providers
Gemini, Bedrock, Vertex, Azure OpenAI and local runtimes. The provider interface is small and the OpenAI-compatible path already exists.
Skills and playbooks
Markdown skills for common admin work: data model changes, Flow patterns, permission set design, managed package rollouts for specific products.
Metadata coverage
More metadata types with validation feedback, better diff rendering for layouts and Flows, and support for unlocked packages.
Hosting recipes
Tested guides for Heroku, Fly.io, Cloud Run, ECS and Kubernetes, with the reverse proxy and SSE settings each needs.
Tests and evaluations
Scripted provider scenarios that pin agent behaviour, and evaluations that catch a prompt regression before a user does.
Documentation and translations
Admin and user guides in more languages, and worked examples of end-to-end sessions.
How to contribute
- Open an issue first for anything beyond a small fix, so the approach is agreed before the work.
- Contract changes go into the shared package first, and any schema change is a new migration.
- Anything that changes a Salesforce org goes through the approval gate and takes a plain-language reason.
- Tests cover the behaviour, not just the happy path. Agent behaviour is pinned with the scripted provider, never a live API.
- Before pushing:
npm run lint && npm run typecheck && npm testLinks
- Contributing guidethe conventions that are not negotiable, and why
- Issuesbug reports and feature requests, with templates
- Discussionsquestions, hosting notes, show and tell
- Security policyreport privately, never in a public issue
- Code of conduct
Star it, fork it, run it
The repository has everything on this page in more detail, and a CI that runs lint, typecheck and the full test suite on every push.