BeefTV is a local first canvas where an agent does the creative work

The canvas is the product, not a panel around it

BeefTV describes itself as a high performance, lightweight, AI native video workspace for the age of AI, and the sentence that explains it is the second one: in a free canvas, connect ideas, models and assets. The description in the repository is that it is a video creation workbench where you connect creative work, models and materials together on a canvas with an agent.

That is a different architecture from the usual generation tool, which is a form with a prompt box and a result panel. Here the project is a graph. Nodes hold prompts, generated media, references and tools, and the connections between them are the workflow: the direction of the arrow is the dependency, and a node downstream of a generated image is a step that uses it.

The reasons the project gives for the canvas are worth reading as design rationale. The four stages it lists are generation, where you produce text, images, video and audio from a prompt or from reference material, organisation, where nodes and connections establish relationships between assets, the creative context and the generation flow, processing, where you crop, annotate, repaint part of an image, split, reference and combine results, and iteration, where the history is kept and assets are reused so that one generation becomes a workflow that keeps evolving.

The workload in the middle of that list is the one that distinguishes this from a prompt box. A partial repaint and a split are operations on an existing result, and they are exactly the operations that a node graph makes natural, because the result is a node with edges rather than a file you downloaded.

The audience is creators who iterate on AI video and who want the process itself to be a reusable artefact rather than a folder of loose files.

Performance comes from decoupling the viewport from the work

The project makes three performance claims and one of them is unusually specific.

The first two are about the workspace being optimised for a complex creation canvas, and about low resource use and a low barrier to entry, with a single desktop workspace enough to start creating and capabilities loaded on demand. The third is the interesting one. The readme says the viewport rendering, node loading, media preview and generation tasks are decoupled from each other, so that operation stays smooth as the project grows.

That is a claim about architecture, not about a number, and it is checkable in the code rather than in a benchmark table. If the render loop does not wait for a generation task, and a media preview does not block node loading, then a project with a hundred nodes and a running job still responds to input. A tool that couples them would feel fine with five nodes and terrible with a hundred, which is the failure mode that makes canvas tools frustrating in exactly the workflows they are built for.

The decoupled design also has a second effect on the product. Generation is asynchronous, and the project lists asynchronous tasks as one of the things the workspace manages, alongside the project library, the personal asset library, model channels and the creation tools. So the canvas is not a place where you wait for a result, it is a place where a job is running while you work on something else.

The documentation site has a features page, docs/content/docs/overview/features.mdx, which the readme points to for the complete scope, and that is where the per feature detail lives.

Local first data, and model channels you configure yourself

Two commitments define the project's stance, and both are about not being dependent on a vendor.

The first is the model channel. The readme states that text, image, video and audio model channels can be configured freely and that the tool is not bound to a single provider. The second is data ownership. Projects, canvas, assets and tasks are managed by a unified workspace, and the data can be stored locally and migrated.

Together they mean the workspace is a client for whatever generation services you have accounts with, and your project files are files on your disk. For a creator with several subscriptions, or one with an account on a self hosted model server, that is the difference between a tool that fits their setup and one that asks them to sign up for a plan.

The practical consequence for evaluation is that the download is not the product. The readme says that after the first launch you add your own model channel to start creating, so the first session in the app is an empty canvas and a settings screen where you paste a provider configuration. If you are evaluating the generation quality, you have to bring credentials and burn your own quota doing it.

The open by design section also says the model protocol and the workspace capabilities can continue to be customised or extended, which is a statement about the extension points rather than a promise of a plugin API. The repository has a plugin-packages directory and an agent-host directory, and an AGENTS.md at the root, so the shape of those extension points is in the tree even if the readme does not describe them in detail.

React and Go behind a Wails desktop shell

The desktop build has three parts, and the readme names all three: the desktop client is based on React, Go and Wails.

The division of labour is conventional for that stack. React and the web assets make the canvas, the Go backend holds the workspace state, the asset libraries and the task queue, and Wails packages both into a native desktop application without a bundled browser runtime. The web directory and the backend directory at the top of the repository match that split, and the presence of a Dockerfile that builds the web frontend with Vite and serves it from nginx confirms that the same web layer is what runs in the browser.

There are two ways to run the thing, then. The desktop application, and a container deployment of the web workspace with the backend behind it. The readme's badges advertise the desktop version for macOS and Windows, and the quickstart document covers the download and the first launch instructions for Mac, with a separate note that the desktop version supports macOS and Windows.

The build from source is three commands:

