# TapCanvas and what an agent native canvas means for video production

> TapCanvas is a TypeScript monorepo that puts ideas, scripts, character and scene assets, storyboards, images, video and the finished cut on one infinite canvas driven by agents. It is open source under MIT, and its own documentation is careful to say the fixed one-click film entry point is not live yet.

**anymouschina/TapCanvas** — 面向 AI 影视、漫剧与多模态内容生产的 Agent 原生无限画布, 主推一键成片 agent，编排可控

- Repository: https://github.com/anymouschina/TapCanvas
- Website: https://lluban.cn
- Stars: 681 · Forks: 165
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/anymouschina-tapcanvas

## One canvas holding the plan, the assets and the run history

TapCanvas places creative work, scripts, character and scene assets, storyboards, images, video and the final cut into a single traceable canvas workflow. The distinction it draws is between itself and a one-shot model caller: agents read the real project and canvas state, choose skills and tools on their own, execute a multi-step production, and deliver results as nodes, assets and run records.

That is a bigger claim than a prompt box, and the repository layout backs it up. The project is a TypeScript monorepo with an apps directory, a packages directory, a scripts directory and a docs directory, plus an AGENTS.md, a CLAUDE.md, an AI_RUNTIME_ARCHITECTURE.md and a Design.md at the root. The workspace manifest is a private package named tapcanvas-workspace using pnpm 10.8.1, and it declares scripts for each application separately.

The applications named in the root manifest are the web app, the API, the agents bridge and the model gateway. Each has its own filtered script for development, build and test, which is the shape you want in a system where the front end, the protocol layer and the model gateway have to be rebuilt and retested independently:

```json
  "scripts": {
    "dev": "./scripts/dev.sh local",
    "dev:web": "pnpm --filter @tapcanvas/web dev",
    "dev:api": "pnpm --filter @tapcanvas/api dev",
    "dev:agents": "pnpm --filter agents dev",
    "build": "pnpm run build:web && pnpm run build:api && pnpm run build:agents",
    "test": "pnpm run test:web && pnpm run test:api && pnpm run test:agents",
```

The project description calls it an agent native infinite canvas for AI film, animation drama and multimodal content production, and the homepage is lluban.cn. The repository is MIT licensed, is not archived, and the last push was on 2026-10-22.

The release history tells its own story. Version 1.0.0 was published on 2026-04-15 with a note saying there was no energy to maintain two versions and the project was opened up directly, version 2.0.0 came on 2026-08-31 as the polished open source edition, and 2.0.1 followed on 2026-09-21.

## The main chain is canvas, bridge, workflow kernel, workers, evidence

The architecture section describes the main path in one line, and the sequence is the design.

The chain is infinite canvas, then Agents Bridge, then the production workflow kernel, then task and media workers, and finally verifiable delivery. Agents call skills, MCP, sub agents and workflows on demand according to the real project state. Image, video and audio tasks go out through the model gateway into AIGC models, and then a task ledger, queues, leases, idempotency, retries and reconcile, together with real asset URLs and delivery evidence, are what make a long production chain recoverable, traceable and acceptable to review.

Several design choices in that sentence are worth pulling out. The task ledger with leases, idempotency and retries is what turns a multi-hour video generation run from a script that fails halfway into something that can resume. The delivery evidence and real asset URLs are what let a reviewer check that a node produced an actual file rather than a promise.

The Agents Bridge has a documented entry point. Agent native execution is described as a single POST to /public/agents/chat, which enters the DeepSeek Harness Bridge, where the agents take responsibility for semantic understanding, planning, skills, sub agents and a final delivery self check.

The application boundaries are listed too. The web app handles interaction and deterministic canvas execution, the Hono API handles protocol, permissions, tasks and factual evidence, the agents CLI is the TapCanvas Bridge for the DeepSeek Harness, and the model gateway handles model access. The schemas package holds the shared contracts, and the documentation points to an interactive architecture diagram with a guided tour and node explanations.

## The model gateway is yours to configure, with no credentials in the repo

The model access story is the part of this project most likely to surprise an evaluator, in a good way.

Text, image, video and audio models are all accessed through the model gateway in apps/new-api, which handles unified access, metering and dynamic delivery. The front end does not hard code a model list, which means the set of models available to a deployment is a configuration question rather than a code question.

