tigerowo/infinite-canvas: a self-hosted AI creation workbench built on a Go and Next.js canvas

What infinite-canvas actually solves, and who ends up using it

Most image and video generation work happens in a chat box. You write a prompt, you get a picture, you lose the prompt, and the reference image that produced the good result is three browser tabs away. infinite-canvas attacks that specific mess. The README describes it as an open source workbench for image, video and audio creation that puts canvas arrangement, AI image generation, video and audio generation, reference-image editing, a chat assistant, a prompt library and asset storage into one interface.

The target user is not a casual tinkerer. The repository is a Go backend plus a Next.js frontend, deployed with Docker, and it expects you to bring your own model endpoints. The README points at OpenAI-compatible Images API and Responses API endpoints, mentions image-to-image, reference-image editing, streaming responses and Base64 image returns, and notes that Seedance 2.0 can be reached through the Volcano Ark Agent Plan. If you do not have an API key for something, the canvas has nothing to draw with. The README itself links to a separate free image-generation project for people who are stuck on that step.

The project also carries a sponsor block for two API providers, one for image and video models and one for MiniMax H3 video generation. That is worth naming plainly: the README is partly a distribution channel for those services. It does not invalidate the software, but it tells you where the author's incentives sit.

Node graph, Agent and director stage: how the pieces connect

