TongFlow: An AGPL Multimodal Canvas That Runs Against a Hosted Studio
TongFlow — Multimodal GenAI Studio
At a glance
- What is it?
- TongFlow wraps text, image, audio, video and 3D models as nodes on a single canvas, but the desktop installer is a thin shell around app.tongflow.com. Self-hosting is the only path to a fully local, account-free setup.
- Who is it for?
- Adopt TongFlow if your team already thinks in pipelines of modality transforms and you are willing to run the self-hosted source or Docker path with your own plugin credentials, because the default desktop app is only a shell around app.tongflow.com. Do not adopt it if you need a fully offline install with no account, or if you require a node that is still marked as planned rather than shipped with an official plugin.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: modality transforms scattered across separate tools
Most generative work is a chain, not a single call. You write a script, turn it into speech, generate a character image, then lip-sync the two together. Doing that today usually means moving files between a chat UI, an image tool, a voice tool and a video editor, re-uploading at every hop. TongFlow's stated premise is that every AI model is a modality transform: LLMs are text to text, image models are text to image, speech models are text to audio. Wrap each one as a node and the chain becomes visible on one canvas. The README frames the target user as someone who wants a low barrier and a high ceiling, with no complex AI parameters to learn and no manual node connecting, using three operations: add, transform, combine. That is a narrower claim than it sounds. It is aimed at people who can describe a pipeline but do not want to write the orchestration code, and at teams that want an official plugin per capability rather than a hand-rolled integration for each model vendor.
Add, transform, combine: the node model in practice
The canvas has two node families in the documentation. Add nodes bring material in: text input, image from file, photo from camera, sketch drawn on canvas, audio from file or mic, video from file or camera, document from file, URL fetch, and 3D model from a local file. The URL node is the interesting one, because the README says it fetches a page and adds text, image, audio or video nodes depending on what it finds, so one input can fan out into several typed nodes. Transform nodes consume and emit typed material. Text has generate and rewrite. Image has generation, editing (inpaint, edit, redraw), understanding (captions and Q&A), upscaling, pose detection at 308 keypoints across body, hands and face, 29-class body-part segmentation, surface normals, and matting to a transparent PNG. Video has generation from text, image-to-video, first and last frame interpolation, multi-image reference fusion, and an omni-reference mode that mixes image, video and audio references. The README's demo table shows the intended shape of this: a basic workflow chains Add text, Transform to images, Compose into one; an intermediate one pairs a topic-to-script-to-speech branch with a character-description-to-image branch and feeds both into a lip-synced talking-head video. Nothing in the supplied material describes how node outputs are typed or validated at the edges, so treat the type-safety of a chain as unverified.
The desktop app is a shell, and that is the whole architecture question
This is the part that decides whether TongFlow fits. The README states plainly that the desktop app is a lightweight shell of roughly 10 MB around the cloud studio at app.tongflow.com: install it, sign in, and start creating. The cloud studio also runs in any modern browser. So the default experience is a client for a hosted service, not a local application. Node execution and plugin management happen on the cloud side, per the sign-in step. The repository is TypeScript and carries a PyPI badge for a Python SDK, so there is a programmatic surface alongside the canvas, but the supplied README does not document its API. The local runtime does exist as a path: the README points to Run from source and Run with Docker, then to a Self-host setup section covering plugins and credentials, and notes that desktop app builds up to v0.1.13 bundled that local runtime. That note is the load-bearing detail. If you want account-free local execution, you are building from source or running the container, and you are supplying your own credentials per plugin.
Getting it running: two paths with different trust models
The hosted path is short. Download TongFlow-mac-universal.dmg or TongFlow-win-x64.msi from the latest release, install, open, and sign in with Google or WeChat. On macOS the README warns that builds are not yet notarized with Apple, so Gatekeeper blocks the first launch with a damaged-and-cannot-be-opened message. The documented fix is to move the app to Applications and clear the quarantine flag once: xattr -cr /Applications/TongFlow.app. The README also warns against installing from chat apps such as WeChat, because installers passed through them may be renamed or re-flagged. The self-hosted path is the one the README points to for a fully local, account-free setup: build from source or run with Docker, then complete the Self-host setup step for plugins and credentials. The material names those sections but does not reproduce the Docker command, the environment variables, or the credential key names, so the exact invocation has to come from the repository docs. What is clear is the shape of the work: you install plugins per capability and you supply provider credentials yourself, which is the trade you make for dropping the hosted account.
Where TongFlow is the wrong tool
The README's own legend is the first limitation. A checkmark means a node is available out of the box with an official plugin; an open square means the node exists on the canvas but has no official plugin yet, listed as planned. So the canvas can show you a node you cannot actually run without writing a plugin. The README itself flags this distinction rather than hiding it. Second, the plugin-based design is deliberate: the core stays small and every platform can package its own plugins, with at least one official implementation per capability node. That is an ecosystem bet, and it means breadth depends on third parties filling gaps. Third, the default install is not local. If your constraint is that prompts, source images or client footage cannot leave your infrastructure, the desktop app as shipped does not satisfy it, and you are on the source or Docker path with your own credentials. Fourth, macOS distribution is currently un-notarized, which is a real friction for anyone distributing the app inside an organization. And the licence matters here: AGPL-3.0 is a strong copyleft licence, so if you modify TongFlow and expose it to users over a network, the source-availability obligation is likely to reach your changes. That is a description of the licence family, not legal advice; get counsel for a commercial deployment.
What a node-graph tool like ComfyUI does differently
ComfyUI is the obvious comparison for anyone reading a node canvas description, and the difference is in who supplies the execution environment. ComfyUI is a local Python server you run yourself; the graph is the program, and model weights and custom nodes live on your machine. TongFlow inverts the default: the graph runs in a hosted studio, and the desktop app is a roughly 10 MB shell that signs you in. Where ComfyUI expects you to wire nodes and manage parameters, TongFlow's stated design goal is the opposite, three operations (add, transform, combine) and no manual node connecting. That is a genuine difference in audience, not a feature gap. The self-hosted TongFlow path moves it closer to the ComfyUI model, since you then manage plugins and credentials locally, but the README does not claim parity with a fully local Python stack, and the local runtime is documented as something you build or containerize rather than something the current installer gives you. If your team already has ComfyUI graphs in production, TongFlow's value is the hosted collaboration surface and the official plugin set, not local execution.
Maintenance, releases and what to check before committing
The release cadence visible in the supplied material is three versions in about three weeks: v0.3.3 and v0.3.4 on 2026-08-19, then v0.3.5 on 2026-09-10, with the last push to main on the same day as v0.3.5. That is a fast-moving pre-1.0 project, and the version numbers say so. The upgrade cost you should plan for is plugin and credential compatibility across minor bumps, since self-hosting means you own the plugin set and the provider keys behind each node. The README does not describe a migration policy or a plugin API stability guarantee, so pin a release tag rather than tracking main if you self-host. The AGPL-3.0 licence is the other long-lived cost: it is compatible with internal use, but any modified version you expose to users over a network carries a source-availability obligation. Before you commit, do three concrete things. Walk your intended workflow against the What's Defined list and confirm every node carries the checkmark rather than the planned marker. Confirm from the repository docs whether the local runtime is present in the current release or only in installers up to v0.1.13, since that decides whether the account-free path is a build or a download. And read the Self-host setup section for the actual plugin and credential keys, because the README names that step without reproducing it.
Editorial conclusion
Adopt TongFlow if your team already thinks in pipelines of modality transforms and you are willing to run the self-hosted source or Docker path with your own plugin credentials, because the default desktop app is only a shell around app.tongflow.com. Do not adopt it if you need a fully offline install with no account, or if you require a node that is still marked as planned rather than shipped with an official plugin. Verify first that every node in your intended workflow has the checkmark in the What's Defined list, and confirm whether the local runtime you need is still present in the current release or only in installers up to v0.1.13.
Community notes