Should I vibe code
Hosted Excalidraw workspaces with collaboration, libraries, and sharing
The canvas is MIT — take it. What Plus sells is the server that still has your boards on Monday.
?
Their verdict, the Plus price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Confront the obvious thing first: the editor is MIT, published as an npm package, and you can have it running behind your own domain in an hour. So do not clone Excalidraw — import it. That single decision removes the entire drawing problem, which was never the problem. What Excalidraw+ sells is everything that is not in the repository: accounts, folders, boards that are still there on Monday, comments, presentation mode, and a collaboration server with an uptime target. The community server that powers live sessions, excalidraw-room, is MIT too but its last commit landed in December 2023, so "self-host the whole thing" quietly means "adopt a dormant websocket service". None of this is dangerous — a lost whiteboard is a bad afternoon, not an incident — but the honest ceiling is low. You will have a working multiplayer canvas by Sunday night and you will still be tuning websocket reconnection and scene storage two months later, for seven dollars a seat.
What actually breaks
not "if". the specific failures.
- Scene persistence. The canvas autosaves to browser storage by default, which is not a backup — clearing site data or switching machines loses everything that never reached a server
- The collaboration server, which in the open-source world is excalidraw-room, last committed in December 2023. Self-hosting it means you now maintain a websocket service nobody upstream is maintaining
- End-to-end encryption, which the public product gets by putting the key in the URL fragment. Store scenes server-side in your version and every board becomes readable by whoever holds the database
- Reconnection. A laptop lid closing mid-session, and the question of whether the drawing made in the last thirty seconds survives the socket dropping
- Concurrent editing at the edges — two people moving the same element, a late join replaying a scene, an element deleted on one side and dragged on the other
- Share links that never expire, which is fine until the board someone shared with a candidate still has last quarter's roadmap on it
- Storage growth, because embedded images live in the scene and a whiteboard with forty screenshots is not a small row
- Upstream drift: the editor package keeps moving, and a major version that changes the element schema means migrating every stored scene you own
Is that you?
the verdict is a default, not a law
- You are running the real MIT editor rather than writing a canvas
- Scenes are files — exported .excalidraw JSON in a folder or a git repository — and the app is a viewer over them
- Collaboration means sharing an export, not a live session
- It is you, or a handful of people who will happily redraw a board if it disappears
- The only copy of a team's boards is on a server you set up on a Sunday
- Boards get shared by link with people outside the company
- Anyone treats a whiteboard as a document of record rather than a sketch
- You would be operating the websocket server for a team that expects it during meetings
If you build it anyway
the checklist, then the prompt that enforces it
- Import @excalidraw/excalidraw. Do not rebuild the canvas — every hour spent on shape rendering is an hour not spent on the part that actually loses data.
- Persist to durable storage on a debounce from the first commit, and treat browser storage as a cache. Prove it by clearing site data mid-build and reloading.
- Export every scene to .excalidraw JSON on a schedule, into somewhere that is not the app's database. It is the whole reason this entry is only DEMO ONLY.
- Decide the encryption story explicitly. Either keep the key in the URL fragment as the public product does, or accept in writing that boards are readable by anyone with database access.
- Give share links unguessable IDs and an expiry, and mark publicly viewable boards visibly in the UI.
- Pin the editor package version and read the release notes before bumping. Element schema changes mean a migration across every stored scene.
- Store embedded images as blobs outside the scene document, with a size cap, or the first screenshot-heavy board will be a multi-megabyte row.
- If you self-host excalidraw-room, read it end to end first and accept that you are adopting it — upstream last committed in December 2023.
I want a self-hosted collaborative whiteboard. Before writing anything, talk
me out of building the canvas.
1. Say this plainly first: Excalidraw's editor is MIT and published as
@excalidraw/excalidraw. The correct build is importing it, not
reimplementing it. tldraw is the same answer under a different licence.
Only continue past this point if I explicitly say I want my own canvas.
2. Assuming I am importing theirs, the work is storage and sessions, so order
it that way. Durable persistence comes first: debounced saves to a real
database or object store, with browser storage treated as a cache only.
3. Prove it before adding features — clear site data, reload, and show me the
scene comes back from the server.
4. Then the export path: every scene written to .excalidraw JSON on a
schedule, into storage that is not the app's own database. If the app
dies, the boards are still files.
5. Then decide encryption out loud. Either the key lives in the URL fragment
the way excalidraw.com does it and the server never sees plaintext, or
boards are readable by anyone with database access. Write the choice into
the README rather than leaving it implicit.
6. Share links get unguessable IDs and a default expiry, and any board
readable without login is visibly marked public in the UI.
7. Only then live collaboration. If I self-host excalidraw-room, tell me its
last commit was December 2023 and that I am adopting it, not using it.
8. Handle reconnection explicitly: buffer local changes while the socket is
down and replay on reconnect. Show me the test where the network drops
mid-stroke.
9. Pin the editor package version. Before any upgrade, check the release notes
for element schema changes and write the scene migration first.
10. Images are blobs outside the scene document with a size cap. Out of scope,
and say so: comments, presentation mode, workspace libraries and user
management. Those are the $7 a seat.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as boards matter to more than one person. Seven dollars a seat a month buys the two things you cannot import from GitHub — a collaboration server somebody else keeps up during your meeting, and storage you are not responsible for backing up. The free tier is also unusually honest: the full editor, unlimited collaborators on a shared link, and local storage. If you are solo, that is not a trial, it is the answer.
$7/mo is cheaper than your weekend.
This is the rare entry where the exit is genuinely easy, and it is most of why the verdict is not harsher. The .excalidraw format is open, the editor that reads it is MIT and will keep existing whether or not your server does, and a scene exported today opens in excalidraw.com tomorrow. The discipline is the only hard part: schedule the export rather than intending it, and put the files somewhere your app cannot delete.
The product itself: MIT editor published as an npm package, so the canvas is a dependency rather than a project.
The collaboration server behind live sessions, MIT but last committed in December 2023 — self-hosting it is an adoption.
Infinite-canvas SDK with multiplayer built in, under tldraw's own licence rather than an OSI one — check the terms before shipping.
Questions
It is open source, so why isn't this SHIP IT?
Because what people mean by "build Excalidraw+" is not the editor. The editor is a dependency and using it is the recommendation. Plus is the account system, the folders, the boards that persist, and a websocket server with an uptime expectation. Standing all of that up is a weekend; keeping it running for other people is the part that never ends.
Can I just self-host the whole thing, editor and collaboration server?
You can, and for a small team it works. Know what you are taking on: excalidraw-room is MIT but its last commit was December 2023, so you are adopting a websocket service rather than consuming a maintained one. Read it before you depend on it, and have a plan for the day a Node or socket.io upgrade breaks it.
What actually loses my whiteboards?
Browser storage, usually. The editor autosaves locally by default, which feels like persistence right up to the point someone clears site data, uses a different machine, or opens it in a private window. Wire durable server-side saving and a scheduled .excalidraw export before you draw anything you would mind losing.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Diagram-as-code is a solved problem. Keeping the canvas and the code from drifting apart is not.
Multiplayer is not a feature you bolt on later. It is a document model, and you picked one on day one.
Mermaid is MIT and already renders in your README. The subscription is a login screen around a Markdown feature.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice