ViewComfy: Turning ComfyUI Workflows Into Shareable Web Apps

The gap between a ComfyUI graph and a person who just wants to click generate

A ComfyUI workflow is a graph. Handing that graph to a client, a colleague, or a non-technical user means handing them node wiring, sampler settings, and a local install. ViewComfy addresses a narrower problem: taking the workflow_api.json that ComfyUI exports and generating a form-based interface over it. The README describes the project as an open source tool to help you create beautiful web apps from ComfyUI workflows, and it states that a single UI can hold multiple workflows and works with image, video and text outputs. The intended user is the person who built the workflow, not the person who will use the app. The builder drags the JSON into the form editor, decides which inputs are visible, and the result is a playground that can be shared. The end user never sees the graph, never installs ComfyUI, and never receives the workflow_api.json file. That last point matters more than it first appears: Playground Mode is explicitly described as convenient for sharing a workflow without sharing the JSON, and without the recipient having to install ComfyUI. The tool is therefore as much an access-control boundary as a UI generator.

What the form editor actually does with your workflow_api.json

According to the README, the form editor accepts a drag-and-drop of the ComfyUI workflow_api.json file and generates a new form used to configure the inputs shown in the playground. The input types listed are text, numbers, dropdowns (select), sliders, check boxes, images, videos and audio. Inputs can be marked required or optional, and helper text can be attached. So the data flow is: ComfyUI exports the API-format graph, ViewComfy parses it, and the builder maps a subset of node parameters onto form controls. A separate mask editor adds masks to image inputs, which is the one editing affordance beyond field configuration. For behaviour that a static form cannot express, the project points to a companion node pack, ViewComfy-Utils, which the README says enables workflow routing, optional images, and custom input validation with error messages. That is an important architectural detail: conditional logic is not implemented in the TypeScript front end. It is pushed into the ComfyUI graph itself, as nodes, which means the app's behaviour depends on the deployed workflow containing those nodes. The output of the editor is a view_comfy.json file, and that file is what you place in the root of the project to run Playground Mode locally. Nothing in the material describes a schema for that file or a migration path between versions of it, which is a real gap if you plan to keep apps alive across releases.

Installation and the local Playground Mode setup

The repository is TypeScript and installs like a Node project. The README recommends Node.js v20.18 or later, with v20.18 as the recommended version. The commands given are git clone https://github.com/ViewComfy/ViewComfy.git, then cd ViewComfy, npm install, npm run dev. That starts the development server. To run only the playground locally, the README says you download the view_comfy.json generated by the form editor and place it in the root of the project; Playground Mode, also called ViewMode, then loads only the playground page. The README notes this mode is enabled by default when apps run on ViewComfy Cloud. There is also a hosted editor at editor.viewcomfy.com that skips installation entirely, but with a condition: when using the web-hosted editor you must first deploy the workflow on ViewComfy Cloud and connect the app to the workflow's API endpoint. If you want a local installation to talk to a cloud deployment instead of local ComfyUI, the README specifies two environment variables in a .env file: VIEWCOMFY_CLIENT_ID and VIEWCOMFY_CLIENT_SECRET, with the keys taken from the dashboard. After that, the app sends a request to your ViewComfy deployment each time the user clicks generate. The README does not document the rest of the .env surface, so treat those two keys as the only confirmed configuration.

Deployment: viewcomfy.json, API endpoints, and where the hosted features stop being yours

Deployment has two halves. The first is the Comfy server: you set it up so the workflow runs on serverless infrastructure and is reachable through both the standard Comfy interface and an API endpoint. You then paste that endpoint into the corresponding field in your ViewComfy app, and every generate click becomes a request to it. The second half is the app itself. The easiest path, per the README, is to open the ViewComfy Apps tab on the ViewComfy cloud dashboard and drop the viewcomfy.json there. The README also states that you can deploy on the hosting service of your choice, and points to a hosting-examples/modal folder for Modal. This is where the open source boundary becomes visible. User management, billing tracking, shareable email links, user output history, the app hub, and analytics are all described as coming with apps hosted on ViewComfy Cloud. They are not presented as features of the self-hosted repository. If you deploy the app yourself, you are deploying the interface and the endpoint wiring, and you are building or buying the surrounding account and history layer. The README does not enumerate what the self-hosted build omits, so the honest reading is that the cloud dashboard is the reference deployment and other hosts are supported but less specified.

