OPEN SOURCE DEEP DIVE
Toonflow: open-source AI video generation workbench for short dramas and motion comics, from script and storyboard to shots on one infinite canvas
Toonflow productizes short-drama and motion-comic production as infinite-canvas nodes: text nodes write script and storyboard, image-generation nodes cut character turnarounds and scene plates, video-generation nodes render each shot from its references, while audio nodes and a 3D director stage carry dubbing and camera blocking. The model layer stays open - third-party APIs, local ComfyUI and local LLMs all plug in - and agents, MCP and a plugin market open the same canvas to machines. MIT licensed, deployable as desktop, Android, Docker or a plain server.
In one sentence
Toonflow (HBAI-Ltd/Toonflow-app) is an open-source AI creation platform for short dramas, motion comics and short-form video: script, storyboard, character and scene assets, image and video shots all live on one infinite canvas, wired by hand into a complete line from text to finished cut. At collection time the repo held 18,468 stars and 3,283 forks under the MIT license, TypeScript as its main language on Bun 1.3.14, created 2026-01-29 and still updating at high frequency.
What separates it from "yet another text-to-video wrapper" is that the whole craft of making one short drama is productized as canvas nodes: text nodes write script and storyboard, image-generation nodes produce character turnarounds and scene plates, video-generation nodes cut each shot from its references, audio nodes carry dubbing and effects, and a 3D director stage blocks the camera before any video is spent. The model layer stays fully open: which provider to pay, whether to plug in a local ComfyUI, is the creator's call.
Data sheet
| Item | Value |
|---|---|
| Repo | HBAI-Ltd/Toonflow-app (MIT, TypeScript monorepo) |
| Stars / forks / watchers (snapshot at collection) | 18,468 / 3,283 / 82 |
| Created | 2026-01-29 |
| Runtime and front end | Bun 1.3.14 + Express (server), Vue 3 (web), Electrobun (desktop) |
| Client forms | Windows / macOS / Android ARM64 / Docker / Linux server |
| UI languages | 21 |
| Source | depth-1 clone of GitHub main (2026-10-20) plus close reading of README, the repo's AGENTS.md and packages source |
One canvas per short drama: the four-step workflow
The README's production loop is four steps, and all four happen on the same canvas:
- Script and storyboard: story, character sheets and shot descriptions are organized in text nodes, co-written with a language model, then reviewed and revised by hand;
- Character and scene assets: reference images are imported or produced by image-generation nodes - character turnarounds, scene plates, storyboard frames - locking the visual key of the whole piece;
- Video shots: text and image references are wired into video-generation nodes, a video model and generation mode are picked, and clips are generated shot by shot;
- Preview, organize, download: images and clips are previewed and arranged on the canvas, then exported for downstream editing.
What each step supports - how many references, how long, which resolution, whether audio exists at all - depends entirely on the model and provider chosen for that shot. Toonflow does not pretend to a unified capability surface, and the README says so in its FAQ.
The node system: eight built-ins, everything else via the plugin market
packages/nodes ships eight built-in node types, exactly covering "text, image, video, audio, plus a director":
| Node | Responsibility |
|---|---|
textNode | script, storyboard and setting text, with LLM-assisted rewriting |
imageNode / imageGenerationNode | reference-image management and image generation for turnarounds, scene plates and storyboard frames |
videoNode / videoGenerationNode | shot-clip management and multi-reference video generation |
audioNode / audioGenerationNode | audio assets plus dubbing and effect generation |
director3dNode | 3D director stage: block camera and characters in a virtual scene, preview the shot, then hand it to video generation |
Around the nodes sit three scaffold layers with a hard boundary: packages/nodeScaffold offers only generic node infrastructure and host interfaces, cross-plugin shared components and business logic live in the standalone packages/nodeShared package, and plugin-specific components, prompts and presets must stay inside their own plugin - the repo's own AGENTS.md writes this boundary as a rule. Above that sits the plugin market: storyboards, panoramas, timelines, even mini-games can be plugged into the canvas. Plugin-ization is design, not hack.
Provider layer: bring your own keys, your own ComfyUI, and an open-sourced official router
packages/providers is the supplier system born from the third refactor: third-party API keys are configured in-page, and custom provider adapters plug in local ComfyUI workflows and local LLMs. The official relay platform TF-Router is open-sourced as its own repo (HBAI-Ltd/TF-Router) so anyone can deploy and audit it; the team signed an annual Seedance contract themselves and passed Seedance 2.0 through at cost during the launch window.
The README reports one real production case, which calibrates what this tool costs to run:
| Stage | Model | Recorded cost |
|---|---|---|
| Language (script and storyboard co-writing) | Claude Opus 4.6 | about CNY 10 |
| Images (character and scene plates) | GPT Image 2 | under CNY 1 |
| Video (shot clips) | Seedance 2.0 | about CNY 120 |
| Total | roughly 2 hours of work for a ~2-minute cut (demo compressed to 480p) | about CNY 130 |
Opening the craft to machines: agents, MCP, skills
Toonflow's "open agent" stance opens three things: prompts, tools and A2A - custom agent behavior inside, collaboration with external agents outside. packages/teams ships storyboardTeam, a built-in storyboard team; packages/skills distills canvas and workflow experience into reusable skills (three sets: canvas, workflow, v118workflow); packages/mcp together with the server-side utils/mcp exposes canvas capabilities as MCP tools and resources so external tools and services connect over the MCP protocol. The same canvas can be driven by hand or by machine.
Deployment: four clients, one data directory
| Form | Notes |
|---|---|
| Windows / macOS desktop | Electrobun client; the Windows installer detects and installs WebView2, macOS Apple Silicon opens by drag-in |
| Android ARM64 | the APK embeds a local Bun backend and runs standalone, or scans "device interconnect" to join a shared desktop or remote backend over LAN or public network |
| Docker | one compose command brings up web + server; image based on Bun 1.3.14 with FFmpeg inside; config, plugins and projects live in the named volume toonflowData (container path /app/data/); docker compose down -v deletes that volume |
| Linux server | plain Bun 1.3.14: build:server compiles built-in nodes, tools, web and server, start:server runs it on fixed port 3000 |
Two operational warnings: the service has no login auth of its own, so public deployment must be firewalled or placed behind an authenticating reverse proxy, and for personal remote use the README recommends an ssh -N -L 3000:127.0.0.1:3000 tunnel over opening the port; config, plugins and workspaces default to the repo's data/ (or /app/data/ in the volume), and backup means stopping the service and copying the whole directory.
License, engineering, community
The license moved three times: AGPL-3.0 before v1.0.8, Apache-2.0 plus additional terms from v1.0.8 to v1.1.8, then MIT with all commercial clauses removed after the third refactor - with a non-retroactivity clause keeping old versions under their old license. The team's open letter of 2026-06-08 leaves a pace snapshot: 130 days, 20 releases, 800+ commits, 213,765 lines of code, two refactors already behind it.
Engineering-wise it is a complete monorepo: apps/ holds web (Vue 3), server (Bun + Express), desktop (Electrobun), mobile and updateServer; packages/ adds, beyond nodes / providers / skills / teams / mcp, a unified file entry (file), a bundled ffmpeg, i18n (21 UI languages) and the scaffolds. Community-wise it holds Gitee GVP and AtomGit G-Star No.540 certifications plus several Trendshift Repository of the Day / Week / Month badges, with Discord and WeChat groups maintained in parallel.
Boundaries to know
- generation capability (references, duration, resolution, audio) depends on the model and provider chosen per shot; the platform promises no unified ceiling;
- third-party model APIs may charge, and local ComfyUI / LLM paths require your own environment and compute;
- port 3000 ships without login auth - exposing it directly to the public internet is running naked;
- the Android build targets ARM64 devices only, and the Windows desktop depends on the WebView2 runtime.