NodeTool: an agent-first creative workspace for images, video, audio and text

What NodeTool solves, and who it is actually for

Generating one image is easy. Producing a finished piece means moving between a prompt box, a storyboard, a voice tool, a timeline and an image editor, and re-uploading assets at every hop. NodeTool's answer is to keep all of it in one project: the graph, the inputs, the assets and the edits stay together, and five editors sit on the same node canvas. The README describes the intended path as writing a brief, asking the agent for a storyboard, approving stills before spending on video, assembling clips on a timeline, trimming, adding narration and exporting an MP4.

The audience is narrower than the tagline suggests. This is for people who are comfortable connecting typed ports in a node graph and who already hold API keys with providers such as OpenAI, Anthropic, Gemini, fal, Replicate, Hugging Face, ElevenLabs, MiniMax, KIE, Topaz and Atlas Cloud, all of which appear as workspace packages in the root package.json. It is also for people who want the same workflow reachable from a studio, a CLI or an external agent over MCP. If you want a single prompt box with a monthly subscription, the graph is overhead you will not use.

The node graph underneath the storyboard, script, timeline, sketch and 3D editors

Every project is a graph you can open. Drag nodes in, connect typed ports, and read the live output at each step; the editor refuses a mismatch, so an image cannot land in a text field. Each of the five editors is a view onto that canvas rather than a separate document format.

The mechanism that makes this more than a diagram is staleness. In the timeline, a clip can be bound to a workflow and generated in place; change a parameter and the clip regenerates, tweak the workflow and the clip flags itself stale. The sketch editor behaves the same way: bind a layer to a model or workflow, change a prompt or an upstream input, and the layer flags itself stale while the rest of the workflow receives the flattened image, the mask and each layer separately. In the script editor, each voicing saves its own take with word timings, and changing the words flags that take stale. That flag is the whole cost-control story: you rerun the part that changed, not the film.

The repository layout backs this up. The root workspaces include packages/storyboard, packages/timeline, packages/image-editor, packages/model3d, packages/execution, packages/workflow-runner, packages/node-sdk and packages/agents, so the editors and the runtime are separate packages rather than one monolith. Provider integrations are code-generated per vendor (packages/fal-codegen, packages/replicate-codegen, packages/kie-codegen), which is how the project can add a model close to the day it ships.

Installing NodeTool: GitHub release or Docker Compose on port 17777

There are two documented routes. The README points at the latest release for your operating system and refers to docs/installation.md for requirements and per-OS steps; Studio is described as free and available on macOS, Windows and Linux. The repository also ships a reference Docker Compose file for self-hosting the server, and that is the route with copyable commands.

The compose file header gives the sequence directly. Copy the example environment file, fill in the provider keys you use, then bring the stack up and open the published port.

Local mode has no login, and that is the first thing to fix

The compose file carries a security banner in capitals: it runs in LOCAL MODE with NO LOGIN and NO PASSWORD, and every request from a trusted network runs as the single ADMIN user "1" with full access to workflows, files, stored secrets and API keys. The file calls this safe on a laptop, a private LAN or a VPN, and says you must enable Supabase auth or keep the port firewalled before putting it on a public IP.

The subtle part is the trust boundary. Behind Docker a published-port connection arrives from the bridge gateway rather than loopback, so NODETOOL_TRUST_LOCAL_NETWORKS must include that range or every API and WebSocket call returns 401. That variable is described in .env.example as bypassing login, which means the fix for the 401s is also the thing that grants admin. Auth is off by default, and enabling it means setting SUPABASE_URL, SUPABASE_KEY and SUPABASE_ANON_KEY together; the web UI reads those from the backend at runtime via GET /api/config, so no frontend rebuild is needed. The service-role key is documented as server-only and never sent to the browser.

This is not a footnote. Anyone who runs the compose file on a cloud host and forwards the port has published an unauthenticated admin API.

Cost control through cheap stages first

The README makes an economic argument rather than a quality one: a still costs cents, a clip costs dollars, so you generate stills until one looks right and then animate that one. Approving stills before spending on video is presented as the default workflow, and revising a single shot runs video-to-video on that clip alone and swaps it in place.