Where ViewComfy is the wrong tool

The clearest limitation is the one the project states as a feature: the playground exposes only the inputs you choose. If your users need to inspect or rearrange the graph, adjust a node that was not surfaced, or debug why a generation failed at the sampler level, ViewComfy is the wrong layer. It is a presentation layer over a fixed workflow, not a ComfyUI replacement. Routing and conditional logic depend on the ViewComfy-Utils node pack being present in the deployed workflow, so an app is only as flexible as the graph behind it. There is also a coupling problem for local use: connecting a local installation to a cloud deployment requires client credentials in .env, and the web-hosted editor requires the workflow to be deployed on ViewComfy Cloud before the app can be connected at all. In other words, the fastest editing path routes through the vendor's cloud. Finally, the release cadence visible in the material is uneven. v.0.3.22 and v.0.3.21 landed three days apart in late August and early September 2025, then v.0.3.23 arrived on 2026-01-08. That is a gap of roughly four months between the last two releases. The last push to the repository is dated 2026-03-19, so development has not stopped, but anyone pinning to a version should expect to wait between tagged releases and should not assume a fixed upgrade rhythm.

How it differs from putting Gradio in front of a model

The obvious alternative for anyone shipping a small generative interface is Gradio, which builds a UI around Python functions you write. The difference in approach is where the workflow lives. With Gradio you re-express the pipeline in Python, or call out to something that already does, and the UI is generated from your function signature. With ViewComfy the pipeline stays in ComfyUI, and the UI is generated from the exported workflow_api.json. That means you keep the node graph as the source of truth and get every custom node your workflow already depends on, but you inherit ComfyUI's execution model and API endpoint as a runtime requirement. It also means the interface is limited to the field types ViewComfy supports and the behaviours its node pack provides, whereas a Gradio app can implement arbitrary logic in Python. If your pipeline is already a ComfyUI graph and you want to avoid rewriting it, ViewComfy removes that work. If your pipeline is a few model calls and some post-processing, Gradio is the smaller dependency and does not require a running Comfy server.

Licence and the cost of staying current

ViewComfy is licensed AGPL-3.0. The practical consequence, stated plainly and without legal advice: if you modify the software and let users interact with it over a network, the AGPL's source-disclosure obligations are generally understood to apply to your modified version. That is a different posture from a permissive licence, and it is worth confirming with your own counsel before you build a commercial product on a fork. On maintenance, the material supports only limited conclusions. The form editor emits a view_comfy.json whose format is not documented here, so any change to that format between releases is a migration you would have to discover yourself. The dependency set is a Node project pinned by the README to Node.js v20.18 or later, which means Node upgrades are part of your maintenance surface. The ViewComfy-Utils node pack is a second component to track, because workflow routing and validation live there rather than in the app. Upgrading the app without upgrading the node pack, or the reverse, is the kind of mismatch that the supplied material gives you no compatibility matrix for.

Editorial conclusion

Adopt ViewComfy if you already have a working ComfyUI workflow and need a narrow interface for people who will not install ComfyUI. Do not adopt it if your users need to edit the graph, or if you are unwilling to accept AGPL-3.0 terms or to depend on ViewComfy Cloud for history, app hub and user management. Before committing, verify three things: that the view_comfy.json generated by the form editor loads correctly in Playground Mode, that your workflow works through the API endpoint rather than only through the standard Comfy interface, and that you have a plan for the .env keys VIEWCOMFY_CLIENT_ID and VIEWCOMFY_CLIENT_SECRET if you connect a local installation to a cloud deployment.

Official sources

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