The channel configuration is where the practical detail sits. The project documents built-in channels and describes the discipline around them: newly added channels are disabled by default with an empty key, and they contain no maintainer private credentials. Administrators add their own key, select models from the dynamic catalogue, configure the protocol binding and the price, and then enable the channel. Upgrades preserve existing keys and their enabled state.

That design, a gateway where nothing works until you supply a key, is the correct default for a repository that anyone can clone. It also means the deployment is not a one-command experience. The project ships several channels with a set of chat, image and video models, and a documentation folder with per channel notes and patch SQL files that expand or initialise the configuration.

The payment and verification boundary is stated in the version note as well. The community edition does not provide SMS verification codes or online payment, and the model channels are configured by the user. The hosted commercial product at lluban.cn is a separate product with different features, services and terms, and the documentation is explicit that the online version's core features and styling match the current project, which is a helpful baseline for anyone deciding whether to self host.

## The one-click film entry point is not live yet

This is the sentence to read twice before adopting the project, and the documentation puts it in a highlighted boundary note of its own.

The community edition provides the v135 system workflow and an administrator canvas template entry, which can be executed through an already assembled workflow, and you have to configure a usable agent, image and video model channel before running it. The main text says it directly: the fixed one-click film entry is not yet online.

What is described as the production base supports chapter context, character and scene assets, structured storyboards, continuous shots, first and last frame continuation, video generation and compositing. The qualification is the word requires orchestration. The one-click video production entry point, which the project description leads with, is the piece that is not there in a fixed form yet.

The same note explains the relationship between the video node and the full cut: both share one chapter plan, and media generation depends on real upstream assets. In other words, the plan is a shared artefact and the images are real files, which means a run cannot conjure a video from nothing without the upstream nodes being populated.

The changelog shows how active that area is. A v135 one-click film release on 2026-10-07 synchronised full chapter plot and timeline planning, per item asset creation, per clip prompts and media production, plus the latest creation skills, with the editor and the executor sharing one workflow definition. An earlier entry on 2026-09-20 synchronised a v90 video production workflow and adapted the DeepSeek Harness runtime.

For an adopter, the practical question is whether the orchestration you need is the orchestration that exists. The changelog entries are dated and specific, so the answer is readable in the repository rather than something you have to ask a maintainer.

## The canvas is typed nodes, and the workflow is a reusable DAG

The infinite canvas is described as using strongly typed nodes, ports and connections to organise documents, characters, storyboards, images, video, audio, subtitles and workflows. Typing the ports is what makes a canvas more than a mood board, because it means the connection between two nodes carries a contract rather than a hope.

The collaboration features are the other half of the picture. The project supports reusable DAG workflows, asynchronous workers, failure recovery, sharing and publishing, team scope, and real time canvas state. A reusable DAG is the interesting term: the workflow is a versioned object that can be applied again, and the project mentions a system workflow release file for v135 alongside retained historical executions and generated assets.

Project based assets are the third feature, and it is where the difference from a prompt box shows. The asset library, versions, generation history, task status, delivery evidence and project local metadata accumulate continuously, and successfully generated assets are not discarded by later post processing.

The most recent changelog entry, dated 2026-10-20, is a good illustration of the granularity. A canvas image comparison node was added with four modes, side by side, slider split, opacity overlay and hold to toggle. It can be created from the add node panel or the context menu, and selecting two images and clicking image compare auto creates the node and wires it. The comparison content follows the upstream images in real time, and the mode, split position, opacity and size are stored with the node.

That last detail, that the comparison is a node rather than a modal, is what makes it usable in a production flow. The result is a live artifact in the graph that can be saved, reopened and reviewed, not a transient view.

## Docker Compose with Postgres and pgvector is the deployment path

The repository ships two Compose files, a docker-compose.yml and a docker-compose.prod.yml, and the services section shows what the system needs underneath.

The database is Postgres with the pgvector image, configured with a healthcheck that runs pg_isready against the configured user and database every five seconds, with a timeout of three seconds and thirty retries, and a one gigabyte memory limit. The volume is a named volume rather than a bind mount, so the data survives container replacement.

```yaml
services:
  postgres:
    image: ${POSTGRES_IMAGE:-${DOCKERHUB_REGISTRY:-docker.io}/pgvector/pgvector:pg16}
    environment:
      POSTGRES_DB: ${POSTGRES_DB:-tapcanvas}
      POSTGRES_USER: ${POSTGRES_USER:-tapcanvas}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-tapcanvas}
    ports:
      - "${POSTGRES_PORT:-5432}:5432"
```