Entities support this. Characters, locations, styles and props paste the same descriptor into every prompt that names them, which is how a cast stays consistent across separately generated shots. The trade-off is that consistency depends on that shared descriptor rather than on a trained model, so a character's look is only as stable as the prompt text and the model's willingness to follow it. The README does not claim otherwise.

NodeTool calls the provider with your key, at their price, with no billing unit in between. That means no markup, and also no spend cap from NodeTool itself. Your provider dashboard is the limit.

Where NodeTool is the wrong tool

The documentation is silent on several things a production team would ask about. There is no documented rollback for a bad upgrade, no documented migration path for the SQLite database, and no documented retention or backup policy for the assets under /workspace. The compose file states that all persistent state (SQLite database, assets, vector store, model cache and the generated secret key) lives under /workspace on the named nodetool-data volume so it survives restarts and image upgrades. Surviving an upgrade is not the same as being able to go back, and the README does not describe going back.

Local models have hardware requirements that the README says depend on the model, and offline work needs the models and assets on your machine. There is no compatibility table in the README. NodeTool Cloud is described as in alpha and running on hosted storage and cloud providers, so it is not a fallback for someone who needs a supported hosted option today.

The wrong-tool case is clearest for teams that need multi-tenant accounts on first boot. Local mode is single-user by design, and Supabase auth is the documented way out. If you are not prepared to run that, run the studio locally instead of the server.

How NodeTool differs from ComfyUI

ComfyUI is the obvious comparison, and the difference is where the editing state lives. ComfyUI is a node graph for generation: you build a workflow, run it, and the output is an image or a clip that then goes somewhere else to be cut, voiced or layered. NodeTool puts the editors on top of the graph. The timeline, storyboard, script, sketch and 3D views are all views of the same project, so a clip on a track can stay bound to the workflow that produced it and regenerate in place.

That binding is also the constraint. In ComfyUI a generated file is inert; in NodeTool it can flag itself stale when an upstream parameter changes, which is useful when you want reproducibility and annoying when you only wanted to nudge a cut. The other difference is the agent. NodeTool's premise is that an agent wires the graph and runs it, and that the same workflow is reachable from the studio, the CLI or an external agent over MCP. In ComfyUI the graph is something you drive yourself. If you want the graph and nothing else, the extra layers here are weight you are paying for.

Licence, maintenance and what an upgrade costs you

NodeTool is licensed AGPL-3.0, with the licence text in LICENSE.txt. The practical consequence is the usual one for this licence: if you modify it and let users interact with it over a network, the AGPL's source-availability obligation is generally understood to reach your modified version. Whether that applies to your deployment is a question for a lawyer, not for this article.

The repository is not archived, and the last push was on 2026-09-14. The release history shows v0.7.0 on 2026-09-10, a release candidate v0.7.0-rc.40 on 2026-09-05, and a nightly build v0.7.1-nightly.20260904.762 on 2026-09-04, so there is an active release cadence including prerelease and nightly channels. Note that nightlies are published as builds, not as supported versions, and the repository does not describe a support policy for them.

Upgrade cost is dominated by the workspace volume and the container image. The compose file supports pinning a release with NODETOOL_VERSION or pointing NODETOOL_IMAGE at a locally built image. The Dockerfile copies package manifests with --parents so that adding or removing a workspace package needs no Dockerfile change, and builds packages with npm run build:packages before bundling the backend with esbuild. A self-hoster who pins NODETOOL_VERSION gets a predictable image; one who tracks main gets whatever the workspace graph resolves to.

Editorial conclusion

Adopt NodeTool if you want an agent to drive storyboard, script, timeline, sketch and 3D editors over one graph, and you are willing to run it on your own provider keys. Do not adopt it if you need a hosted multi-tenant service with accounts out of the box, or if you cannot firewall the port, because the reference compose file runs in local mode with no login and treats every request from a trusted network as admin user "1". Before committing, verify that the providers you depend on appear in docs/models-and-providers.md, confirm the hardware your chosen local model needs, and read the Authentication section of docker-compose.yml if the instance will be reachable by anyone other than you.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. nodetool-ai/nodetool on GitHub
3. Project website
4. README
5. Releases