The architecture is visible from the repository layout and the Dockerfile. The Go server lives in main.go with handler, middleware, model, repository, router and service directories. The frontend is the web directory, built with bun. In the runtime image, the Go binary starts first and listens on 8080 inside the container, while Next.js serves pages on 3000 and proxies /api/* to the internal Go process. So the browser only ever talks to 3000.

The canvas model is a node graph. Nodes can be dragged, scaled and connected, and the README lists multiple canvas projects, a minimap, undo/redo and import/export. Generation nodes carry their own camera settings: aperture, focal length and lens parameters are stored per node, written into the prompt automatically, and copied along with the node. That is an unusual design decision. It means the visual language of a shot lives in the graph rather than in a separate settings panel, which is good for reproducibility and awkward if you want to change one parameter across twenty nodes.

The Agent is the part that distinguishes this from a plain node editor. According to the README, it analyzes the selected node and its upstream nodes, plans a task, optionally follows a selected Skill, generates an image or video, and inserts the result back into the canvas. The director stage is a separate 3D scene where you place characters, models, panorama environments and camera positions, manage shots, take screenshots, and send a camera view back as a connected image node. Panoramas can be generated from text, from a reference image, or imported as a local 2:1 image and then used as the director stage environment.

Storage is layered: SQLite by default, with MySQL and PostgreSQL drivers present in go.mod, plus local IndexedDB on the frontend, S3-compatible object storage and Cloudflare R2 mentioned in the README. The .env.example also shows driver selection through STORAGE_DRIVER. That is a lot of moving parts for a project at version 0.7.x.

Installing infinite-canvas with Docker and reaching the admin prompt page

The README gives a Docker path as the primary route. Clone the repository, copy the environment template, edit the credentials, then build and start. The .env.example sets ADMIN_USERNAME to admin and ADMIN_PASSWORD to infinite-canvas, and warns in a comment that JWT_SECRET should be changed for a real deployment. Change both before the first start, because the admin account is created on first boot.

git clone https://github.com/tigerowo/infinite-canvas.git
cd infinite-canvas
cp .env.example .env
# edit the default account and password first
docker compose up -d --build

The compose file maps port 3000 and mounts ./data into /app/data, so the SQLite file and prompt data survive a container rebuild. After the containers come up, the README says the default port is 3000 and the app is reachable at http://localhost:3000. If you want the prompt library populated from the GitHub projects the README says it scrapes, the README points you to http://localhost:3000/admin/prompts.

For non-Docker development the README splits the process in two. The Go backend runs from the repository root after copying .env, and the frontend runs from web with bun. The .env.example notes that the frontend dev proxy defaults to http://127.0.0.1:8080 and that API_BASE_URL can override it if the backend runs elsewhere.

cp .env.example .env
go run .

# open a second terminal
cd web
bun install
bun run dev

The README also documents a source-build compose file, docker-compose.local.yml, for people who want the local build rather than the published image. One detail from the Dockerfile that matters operationally: the image sets PROMPT_DATA_DIR to /app/data/prompts and creates that directory, so prompt data belongs under the mounted volume, not inside the container layer.

If you use New API, the README gives a one-line configuration string to paste into the chat settings dialog, of the form https://infinite-canvas-cpco.onrender.com?apiKey={key}&baseUrl={address}, which opens a dialog with the key and base URL prefilled. The README says you can replace that host with your own deployment address.

The data-compatibility warning is the real adoption risk

The README carries an explicit caution block, and it is not boilerplate. It states that the project is in a development phase, that historical data compatibility is not guaranteed, and that database structures and storage formats may be adjusted directly. It then recommends forking and developing independently if you need a stable branch of your own.

Take that at face value. A node graph is a persisted document format. If the shape of nodes, camera parameters or generation history changes between releases, an upgrade can leave your existing canvases unreadable or partially migrated. There is no migration tooling described in the README, and no rollback procedure is documented. The repository does carry a CHANGELOG.md and a VERSION file, and releases v0.6.0 through v0.7.1 landed within roughly two weeks of each other, which is fast enough that format churn is plausible rather than theoretical.

There is a second limitation that the README implies rather than states. The whole tool is a client for external model APIs. Latency, rate limits, content filters and per-image pricing come from whoever you point it at. The workbench adds concurrency, history merging, failure details and asset reuse on top, but it cannot make a slow or restrictive endpoint pleasant. If your provider returns errors under load, the canvas shows failures; it does not queue around them in any way the README describes.

Finally, this is the wrong tool for a large class of people who search for the phrase. It is not a note-taking canvas, not a whiteboard, not a drawing app for iPad, and not a replacement for OneNote or GoodNotes. The name overlaps with a crowded category of infinite-canvas apps, and the README makes no claim in that direction at all.

How it differs from ComfyUI and from hosted generation tools

The closest functional comparison is ComfyUI, and the difference is where the models run. ComfyUI executes diffusion models locally on your own GPU and gives you a node graph over the sampling pipeline itself, with control over checkpoints, samplers, LoRAs and latent space. infinite-canvas does not run models. It orchestrates remote APIs, so its nodes represent API calls, references and results rather than sampling steps. That makes it far lighter to run (a Go binary and a Node process, no CUDA) and far less controllable over the generation process. You cannot fix a seed and change a sampler, because there is no sampler in the graph.

The second comparison is hosted generation tools, which give you a prompt box and a gallery. infinite-canvas trades their zero-setup experience for self-hosting, your own keys, your own storage and a graph you can arrange. The README's sponsor entries make the trade explicit: the project expects you to bring a paid or free API account from somewhere.

There is also a lineage point the README states directly. This repository is based on basketikun's frontend-only infinite-canvas, merged with HuFakai's image-generation-enhanced version, with more complete video and video-generation configuration and a backend cloud sync mechanism added so it no longer depends on being purely frontend. If you only need the frontend behaviour, the upstream projects exist and are named.

Licence, maintenance and what an upgrade actually costs

The licence is AGPL-3.0, referenced from the LICENSE file and the badge in the README. The practical consequence: if you modify the code and let other people use it over a network, the AGPL's network clause is generally read as requiring you to offer those users the corresponding source. Running it privately for yourself does not trigger that. This is a description of the licence, not legal advice; if you plan to offer it as a service, get your own reading.

The README also asks that secondary development and pull requests keep the original author information and the frontend page identifiers. That is a request, not a licence term, but it tells you how the maintainer wants forks to behave.

On maintenance, the last push to the default branch was on 2026-09-17, and the recent release tags are v0.7.1 on 2026-09-12, v0.7.0 on 2026-09-09 and v0.6.0 on 2026-08-30. The repository is not archived. That release cadence is the thing to weigh against the compatibility warning: the project is moving, and moving releases are exactly when stored formats drift.

Upgrade cost is therefore mostly your own. The compose file uses pull_policy: always on the ghcr.io image, so a plain docker compose up will fetch whatever latest is at that moment. If you want to pin, override the tag yourself. Back up the ./data directory before upgrading, since that is where the SQLite database and the prompt data directory live. The README does not document a downgrade path, so the backup is the rollback plan.

Editorial conclusion

Adopt it if you already have OpenAI-compatible image and video endpoints and want a self-hosted node canvas that keeps prompts, references and results in one place, and if you can tolerate a project whose README states it does not guarantee historical data compatibility. Do not adopt it if you need a stable schema for long-lived assets, or if you want a general-purpose infinite canvas for note taking: this is a generation workbench, not a whiteboard. Before committing, verify three things yourself: that your provider implements the Images or Responses API the way the README describes, that your DATABASE_DSN points at an absolute path under /app/data in Docker, and that you are willing to publish modifications under AGPL-3.0 if you expose the service to others.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. tigerowo/infinite-canvas on GitHub