open-ai-canvas (影策): a self-hosted canvas for AI film and short-drama production

What 影策 solves for AI film and short-drama teams

Generating a shot is easy. Keeping a hundred shots, their character references, their prompts and their regenerated variants in one place is not. Most AI video work ends up spread across a chat window, a folder of downloaded clips and a spreadsheet. 影策 (open-ai-canvas) targets that gap. The README describes it as an open source AI film and short-drama workbench that organizes creation on a free canvas and manages scripts, characters, scenes and storyboards through structured workflows, with image, video, audio and text generation handled by one task system.

The intended user is a small production team or a solo creator who already has model API access and wants the production layer on top. It is not a model. It is the place where prompts, references, storyboards and outputs live, and it forwards generation work to external channels you configure. The README's own list of capabilities includes a 3D director's stage, a timeline editor with subtitle transcription and server-side final export, and a cloud Agent that supports persistent conversations and canvas summaries. That last item is explicitly marked as a read-only stage, so the Agent is not yet the automation layer the name suggests.

Canvas, backend and task worker: how the pieces connect

The README's architecture diagram is unusually direct about the split. The browser side is a React workspace with the canvas, task center and asset library, using Zustand and localForage for local state and fallback caching, and reaching the server over authenticated API calls and SSE. The backend is Go with Gin handlers feeding a service layer and then repositories and models, backed by SQLite locally or PostgreSQL plus Redis in deployment, with an async task worker, permissions, asset storage and a model relay. External model channels sit behind a provider and outbound layer.

Two details in the repository files matter more than the diagram. First, the frontend routes business API calls through web/src/services/api/request.ts, so the proxy target is a single point of configuration; the README notes the dev server proxies /api to http://127.0.0.1:8080 by default and that VITE_API_PROXY_TARGET overrides it. Second, in production Nginx serves the built frontend and proxies the backend, so only the web entry point needs to be public. SSE is only exempted from proxy buffering on explicit streaming paths, which is the kind of detail that decides whether task progress updates arrive incrementally or in one lump.

Concurrency is configured, not automatic. The Compose file sets CANVAS_WORKER_CONCURRENCY and CANVAS_CHANNEL_CONCURRENCY, both defaulting to 3. Those two numbers are the practical ceiling on how much generation work runs at once, and they are separate: one limits the worker pool, the other limits per-channel pressure.

Installing open-ai-canvas from source and running it locally

The README lists three prerequisites: Bun for the frontend and docs site, Go 1.25 for the backend, and Docker Compose only if you use containers. The host-machine path uses two terminals and keeps development data in a git-ignored directory.

First clone and create the local data and cache directories:

git clone https://github.com/ddcat-ai/open-ai-canvas.git
cd open-ai-canvas
mkdir -p .local/project-workbench-debug .local/cache/go-build .local/cache/go-mod

Then start the backend in one terminal. These environment variables point it at 127.0.0.1:8080 and keep the Go build and module caches inside the repository:

cd backend
CANVAS_BACKEND_ADDR=127.0.0.1:8080 \
CANVAS_BACKEND_DATA_DIR=../.local/project-workbench-debug \
GOCACHE=../.local/cache/go-build \
GOMODCACHE=../.local/cache/go-mod \
go run ./cmd/server

In the second terminal, install frontend dependencies with the lockfile and start the dev server:

cd ../web
bun install --frozen-lockfile
bun run dev

The README says to open http://localhost:3000, register the administrator account on first use, and configure model channels in settings. Windows PowerShell users can instead run .\scripts\start-local.ps1 from the repository root. For container work, docker-compose.dev.yml gives hot reload and docker-compose.local.yml builds and runs a release image; the default frontend port is 3000 and the backend port is 8080, overridable with CANVAS_WEB_HOST_PORT and CANVAS_BACKEND_HOST_PORT. There is also a one-line server install, curl -fsSL https://raw.githubusercontent.com/ddcat-ai/open-ai-canvas/main/scripts/install-server.sh | sudo bash, which installs Docker, pulls the source, generates a protected .env and starts PostgreSQL, Redis, the backend and the web frontend, with default access at http://server-ip:3000. A second script, install-server-image.sh, deploys from GHCR images without source.

The security defaults are the deployment decision

The README does not treat security as an appendix, and the defaults are deliberately closed. CANVAS_REGISTRATION_ENABLED defaults to false, so public deployments should never accept new registrations. CANVAS_ALLOW_PRIVATE_UPSTREAMS defaults to false and the backend rejects local, private and link-local model addresses; development against a trusted private gateway requires listing exact hosts in CANVAS_ALLOWED_PRIVATE_UPSTREAM_HOSTS, and the README warns against the blanket allow switch. CANVAS_CORS_ORIGINS defaults to http://localhost:3000 and the README says not to use * on the public internet. Backend port 8080 is meant to stay inside the Compose network.

