ViewComfy turns a ComfyUI workflow into a web app, then freezes your settings at build time

Playground Mode hides the workflow JSON entirely

The core idea is a translation step. You drag a ComfyUI workflow_api.json into the form editor, and it generates a form describing the inputs that will be shown, which you then configure: which inputs appear at all, whether each is required or optional, and what helper text sits next to it. The supported input types are text, numbers, dropdowns, sliders, check boxes, images, videos and audio, and a mask editor adds masks to image inputs. Several workflows can live in the same interface, and the tool handles image, video and text outputs. Playground Mode, also called ViewMode, is what turns this into something you can hand to another person: it loads only the playground page, so the recipient never sees the workflow_api.json and never has to install ComfyUI, and you control which inputs are exposed. That mode is on by default for apps deployed on ViewComfy Cloud, which is why the hosted product feels different from the local one.

view_comfy.json is the file that actually renders the app

Two editor paths sit on top of each other, and the second one saves you the ComfyUI file. The normal route is the form editor, where you drop in workflow_api.json and it generates a form for the playground. The advanced route skips that: you can drop a view_comfy.json straight into the form editor and edit it without ever supplying workflow_api.json, which is what you want once you have already generated one. That generated file is also what the app renders. ViewComfy looks for view_comfy.json in the project root by default, and you place it there next to workflow_api.json, while the VIEW_COMFY_FILE_NAME environment variable points the app at a different filename. The flag can be set in the .env file or passed on the command line in one step:

VIEW_COMFY_FILE_NAME="view_comfy.json" NEXT_PUBLIC_VIEW_MODE="true" npm run dev

The playground itself is the simplified surface where the workflow actually runs, and it is the page ViewMode keeps on its own when you want a shareable app.

The no-install editor still needs a cloud deployment first

There is a web-hosted app editor, and the conditions attached to it are easy to skim past. To skip installing ViewComfy you can use the hosted editor at editor.viewcomfy.com, but you have to deploy the workflow on ViewComfy cloud first and connect the app to that workflow's API endpoint. So the zero-install route still assumes a cloud deployment and an API endpoint; what it removes is the local Node install, not the server dependency. The local route is four steps: install Node.js v20.18 or later, with v20.18 recommended, clone the repository, install dependencies with npm, and start the dev server. The repository also carries a longer guide for setting up playground mode and sharing an app through ngrok on the project blog, and an installation video, so the shallow README steps are a starting point rather than the full procedure.

NEXT_PUBLIC_ settings are decided when the image is built

This is the operational detail that decides how you work. The Dockerfile takes five values as build arguments and copies them into the environment before running the build: NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY, NEXT_PUBLIC_USER_MANAGEMENT, NEXT_PUBLIC_VIEW_MODE, NEXT_PUBLIC_API_URL and NEXT_PUBLIC_CLOUD_WS_URL. Because the Next.js build inlines anything prefixed NEXT_PUBLIC_ into the client bundle, those values are fixed at the moment npm run build runs inside the builder stage, not when the container starts. Changing your view mode, your Clerk key or your API URL after deployment therefore means rebuilding the image, not restarting it. The same applies to the documented local workflow, where NEXT_PUBLIC_VIEW_MODE is set in a .env file before npm run dev, which is why the README shows the flag being set alongside the dev command on a single line as an alternative.

The container runs Node 22 while the docs recommend 20.18

The Dockerfile starts from debian:bookworm-slim, installs curl, build-essential, unzip and ca-certificates, then pulls in Node from the NodeSource setup script for the 22.x line and installs nodejs from apt. That is one major version ahead of what the installation instructions ask for, so local development and the container are not the same runtime even though both satisfy the stated minimum of v20.18. The rest of the image is a conventional three-stage build. The deps stage copies package.json and package-lock.json and runs npm ci, so the lockfile is what pins the tree. The builder stage copies node_modules and the whole source tree, sets NEXT_TELEMETRY_DISABLED=1, and runs npm run build. The runner stage sets NODE_ENV=production, creates a system group and user at uid and gid 1001, copies the public directory, and takes the standalone Next.js output from the builder so the image ships fewer files.

The API client is generated from a running ComfyUI instance

One script in the manifest explains the coupling between the app and a live ComfyUI server. generate-api runs openapi against http://localhost:8000/openapi.json, writes the result into src/generated and generates a fetch client, which means regenerating the typed API surface requires a ComfyUI server listening on port 8000 at the moment you run it. The runtime path is similarly direct. Your app sends a request to your ViewComfy deployment every time someone clicks generate, so the workflow host is on the critical path for every interaction rather than only for the first one. To point a locally installed ViewComfy at that deployment you need credentials from the dashboard written into a .env file:

.env file ->
VIEWCOMFY_CLIENT_ID="<your client id>"
VIEWCOMFY_CLIENT_SECRET="<your client secret>"

The deployment itself is then a file drop: you put viewcomfy.json into the Apps tab on the cloud dashboard, or you host the app on a service of your choice.

User management, billing and history belong to the cloud

A cluster of the advertised features is explicitly scoped to apps deployed on ViewComfy Cloud rather than to the open source build. Built-in user management, analytics, billing tracking, shareable email links, an output history for users, and an app hub listing all of your apps are each described that way. Self-hosting is supported and there is a worked example, with details for hosting on Modal kept in the hosting-examples/modal folder and a separate ViewComfy-modal.dockerfile at the repository root, but the plan is that you supply the missing pieces yourself. The input editor, mask editor, playground and form editor are the parts that survive self-hosting. The README also points at a separate ViewComfy-Utils node pack for the behaviours a single workflow file cannot express, including workflow routing, optional images and custom input validation with error messages.

Clerk configuration is recommended, not enforced, and the tree is untidy

User management runs through Clerk and is switched on with NEXT_PUBLIC_USER_MANAGEMENT="true", alongside NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY and a server-side CLERK_SECRET_KEY. The guidance is that this should be used only when playground mode is also active, which makes sense in a sharing context and leaves the combination unenforced in code, since both are independent flags in the same .env file. The repository layout shows how the project grew: both an app directory and a src directory, two ESLint configurations in .eslintrc.json and eslint.config.mjs, instrumentation files and two Sentry configs, a stores directory and a hooks directory, and agent-facing files such as CLAUDE.md, AGENTS.md, .claude/ and .cursor/. There is also a .env file in the repository root next to .gitignore, which is worth checking before you copy this layout. The manifest says version 0.1.0 and private true while the release tags run v.0.3.21, v.0.3.22 and v.0.3.23, and the last commit was 19 March 2026.

Editorial conclusion

ViewComfy is the right tool when you have a ComfyUI workflow that other people should be able to run without installing anything, and you are willing to host the workflow somewhere reachable. Plan around three constraints. Configuration that starts with NEXT_PUBLIC_ is baked into the build, so plan mode changes before you deploy rather than after. Cloud features such as user management, billing tracking and output history do not come with a self-hosted deployment. And the repository has had no commit since 19 March 2026, so check the tag you are installing against the docs before you rely on it.

Frequently asked questions

Official sources

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