Huobao Canvas: a node-based canvas for chaining AI image and video models

Four node types and typed wires on an infinite canvas

The model is a canvas rather than a chat interface, and the readme describes it as an open-source, node-based AI creation canvas where upstream outputs flow into downstream inputs. You place text, image, video and group nodes on an infinite canvas and wire them together, and the pipeline possibilities named are text to image, image to video and reference to video, with the freedom to mix and match models. The four node types and the typed connection rules are described as the canvas-as-workflow feature, and the typed rules are enforced with a drop-point menu on drag-out, which is the mechanism that prevents invalid wiring rather than letting you build a graph that fails at run time. The editing experience is listed as a separate capability: undo and redo, auto-layout, box selection and zoom, along with upstream outputs auto-injecting into downstream nodes. A node graph is a good fit for this problem because a generation pipeline is genuinely a graph, and the alternative is a folder of scripts and a lot of copying of URLs and prompts between them.

Eleven providers with their native request formats handled

The provider list is the reason to pick this over a script that calls one API. The eleven named are OpenAI, Anthropic, Gemini, Qwen, Volcengine, DeepSeek, MiniMax, Moonshot, Zhipu, Vidu and Xiaomi MiMo, and the claim is native request and response adapters for all of them, so that you add your key and it works. The model coverage is listed in three bands. The chat models include GPT, Claude, Gemini, Qwen3, DeepSeek, Kimi, GLM and MiMo. The image models include GPT Image 1.5 and 2, Gemini Image, Doubao Seedream and Wan. The video models include Wan 2.7 and 3.0 in text to video, image to video and reference variants, along with Seedance, Vidu and MiniMax. The per-provider auth schemes differ and are handled, with Bearer, an x-api-key header, an x-goog-api-key header and a Token variant. Dual-endpoint models are called out specifically, where the same model name covers both text to image and image edit, and the generation mode is switched inside the canvas with connected references detected automatically. The settings page holds per-provider keys, connectivity tests, model toggles and custom models.

The run queue is why the server exists

The server-side run queue is the feature that separates this from a pure browser tool, and the reasoning is about long generations. Model calls execute on the server, which means you can refresh the browser or switch browsers and the tasks survive, and async video tasks are polled server-side with a two-hour budget so long renders can run. That two-hour budget is a real constraint rather than a detail, and it is the ceiling on how long a single asynchronous video task can run before the server stops waiting for it. The second reason the server exists is shared state. Canvas data is kept in SQLite, so every browser on the same deployment sees the same canvas, which turns the application from a personal tool into something a team can use with a shared board. The server itself is described as a zero-dependency Node server using node:sqlite and the built-in fetch, handling canvas storage and the run queue, and the desktop application embeds that same server through a utilityProcess. The practical consequence for a self-hosted install is that you have a single process serving the frontend, the API and the reverse proxy to the providers, with a data directory on disk.

Two catalog modes, and what happens to your keys

The catalog modes decide who talks to the model providers, and the key handling decides where your credentials live. In official direct mode, which is the default, the application talks to providers in their native formats and works standalone with your own keys. In gateway mode, the canvas plugs into any OpenAI-compatible gateway, with the project's own service named as an example, and one key covers everything. The key model is described as bring your own key with the keys staying in your browser, and on self-hosted deployments they mirror to the server automatically, which is a distinction worth understanding. The first-run flow offers a quick setup that writes keys and gateway URLs for all eleven providers in one click, or a manual setup where you enter each provider's official key with connectivity tests. Keys are kept in browser localStorage by default, and the mirror to the server happens on self-hosted deployments, which means a self-hosted instance does hold your provider keys on its disk. The docker-compose file confirms this by mounting a named volume for the key mirror alongside the canvas and the queue, so the data volume holds SQLite canvas data, the key mirror, the run queue and the generated result files.

Docker, desktop app and local development are the same codebase

Three deployment shapes are offered and the architecture section shows why they are the same project. The repository holds a web application built with Vue 3.5, Vite 5, Vue Flow for the canvas, Naive UI for components, Pinia for state, vue-i18n for translations and Tailwind for styling, a server application, a desktop application, and a docker directory with the all-in-one image. The desktop application is an Electron shell in which the server is embedded through a utilityProcess, bundled with esbuild and packaged with electron-builder into dmg and exe files. The Docker image is described as a single image containing the frontend build and the server bundle for amd64 and arm64. The quickest way to see it running is the container:

docker run -d -p 8080:16812 -v canvas-data:/app/data huobao/huobao-canvas:latest
# Open http://localhost:8080

The compose file adds a Watchtower service on a daily interval with rolling restart and cleanup, so the container tracks new images, and it is gated by a label so only explicitly marked containers are updated. The Dockerfile is a two-stage build from node alpine, with the frontend built with Vite and the server bundled into a single file with esbuild, and the runtime stage runs a single process that serves the static files, the API and the proxy to the providers, with a healthcheck against the healthz endpoint and a volume for the data directory. The local development path is a clone and a pnpm install and dev, with the server run separately.

Licensing, unsigned builds and the state of the release

Two practical caveats are worth reading before you install. The first is licensing. The badge in the readme names CC BY-NC-SA 4.0, which permits sharing and adaptation for non-commercial purposes only, while the licence field for the repository says Other, a custom licence GitHub cannot classify, and points to the LICENSE file. Those two statements are not the same and the licence file is the one to read, particularly if you intend to run this for commercial work, and the readme also links a donation page. The second is code signing. The macOS builds are unsigned, so on first launch you right-click and choose Open, or run the xattr command to strip the quarantine attribute, and the Windows builds are unsigned too, so SmartScreen needs More info and then Run anyway. The release history is short, with v1.0.2 on 2026-10-02, v1.0.1 on 2026-09-18 and v1.0.0 on 2026-09-10, so the project reached a 1.0 line very recently and the interface is still likely to change. The readme is multilingual, with English, Simplified Chinese, Japanese and Korean versions, and the interface itself switches between those four languages.

Editorial conclusion

Huobao Canvas is a good fit for a creator or developer who wants to chain several image and video models in one place, who wants the provider request formats handled for them rather than by hand, and who wants long video renders to survive a browser refresh. It is the wrong tool if you need a batch pipeline that runs headless on a schedule, since the run queue is a server-side queue for interactive sessions rather than a job system, and it is the wrong tool if you need a permissive licence, because the badge in the readme says CC BY-NC-SA 4.0 while the licence field for the repository says GitHub cannot classify the custom file. Before deploying it, read the licence file yourself, decide whether the upstream gateway default is acceptable to you or whether you will point it at your own OpenAI-compatible endpoint, and note that the desktop builds are unsigned, so macOS and Windows will each need an explicit step before they will run. The last push was on 2026-10-02 and the current release is v1.0.2 from the same day.

Frequently asked questions

Official sources

1. chatfire-AI/huobao-canvas on GitHub
2. Issues
3. README
4. Releases