This is a real constraint rather than a formality. If your model provider is reachable only on an internal address, the default configuration will refuse the connection and you must name the host explicitly. That is the correct default for a tool that stores API keys and generated media, but it means the first hour of setup is configuration work, not generation work. The README also states that user API keys should not appear in URLs, logs, error reporting or long-term plaintext server storage, and points security reports at SECURITY.md rather than public issues.

Where open-ai-canvas is the wrong tool

The README is candid that the project is still in rapid development and that data structures and external interfaces may change. That is the first limitation: an upgrade can move the ground under a production project. The documentation points to a system update document covering update flow, database migrations, backups and rollback, so the path exists, but the README itself does not document rollback steps, and anyone running a long production project should read that document before the first upgrade rather than after.

The cloud Agent is the second limitation. The README describes it as supporting persistent conversations, canvas summaries and streaming event replay, then says it is currently in a read-only stage and that real-environment capability is governed by the documentation and acceptance checklist. Treat it as an interface preview, not as the automation layer that drives a production pipeline.

Third, subtitle transcription has a hard external dependency. The .env.example states that timeline subtitle transcription is performed by a local whisper.cpp service reached over HTTP, that CANVAS_WHISPER_BASE_URL should point at it (for example http://127.0.0.1:8082), and that without it the transcription task fails explicitly. There is no bundled fallback. If your workflow depends on subtitles, you are running two services, not one.

Finally, this is not a hosted product. There is a public demo at ddcat.pronhubcn.com with the credentials test/test123456, but the README frames the default deployment as suitable for personal, local or trusted environments, not as a public multi-user service without additional security configuration.

open-ai-canvas versus ChatGPT Canvas and Canva

Search interest in this project is tangled up with a different product. ChatGPT Canvas is a document and code editing surface inside ChatGPT; open-ai-canvas is a self-hosted production workbench that happens to use a canvas metaphor. They share a word and almost nothing else. ChatGPT Canvas does not manage storyboards, model channels or generation queues, and open-ai-canvas does not provide a chat assistant in the ChatGPT sense; its Agent is explicitly read-only at this stage.

The closer comparison is Canva, which people also search alongside this project. Canva is a hosted design tool with templates and a browser editor, and it does not run on your hardware or talk to your own model endpoints. open-ai-canvas asks you to supply Bun, Go, a database, Redis in deployment and at least one model channel, and in exchange the assets, keys and project data stay in your environment. That trade is the entire point: more setup, more control.

If what you actually want is a chat-based canvas for writing and code, neither this project nor Canva is the answer. If what you want is a place to organize a short drama across dozens of generated shots with your own model keys, the comparison set is much smaller.

Licence, upstream and what an upgrade costs

The project is MIT licensed, and the README states that 影策 is a second development based on an early version of basketikun/infinite-canvas, with upstream authors and contributors retaining rights and attribution for their code. There is a NOTICE file at the repository root, and the README links to it under upstream declaration. If you fork or redistribute, read NOTICE and LICENSE together; that is a factual statement about the repository, not legal advice.

The build has one licence-adjacent detail worth knowing before you plan a private deployment. The frontend Dockerfile accepts a VITE_TLDRAW_LICENSE_KEY build argument and passes it into the Vite build. tldraw is the canvas library, and the build argument exists because the licence key is supplied at build time rather than runtime. Whether you need a key depends on your use of tldraw, and the README does not discuss it, so verify it against tldraw's own terms before you build a commercial image.

Upgrade cost is a function of the moving interfaces the README warns about. The .env.example shows that CANVAS_AUTO_MIGRATE defaults to true, with the comment that managed production deployments run migrations through a separate migrate service and set this to false. That is the switch to look at first during an upgrade: leaving automatic migration on in a managed environment is a configuration mismatch. For image deployments, the README says to pin CANVAS_IMAGE_TAG to a specific release in /opt/open-ai-canvas/.env rather than using latest, and the releases listed on the repository run on a roughly weekly cadence, so pinning is what keeps an upgrade a decision instead of an event.

Editorial conclusion

Adopt open-ai-canvas if you want a self-hosted canvas that keeps scripts, characters, storyboards and generation tasks in one project, and you are comfortable running Bun, Go and either SQLite or PostgreSQL plus Redis. Do not adopt it as a public multi-tenant service: the README says the default is for personal, local or trusted environments, and the cloud Agent is described as read-only at this stage. Before committing, verify three things: that the model channels you need can be configured in settings, that CANVAS_REGISTRATION_ENABLED stays false on any reachable host, and that your deployment pins CANVAS_IMAGE_TAG to a specific release instead of latest.

Frequently asked questions

Official sources

1. ddcat-ai/open-ai-canvas on GitHub
2. License: MIT
3. Project website
4. README
5. Releases