Show HN: CommonForge – Let clients' AI agents work in your codebase safely CommonForge launched as a self-hosted workspace that lets agencies and their clients run coding agents on client websites, with every agent change isolated, checked, previewed on staging, and approved before production. The tool runs entirely on Cloudflare Workers and Cloudflare Artifacts, deploys into a user's own Cloudflare account via one script, and agents operate through a small CLI called cforge that installs, signs in with a one-time code, checks out the task's folders, and finishes with cforge submit. Access is controlled per folder by the owner through Settings → Access, with Can change, Read only, or No access options, and clients see only the projects they are given. CommonForge is a self-hosted workspace where an agency, its clients and their coding agents change a client's website together. Clients ask for changes as tasks. Agents work on each task in an isolated copy of the code. Every change is checked, previewed on a staging site and approved before it reaches production, and every accepted version can be restored. For developers: it runs entirely on Cloudflare Workers and Cloudflare Artifacts . You deploy it into your own Cloudflare account with one script, and agents work through a small CLI, cforge . ▶ Watch the 8-minute demo on YouTube | Getting started walks a new owner from an empty organization to the first client task live. | Tasks staging mode : client tasks move from Working to In staging, Waiting for approval and Live. | | Give to agent copies one prompt that a coding agent runs from start to finish: install, sign in, check out, submit. | The Change storyboard : what was asked, what changed, what was verified, and the next decision. | | Versions : every accepted version, the one production runs, and restore. | | The screenshots come from the local stack below , not from fixture data. To regenerate them, run pnpm --filter @commonforge-org/web run screenshots apps/web/e2e/readme-screenshots.spec.ts https://github.com/CommonForge-org/commonforge/blob/main/apps/web/e2e/readme-screenshots.spec.ts . The path from a new deployment to a client's change in production: 1. Owner signs in. Sign-in is by emailed magic link. Only the addresses in the deployment's admin list COMMONFORGE ADMIN EMAILS may create an organization. 2. Organization and project. One organization per client; a project is one client site. The project's Overview shows a Getting started checklist that reads its progress from the real project state. 3. Import the code. Files → Add imports a public Git repository as the project's first version. 4. Release target and first publish. The project's Settings → Policy gets a Release section a ready example is offered , which says how to build the site and which Cloudflare Worker runs production. Then Versions → Publish this version : prepare, approve publishing, publish. 5. Staging. A Staging section in the Policy turns on always-on staging. Staging starts from what production runs, so the first publish comes before it. 6. Invite the client. Members → Invite , role Client, with access to the project. Clients see only the projects they are given. Then choose, under Settings → Access , what they can do with each folder: Can change their agent changes it, and the change goes to staging for review , Read only , or No access . A new client reads only until you choose. 7. The client asks for a change. The client creates a task on the Tasks board: a title and what they want, nothing else. Which folders the agent may change, only read, or never see comes from the access the owner set in step 6, not from the client. 8. An agent does it. Give to agent has one button, Copy prompt for your agent . The person pastes the prompt into a coding agent that can run commands the Code tab in Claude Desktop, Codex, Claude Code, Cursor, … . The agent installs cforge if it is missing, signs in with a one-time code that the button puts in the prompt, checks the task out into its own copy of the task's folders, does the work and finishes with cforge submit . The same steps, to run by hand, are folded away under the button. 9. Staging and review. The submitted change goes to the shared staging site by itself and moves to In staging . The client tries it there. 10. Production. The client who asked for it or a developer promotes it from the board. It reaches production once it is approved and published; publishing is a separate, explicit step owners by default . Without staging, the same work goes through Changes instead: New task , Give to agent , then Make proposal once the agent submits. The proposal opens as a Change storyboard: validation runs the project's checks, then approve, accept as a new version, and publish are three separate records. Clients of such a project edit a filtered edition copy and send it back as a proposal. Underneath: - Every task works in its own isolated Artifacts repository, with short-lived credentials scoped to that repository. Clients' editions have no access to the production repository. - A SQLite Durable Object ledger decides, atomically, what becomes the accepted version. Stale proposals are refused, approvals are bound to the exact proposal hash, and restore is a new forward version. - An integration runner in a Cloudflare Sandbox container does the git merge, the checks, the preview build and the push. The Artifacts API cannot write, so every write is a git push from the runner. The repository also hosts the reusable versioned-workspace engine @commonforge-org/ : core, ledger, providers, runner protocol, conformance suites that other products can adopt. web app / cforge CLI / agents │ HTTPS session cookie or bearer ▼ ┌─────────────────────────────┐ signed jobs Queue ┌──────────────────────────────┐ │ commonforge-worker │ ──────────────────────▶ │ commonforge-runner │ │ Hono API, auth, broker │ ◀────────────────────── │ Sandbox container per job: │ │ OrgLedger DO SQLite │ results, credentials │ git merge/check/push, builds │ │ D1 directory, outbox, cron │ service binding └──────────────┬───────────────┘ └──────┬───────────────┬──────┘ │ git push │ REST/binding │ ▼ ▼ ▼ ┌──────────────────────────────┐ R2 assets, Artifacts: