# basketikun/infinite-canvas: a browser-side AI image workbench on an infinite canvas

> infinite-canvas is a TypeScript open source workbench that puts a pan-and-zoom node canvas, AI image generation and a prompt library in one interface, with your API key kept in the browser. It is a tool for iterating on visual ideas, not a drawing app and not a hosted service.

**basketikun/infinite-canvas** — AI AI Agent Agent OpenAI chatgpt2api grok2api flow2api newapi .

- Repository: https://github.com/basketikun/infinite-canvas
- Website: https://canvas.best
- Stars: 7,048 · Forks: 1,766
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/basketikun-infinite-canvas

## What infinite-canvas actually is, and who it is for

The README describes infinite-canvas as an open source workbench for image creation: canvas arrangement, AI image generation, reference-image editing, a chat assistant, a prompt library and asset storage in one interface. The stated use case is exploring visual options and iterating on image results in sequence, which is a different job from drawing.

That distinction matters, because most search traffic for the phrase lands on note-taking and sketching apps. The shared phrase "infinite canvas" describes a pan-and-zoom surface, and this project uses that surface as an orchestration layer for generation calls rather than as a place to draw with a stylus. The README lists multi-canvas projects, node drag and zoom, connections between nodes, a minimap, undo and redo, and import and export as canvas features. On top of that surface sit text-to-image, image-to-image, reference-image editing, text question answering, and audio and video generation.

The audience is narrow but real: someone who already has an OpenAI-compatible image endpoint, or a relay in front of one, and wants a visual workspace instead of a chat box. The README points people without a suitable image API at a separate project by the same author, chatgpt2api. It also lists a local Canvas Agent that connects Codex or Claude Code over MCP, a Codex app plugin that registers MCP and tries to start that agent, and a plugin system that installs remote node plugins from a URL with a TypeScript SDK for writing your own. Those pieces suggest the intended user is comfortable reading repository docs and running a container.

## Where your API key lives, and what the server never sees

The architecture is the interesting part, and the Dockerfile states it plainly. The build stage uses oven/bun:1.3.13 to produce the Vite frontend, then the runtime image is nginx:1.27-alpine serving only static files. A comment in the Dockerfile says the runtime image starts the static frontend only, and that AI requests go directly from the browser to the user's own endpoint.

So the container is a file server. There is no backend that proxies your prompts. The README says the AI API key, base URL, canvases, assets and generation records are stored in the browser by default, and that the prompt library connects from the frontend and caches into IndexedDB. Practically, that means the browser holds credentials and calls your endpoint across origins, which is why the nginx.conf file ships with the image. If your endpoint does not send permissive CORS headers, the browser request fails before any image is produced, and no amount of container configuration fixes it from the server side.

The nginx.conf file is also the place a reverse proxy would normally be configured, and the image copies it to /etc/nginx/conf.d/default.conf. A runtime entrypoint script, web/docker-entrypoint.sh, is installed as /docker-entrypoint.d/40-runtime-config.sh, which is the standard nginx mechanism for generating configuration at container start. The docker-compose.yml exposes an optional analytics block, commented out by default, with separate variables per provider: ANALYTICS_GA4_ID for Google Analytics 4 and ANALYTICS_BAIDU_ID for Baidu. The comment says each variable is independent and that filling one in enables that provider. Since the frontend is static and analytics is off by default, a default deployment sends nothing anywhere except to the endpoint you configure.

## Installing infinite-canvas with Docker and running a first generation

The README gives two paths: local development with Bun, or Docker. Docker is the shorter one. The compose file references a prebuilt image on GHCR, so the clone step is only needed to get the compose file itself.

```bash
git clone git@github.com:basketikun/infinite-canvas.git
cd infinite-canvas
docker compose up -d
```

After that the app listens on port 3000, and the README says you can open http://localhost:3000. The compose file maps 3000:3000 and sets restart: unless-stopped, so the container comes back after a reboot.

If you prefer building from source, the README's development path uses Bun inside the web directory:

```bash
cd web
bun install
bun run dev
```

The first real use is configuration, not generation. The README says that on first open you go to the settings in the top right corner and fill in your own OpenAI-compatible Base URL and API Key. Until those two fields are set, generation calls have nowhere to go. Once they are set, create a canvas, add a node, and issue a text-to-image request; the result is inserted back onto the canvas as a node you can connect to further nodes.

If your provider's request shape differs from the default OpenAI-style call, the README says you can customize the image and video call scripts. That is the escape hatch for relay services and self-hosted backends, and it is also the point where you leave the documented path and start reading the plugin and script sources yourself.

The optional analytics block in docker-compose.yml is worth knowing about even if you leave it off:

```yaml
services:
  app:
    image: ghcr.io/basketikun/infinite-canvas:latest
    container_name: infinite-canvas
    ports:
      - "3000:3000"
    restart: unless-stopped
```

That is the whole default service definition. Everything else in the file is commented out.

## The data compatibility warning is the real constraint

The README carries a caution block stating that the project is in a development phase, that historical data compatibility is not guaranteed, and that local storage formats may be adjusted directly. It then suggests that anyone who needs stable maintenance of their own branch should fork it and develop independently.

Read that as an operational fact rather than boilerplate. Because canvases, assets, generation records and the prompt cache live in browser storage, a format change on upgrade can strand work that exists only in one browser profile. There is no server-side database to migrate and no documented export guarantee beyond the import and export feature listed for canvases. If you are planning to accumulate months of generated assets, the storage layer is the part to test before you commit, and the README does not document a migration path or a rollback procedure for a storage format change.