The build arguments section is worth a glance, because it shows the intent. There is a comment explaining that a clean clone has no host built web dist, and that the dashboard is built in the image with Bun so local startup never depends on host Node or Bun state. The registry and image variables all have overridable defaults, including a Go proxy and an apt mirror, which is a nod to networks where the default upstream is slow.

The workspace scripts give you the operational entry points. compose:up starts the stack, compose:up:fresh forces a fresh build, compose:init runs initialisation only, compose:down tears it down, and dev:isolated starts a node script for an isolated local run. A separate script called dev.sh takes the local and docker modes, so the same script drives both paths.

## Where TapCanvas is the wrong tool

The first wrong case is a team that wants finished video from a fresh install today. The documentation is explicit that the fixed one-click film entry is not live, that you must configure a usable agent, image and video model channel first, and that media generation depends on real upstream assets. Between a community edition that needs channel configuration and key management, a model gateway whose model list is dynamic, and a workflow that must be assembled before it runs, this is an operational project rather than a download.

The second wrong case is a team that already has a working production pipeline for image or video generation and wants a nicer dashboard. TapCanvas is not a viewer. Its value is in the plan, the assets, the run history and the delivery evidence living in one graph, and that value disappears if you only want to look at finished files. The hosted commercial product is a separate thing with different terms, so the free edition is not a free version of that service.

The third is a language or workflow mismatch. The architecture is built around a chapter based, storyboard driven model for AI film and animation drama. A team producing short form vertical video with no characters, no scene assets and no chapter structure would be paying for a canvas with nothing to put in it.

The alternative worth naming is to keep the generation in the tools you already use and treat the durable artefacts as files. Concretely, a team can run its model calls through scripts, keep prompts and outputs in a repository or an object store, and use a database table to record what was generated when. The difference in approach is real rather than a matter of taste: that route is simpler to reason about and easier to hand over, because the state is in files you can read, while TapCanvas gives you a live graph, typed connections, reusable workflow definitions, resumable long runs and delivery evidence for the price of running a monorepo with a database, a model gateway and an agents bridge. If your production is short and linear, the file based route is enough. If it is long, branching and needs to be resumed and reviewed, that is what this project is built for.

## Conclusion

TapCanvas fits a team building AI generated film, animation or multimodal content who needs the plan, the assets and the run history to live in one reviewable place rather than in a chat log. It is the wrong tool if you want a finished product on day one, because the documentation states the fixed one-click film entry is not yet available and that you must configure your own agent, image and video model channels. Before you plan around it, read the version boundary note, since the hosted commercial product is separate with different features and terms, and confirm that the model gateway you plan to use will accept your own keys.

## FAQ

### What is TapCanvas and what does it do?

TapCanvas is an agent native infinite canvas for AI film, animation drama and multimodal content production. It puts ideas, scripts, character and scene assets, storyboards, images, video and the final cut into one traceable workflow where agents plan and run multi-step production and deliver results as nodes, assets and run records.

### Is the one-click video production feature available in the community edition?

Not yet. The documentation states that the fixed one-click film entry point is not online, while the community edition provides the v135 system workflow and an administrator canvas template entry that can be run through an assembled workflow, once you configure a usable agent, image and video model channel.

### Do I need my own API keys and model channels to run TapCanvas?

Yes. The model gateway handles access, metering and dynamic delivery for text, image, video and audio models, and the documentation says newly added channels are disabled by default with an empty key and no maintainer private credentials, so you add your own key and configure the protocol and price before enabling a channel.

### How do I run TapCanvas locally?

The workspace scripts cover it: dev runs ./scripts/dev.sh local, compose:up starts the Docker stack, compose:up:fresh forces a fresh build and compose:init initialises only. The build and test scripts run the web, API and agents applications separately.

### What is the difference between the TapCanvas community edition and the online version?

The repository states that it is the community edition and that the online commercial version is a separate product with different features, services and terms. The community edition does not provide SMS verification codes or online payment, and the online version's core features and styling match the current project.

## Sources

- [anymouschina/TapCanvas on GitHub](https://github.com/anymouschina/TapCanvas)
- [License: MIT](https://github.com/anymouschina/TapCanvas/blob/main/LICENSE)
- [Project website](https://lluban.cn)
- [README](https://github.com/anymouschina/TapCanvas/blob/main/README.md)
- [Releases](https://github.com/anymouschina/TapCanvas/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anymouschina-tapcanvas