drafft.ink is a WebGPU whiteboard where collaboration is a CRDT and accounts are optional

Four build targets, one binary, and a collaboration server on port 3030

drafft.ink is described as an infinite canvas whiteboard built with Rust and WebGPU, and the installation section is four short blocks that cover the whole delivery surface.

The desktop path is a clone and a run:

git clone https://github.com/PatWie/drafft-ink.git
cd drafft-ink
cargo run --release

There is a build script for the same thing, and the native variant is:

./build.sh --native

The web variant uses the wasm flag:

./build.sh --wasm

And the collaboration server is its own crate, built and started as:

cargo build --release -p drafftink-server
./target/release/drafftink-server

The server listens on ws://localhost:3030/ws, and the README is characteristically blunt about the configuration story: one binary, no configuration files. Self-host it. Or don't. We're not your manager.

That last detail is the whole pitch in one line. There is no account to create, no paywall, no telemetry, and no upgrade to Pro, which the philosophy section states as a list of refusals: your tools should work for you, with no accounts, no paywalls, no telemetry, and no upgrade to Pro.

Five crates split the canvas, the renderer, the app and the server

The architecture section lists the workspace layout, and it maps one to one onto the parts of a whiteboard application.

drafftink-core holds the canvas state, the shapes, the CRDT sync and the snapping logic. drafftink-render does the Vello based GPU rendering and the text layout through Parley. drafftink-app holds the application logic, the UI, which is egui, and the event handling. drafftink-server is the WebSocket collaboration server, and drafftink-widgets holds the custom UI components. The workspace members list in Cargo.toml matches, and it also includes a crates/drafftink entry for the binary itself.

The dependency choices explain the rendering approach. vello is the rendering library, pinned with a patch section that replaces the crates.io version with a git revision, and the comment explains why: the current vello 0.6.0 uses wgpu 26 but egui 0.33 requires wgpu 27, so the workspace tracks vello from git until a version with wgpu 27 support is published. That single patch is the clearest sign of how tightly coupled the GPU stack is right now, and it is the first thing to check before you pin a version.

The rest of the stack is conventional. winit and wgpu for windowing and GPU access, egui and egui-wgpu and egui-winit for the interface, kurbo and peniko for geometry and color primitives, roughr and rough_vello for the hand drawn look, serde and serde_json for serialization, thiserror for errors, log and env_logger for logging, and uuid for identifiers. There is a wasm specific group too, with wasm-bindgen, web-sys and js-sys, plus console_error_panic_hook and web-time for the browser build, and native only entries for file dialogs through rfd and the clipboard through arboard, and png for encoding.

The drawing feature list is a sketch app with alignment tools

The features section reads like a product page, and the interesting parts are the ones that go beyond a canvas with shapes on it.

Shapes and drawing covers rectangles, ellipses, lines, arrows and freehand paths with pressure sensitivity, so stylus input is a first class case rather than an afterthought. Smart Guides add alignment snapping, equal spacing detection and angle snapping, which is the feature set that separates a drawing toy from a diagram tool. Text supports multiple font families, with GelPen, GelPen Serif and Vanilla Extract named, per-character styling, and inline LaTeX math.

Images can be dragged and dropped or pasted from the clipboard and are embedded in the document. The sketch style is explicit: sketchy on purpose, precise when it matters, with the hand drawn aesthetic coming from roughr and the fonts.

The open formats story is short and worth repeating: export to PNG or JSON, and import them back. That is a small list, and it is the boundary of the project. A whiteboard that can round trip its own documents is portable; a whiteboard that can only export images is a drawing app. Here you get both, and both directions, which means a document written in one instance can be loaded in another.

The collaboration line is the one with a joke in it, and the joke is about how little it does: real-time sync via Loro CRDT, with the observation that you can watch your colleagues draw boxes around things that don't need boxes. The CRDT part is the substance. A conflict free replicated data type means two people drawing at once do not produce a merge conflict, and no server arbitrates the order of operations.

No account means no login flow, and that is also the limitation

The absence of accounts is the feature everyone will notice, and it has a technical consequence that is easy to miss.

The collaboration server, as described, listens on a WebSocket address and takes no configuration files. There is no account system in the README, and the tool ships no configuration for users, credentials or tokens. So the collaboration model is a shared endpoint: anyone who can reach ws://localhost:3030/ws can join the session.

That is exactly what you want for a self-hosted instance on a private network or behind a reverse proxy with your own access control. It is not what you want for a public instance without a layer in front, because the canvas is shared state and there is nothing in the project that distinguishes one visitor from another.

The second limitation is the platform. The browser build depends on WebGPU, and the native build needs a GPU and a working wgpu driver stack. The README's cross-platform claim, Linux, Windows, macOS, browser, mobile, is a claim about the code having those targets, not a promise that every combination is equally smooth. Touch support is called out specifically for iPad and tablet with gesture navigation, and the browser path is the one that varies most between machines.

The third is the format list again, from the other direction. PNG and JSON cover screenshots and documents, and there is no mention of other interchange formats, so a workflow that needs to move a board into a different tool has a conversion problem to solve.

AGPLv3 is the price of the self-hosting promise

The licence is AGPLv3, and the README states it in one line: use it, modify it, host it, keep it open. The repository listing agrees, and the Cargo.toml records license = "AGPL-3.0" with the version at 0.1.1.

For a self-hostable server application, AGPL is the licence that matches the philosophy, and it is worth being explicit about what it means. If you run the unmodified project yourself for your own use, that is not the interesting case. The interesting case is the one the licence was written for: you modify it and you offer it to users over a network. Under the AGPL, that combination means the modified source has to be offered to those users. That is the obligation to plan for, and this paragraph is a licensing note rather than legal advice.

The release record is thin in a way that matches the 0.1.1 version. The repository has no GitHub releases, so there is no tagged history to diff against, and the version lives in the workspace package section of Cargo.toml. The last push was on 2026-07-06 and the repository is not archived, so work is happening, but the absence of releases means you are tracking main rather than pinning a known good version, which is a real constraint for anyone deploying this for a team.

The build configuration is worth one more look, because it shows the project's priorities. The release profile sets lto = true, codegen-units = 1 and opt-level = "z", and there is a separate release-wasm profile that inherits from it with the same size focus. The whole workspace is compiled for small size at the cost of build speed, which is the right trade for a binary people download and run.

Other repository details are conventional: a build.sh and a build-history.sh, a .cargo/ directory, a web/ directory alongside the crates for the web frontend, a utils/ directory, and a CI setup under .github/.

Editorial conclusion

Adopt drafft.ink if you want a self-hosted whiteboard with no account requirement and a licence that lets you run your own instance, and if you have a GPU and a Rust toolchain. Do not adopt it if you need the AGPL obligations to be avoided, since hosting a modified version as a service is exactly the case the AGPL covers, and check that the client renders in your browser since the browser build goes through WebAssembly and WebGPU. Verify first which export formats matter to you, because the format list is PNG and JSON, that your machine can run the WebGPU path, and that the collaboration server is reachable at the address the client expects.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. PatWie/drafft-ink on GitHub
4. Project website
5. README