A second limitation is architectural. Because the browser calls your endpoint directly, the deployment is single-user by construction. There is no shared workspace, no server-side key escrow, and no way to hand a colleague a link that works with your credentials. Teams that need a shared asset library with server-side keys are looking at a different class of tool. The project also assumes a working image endpoint with correct CORS behaviour; without one, the canvas renders and generates nothing.

The licence is the third thing to check rather than assume. The repository listing shows AGPL-3.0, while the README's licence section points at a LICENSE file and describes MIT terms, saying anyone may use, copy, modify, distribute, sublicense and use the project commercially, including in closed-source products. Those two statements do not agree, and the LICENSE file at the repository root is the only place that resolves it. Anyone planning to embed this in a product should read that file directly and, if the terms matter commercially, get their own legal review. This article is not legal advice.

## How it differs from Excalidraw, tldraw and the note apps people search for

Most tools that get called infinite canvas are drawing or note-taking surfaces. Excalidraw and tldraw give you a pannable board where you place shapes, text and freehand strokes; the output is a diagram or a sketch, and any AI feature is an add-on to the drawing. Goodnotes and Notability give you the same surface for handwriting, with pages that never end. Procreate is a raster painting app whose canvas size is a document setting, not an unbounded workspace.

infinite-canvas inverts the relationship. The canvas is a dependency graph for generation: nodes hold prompts, reference images and results, and connections express which output feeds which input. The README's canvas assistant works on selected nodes and their upstream nodes, holds a conversation, generates images and inserts results back into the canvas. That is a workflow shaped around iteration on generated images, and the canvas exists to keep the lineage visible. You cannot draw on it in the sense those other tools mean, and you cannot take handwritten notes on it.

If your actual need is a whiteboard that happens to have an AI button, a drawing tool is the better fit and this project is the wrong one. If your need is a whiteboard whose nodes are generation calls with parameters and upstream references, the drawing tools will fight you. The nearest neighbour in spirit is a node-based generation front end, and the difference there is hosting: this one is a static frontend you run yourself, with credentials in the browser.

## Plugins, the local agent, and what the docs do not cover

The plugin system installs, enables, updates and uninstalls remote node plugins by URL, and ships a TypeScript SDK for writing canvas node plugins. There is a plugins/infinite-canvas directory in the repository layout described as a Codex app plugin, which the README says registers MCP automatically and tries to start the local agent on install. The canvas-agent directory holds that agent, and the README links its own README for details.

This is the most ambitious part of the project and the least verifiable from the documentation. Installing plugins by URL means the runtime trusts remote code, and the README does not describe a signing scheme, a permission model or a review process for plugin sources. The Codex plugin's automatic MCP registration and agent launch are described as best-effort ("tries to start"), which is honest but leaves failure handling undocumented.

Maintenance is easy to state factually. The last push to the default branch was on 2026-08-18, and v0.16.0 was released the same day, following v0.15.0 and v0.15.1 on 2026-08-07. The repository is not archived. The version cadence in the release list is weeks apart, and the README's own caution block tells you what that cadence means for your stored data. There is a docs/ tree with quick-start, features, Render and Docker deployment pages, a canvas node manual and a shortcuts page, plus a todo list under docs/content/docs/progress. The README does not document rollback, backup or restore for browser-stored canvases, so plan export before you upgrade.

## Conclusion

Adopt infinite-canvas if you already hold an OpenAI-compatible image endpoint and want a self-hosted canvas where prompts, reference images and generated results live next to each other. Skip it if you need a stable local storage format across upgrades, a hosted multi-user service, or an offline drawing surface: the README warns that local storage formats may change without compatibility guarantees. Before committing, check the LICENSE file against the AGPL-3.0 licence metadata shown in the repository listing, and confirm that your image endpoint accepts the default OpenAI-style call shape or that you are ready to write a custom call script.

## FAQ

### What is infinite-canvas?

It is an open source workbench for image creation that combines a node canvas, AI image generation, reference-image editing, a chat assistant and a prompt library in one interface. The README describes it as aimed at exploring visual options and iterating on image results.

### Is there a free app that has an infinite canvas?

infinite-canvas itself is free to run: the README's licence section says anyone may use, copy, modify, distribute, sublicense and use it commercially. Note that the repository listing shows AGPL-3.0 while the README describes MIT terms, so read the LICENSE file at the repository root. Generation still costs whatever your own API endpoint charges.

### What Android apps have infinite canvas?

The documentation does not mention Android, iOS or any mobile client. The deployment paths described are a Bun development server and a Docker image that serves a static frontend on port 3000, both of which imply a desktop browser.

### how to use infinite canvas

Run it with docker compose up -d, open http://localhost:3000, then fill in your OpenAI-compatible Base URL and API Key in the top-right settings. After that you create a canvas, add nodes, and issue generation requests whose results are inserted back onto the canvas.

### Is OneNote an infinite canvas?

This project does not document OneNote's behaviour, and infinite-canvas is not a note-taking app. If you want a note surface, the README's canvas is a node graph for generation calls, not a page for handwriting.

## Sources

- [Official documentation](https://canvas.best)
- [Official README](https://github.com/basketikun/infinite-canvas#readme)
- [Project repository](https://github.com/basketikun/infinite-canvas)
- [Release notes](https://github.com/basketikun/infinite-canvas/releases)

---

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