Doop: a multiplayer canvas where AI agents edit the same frames as you
The open-source alternative to Paper.design. A multiplayer design canvas where humans and AI agents design together, live. MCP built in.
At a glance
- What is it?
- Doop is an AGPL-3.0 TypeScript design canvas that renders frames as real HTML in sandboxed iframes and exposes an MCP server so Claude Code or the built-in agent can design alongside humans. The interesting part is the shared WebSocket room; the awkward part is the licence and the model-key plumbing.
- Who is it for?
- Adopt Doop if you already run Claude Code or another MCP client and want its edits to land on a canvas other people are watching, and if AGPL-3.0 is acceptable for how you deploy. Skip it if you need a canvas whose files you can embed in a closed product, or if you cannot supply an ANTHROPIC_API_KEY and do not want to wire Azure OpenAI through DOOP_AGENT_PROVIDER.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Doop targets: agents that design somewhere you cannot watch
Most agent-driven design workflows are a loop of prompt, wait, refresh. The agent writes files or emits markup, you reload something, you judge the result, you prompt again. The work happens out of sight and the artifact arrives finished, which makes it hard to intervene halfway through a layout decision. Doop's README frames the project as an answer to that: a Canvas at /c/<id> holding Frames, where people edit in the browser and agents edit through an MCP server, with cursors, presence, frame edits, agent status and an activity feed all shared over one WebSocket room. The audience is narrow and specific. It is for teams already using Claude Code or another MCP client who want the agent's output to appear on a surface a designer can point at, and for people who want to self-host that surface rather than rent it. It is not a Figma replacement for pixel-level production work, and nothing in the material suggests vector editing, prototyping links or a plugin ecosystem.
Frames as sandboxed HTML iframes, and one WebSocket room for everyone
The unit of work is the Frame, described as an artboard that renders real HTML inside a sandboxed iframe. That choice explains a lot of the rest. Because a frame is HTML rather than a proprietary scene graph, an agent does not need a bespoke drawing API; it produces markup and the canvas renders it. The collaboration layer is a single WebSocket room carrying live cursors, presence, per-frame editing indicators, undo/redo, comments pinned to elements, and the activity feed. The MCP server lives on the same origin as the API and WebSocket, which is why the web port proxies /api, /ws and /mcp through to the backend on :4400. The README also describes design memory: pinning exemplar frames, capturing decisions, and a distiller that proposes durable style rules every agent then follows. The distiller is implemented in server/distill.ts and, per the README, runs on ANTHROPIC_API_KEY and quietly turns off without it. That is a real architectural dependency worth noticing: the memory feature is not model-free.
Getting a canvas up: bun run dev, Docker, or the hosted instance
The documented local path is short. Clone the repository, run bun install, then bun run dev. Bun is the package manager (bun.lock is the only lockfile) while the server itself runs on Node. The web app comes up on http://localhost:4300 and the API, WebSocket and MCP server on http://localhost:4400. No configuration is required to start: data persists to an embedded Postgres (PGlite) under data/pg, and the README states that optional integrations such as SMTP, stock photos, object storage and analytics degrade gracefully until their variables in .env.example are set. For a production build there are two documented routes. Docker: BETTER_AUTH_SECRET=$(openssl rand -hex 32) docker compose up -d, which brings up app plus Postgres on :4400. Without Docker: bun run build && bun run start, a single server on :4400 serving everything. Setting DATABASE_URL switches to a real Postgres using, in the README's words, the same code path as PGlite.
Connecting an agent over MCP OAuth, and what the built-in agent costs
The connection command is one line: claude mcp add --transport http doop http://localhost:4300/mcp. According to the README this triggers the standard MCP OAuth flow, opening a browser window for approval, after which the agent works as you and inherits your access. Separate from that, Doop ships a server-side agent that picks up work on its own when you queue a board card, @mention a role on an element comment, or leave feedback on a task. Roles live in shared/agents.ts and a card can be routed through several in order. Funding is the part to read carefully. The server pays for a free tier on Anthropic via ANTHROPIC_API_KEY, and the same key gates the guideline distiller. Organisations that need Azure OpenAI can set DOOP_AGENT_PROVIDER=azure along with AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_API_KEY and AZURE_OPENAI_DEPLOYMENT. Past the free tasks, a user connects their own ChatGPT account (or supplies an OpenAI key) and, per the README, that connected account takes over from the very next task rather than after the free balance is spent. Note the asymmetry: the distiller stays on Anthropic regardless, so an Azure-only deployment loses the distiller.
Where Doop is the wrong tool, and what the README does not settle
The licence is the first constraint. Doop is AGPL-3.0, and the README offers no alternative licensing path. If you intend to embed this canvas in a hosted product, the network-copy obligations of that licence are a question for your own counsel, not something this article can resolve. The second constraint is the model dependency. The welcome performance on a first canvas is scripted in server/demo.ts, a pre-authored frame replayed through the same machinery real agents use, so it runs with no configuration. Everything past that wants a key. A team that wants agent design but cannot supply Anthropic or Azure OpenAI credentials gets a multiplayer canvas with a scripted demo and no working agent. Third, the material is silent on several things a buyer would ask about: there is no stated limit on concurrent editors per canvas, no description of how frame HTML is sanitised beyond the word sandboxed, and no migration or export story for getting designs out. I would treat the absence of an export path as the most consequential omission, since it determines how reversible an adoption decision is.
Against Paper.design: same premise, different distribution
Doop positions itself explicitly as the open-source alternative to Paper.design, and the README links to paper.design for comparison. The meaningful difference is not the feature list, it is where the software runs and who can extend it. Paper.design is a hosted product; Doop can be run with docker compose up -d on your own machine or your own server, with the same code path serving PGlite and a real Postgres. That matters for teams with data residency constraints or a preference for keeping design files inside their own network. The second difference is the agent interface. Doop exposes MCP on the same origin as the app, so any MCP client can attach, and the built-in agent runs server-side rather than in a client you have to keep open. A hosted tool can change its agent surface at will; a self-hosted one pins to a version you chose. The trade is operational: you now own upgrades, the Postgres instance, and the API keys, and you get no vendor support contract for any of it.
Release cadence, upgrade cost, and the AGPL boundary
The release history in the material is dense and recent: v0.4.0 and v0.3.0 both dated 2026-09-10 and 2026-09-09, plus a desktop-v0.2.0 tag the previous day. A project at 0.x releasing twice in two days is moving fast, and that cuts both ways. You get fixes quickly; you also get schema and API churn, and the README gives no migration guide for the PGlite data directory at data/pg or for a Postgres instance behind DATABASE_URL. The practical upgrade cost is therefore unknown from the documentation, which is itself the finding. Before putting real design work into an instance, verify what a version bump does to existing canvases, and check whether the MCP tool surface is stable between v0.3.0 and v0.4.0, since agents you have already configured will depend on it. On licensing, AGPL-3.0 governs the code as published; whether your specific deployment triggers its network-use clause is a legal question about your architecture, and the repository does not answer it for you.
Editorial conclusion
Adopt Doop if you already run Claude Code or another MCP client and want its edits to land on a canvas other people are watching, and if AGPL-3.0 is acceptable for how you deploy. Skip it if you need a canvas whose files you can embed in a closed product, or if you cannot supply an ANTHROPIC_API_KEY and do not want to wire Azure OpenAI through DOOP_AGENT_PROVIDER. Before committing, clone the repo, run bun run dev, add the MCP endpoint with claude mcp add --transport http doop http://localhost:4300/mcp, and confirm the OAuth flow and the server/demo.ts welcome performance behave the way the README describes on your machine.
Community notes