git clone https://github.com/glanderness/BeefTV.git
cd BeefTV
./scripts/build-beeftv-release.sh

The script is the entry point rather than a hand written sequence, and the readme defers the details to two documents: QUICKSTART.md for the environment requirements and the download and first launch instructions, and docs/desktop-release.md for the desktop release documentation and the Windows build.

For contributors there is also CONTRIBUTING.md for the development process and the test requirements, a CHANGELOG.md, a CODE_OF_CONDUCT.md and a SECURITY.md. The presence of a VERSION file at the root, which the Dockerfile copies into the image, suggests the version is a single source of truth rather than something read from the package manifest.

The container deployment is two images and a local build

The compose file is worth reading, because it shows the same system as a service and it shows the defaults the maintainers chose.

The backend service builds from backend/Dockerfile with a GOPROXY build argument, runs with GIN_MODE release, listens on CANVAS_BACKEND_ADDR :8080 and stores its data in CANVAS_BACKEND_DATA_DIR /data, which is a named volume, backend-data. The web service builds from the root Dockerfile and publishes port 3000, and it waits for the backend with depends_on and the condition service_healthy, which means the backend defines a health check.

The environment variables are where the product decisions show. The database driver defaults to sqlite, which matches the local first positioning. CANVAS_LOCAL_MODE defaults to true. CANVAS_WORKER_CONCURRENCY and CANVAS_CHANNEL_CONCURRENCY both default to 3, so the generation queue and the channel handling are bounded rather than unbounded. CANVAS_REGISTRATION_ENABLED defaults to false, so the deployment does not accept new accounts out of the box. CANVAS_ALLOW_PRIVATE_UPSTREAMS defaults to false, with an empty allow list of private upstream hosts, which is the sensible default for anything that fetches URLs on your behalf. CANVAS_CORS_ORIGINS defaults to http://localhost:3000. And the shutdown timeout is 10 minutes, used both as CANVAS_SHUTDOWN_TIMEOUT and as the stop grace period, which is generous because a running generation task needs time to finish.

One detail to notice in the images. Both services are named beeftv-backend:local and beeftv-web:local with a build section, so the compose file builds them locally rather than pulling them from a registry. There is no published image to pull, which means the container path is for people who want to modify the code, and the desktop application is the path for people who just want to use it.

The web image itself is two stages. The first builds the frontend with bun 1.3.13 and Vite, and the second is nginx 1.27 alpine serving the static output with an nginx.conf, exposing port 3000 and running a wget health check every 30 seconds. A comment in the Dockerfile notes that the production image builds only the cloud workspace frontend, because the agent runtime runs in the backend worker.

MIT with attribution files, and releases three times in two days

The licence is MIT, with the LICENSE file at the root, and the project also ships a NOTICE file and a THIRD_PARTY_NOTICES.md. The readme points at them for upstream sources, retention notices and third party attribution, which is a more careful treatment than a bare licence file and suggests the project vendors or derives from code whose terms it wants to keep visible.

The repository is not archived and the last push was on 2026-10-19. The release history in the same week is fast: v1.7.22 and v1.7.23 on 2026-10-14, and v1.7.24 on 2026-10-15. Patch releases a day apart, in a project whose feature area is an AI creative workspace, is a project that is shipping continuously.

That pace has consequences. It means the changelog is the document you read before upgrading, and it means a version pinned today may be a version nobody is running tomorrow. For a desktop application that a creator installs once and keeps, that is mostly fine, because an update is a deliberate act. For a team running the containers, the images are built from source anyway, so the commit you deploy is the commit you chose.

The topics attached to the repository describe the territory precisely, with ai-video, ai-image-generation, ai-workspace, aigc, creative-tools, infinite-canvas and local-first. The local-first label is the one that matters most for adoption, because it is the one that is hardest to retrofit into a hosted product later.

The download is a desktop application, the website is at beeftv.app, and there is a community channel and a presence on X, all linked from the readme.

Editorial conclusion

BeefTV is worth adopting if you generate a lot of AI video and want your project files, prompts and assets to live on your own disk with your own provider credentials, and if you are comfortable with a tool that ships releases several times a week. It is the wrong choice if you need a mobile client, if you want a finished production suite with a rendering farm behind it, or if you expect a hosted service to come with model credits. Before you build it, read QUICKSTART.md for the environment requirements and docs/desktop-release.md for the desktop release process, and check the release notes first, because v1.7.22, v1.7.23 and v1.7.24 all landed within two days and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. glanderness/BeefTV on GitHub
2. License: MIT
3. Project website
4. README
5. Releases