ComfyUI_frontend: the official web UI for ComfyUI, and when to pin it
Official front-end implementation of ComfyUI. To use the latest nightly release, add the following command line argument to your ComfyUI launch script: Overlapping Release Cycles The development of successive minor versions overlaps.
At a glance
- What is it?
- ComfyUI_frontend is the TypeScript front end that ships inside ComfyUI and can also be pulled in independently as a pip package. The interesting part is not the node canvas but the release train behind it, which is why most version problems are solved by pinning rather than debugging.
- Who is it for?
- Adopt ComfyUI_frontend if you run ComfyUI and want the interface that upstream actually tests, or if you build on top of the graph canvas and need the exported types. Do not adopt it as a standalone browser app: it is not one, and the desktop and cloud builds are separate distribution targets.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 4 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 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What ComfyUI_frontend actually is
ComfyUI_frontend is the official front-end implementation of ComfyUI, written in TypeScript. The repository is not the whole of ComfyUI. It is the browser layer: the node graph canvas, the sidebar tabs, the queue and history views, the settings dialog, and the localization layer. The Python server that executes graphs lives in a different project, and the README links to it as comfyanonymous/ComfyUI.
That split matters when you are deciding whether to adopt anything. If you run ComfyUI normally, you already run this code. It is bundled into ComfyUI releases, and the version you see is whatever the Python package pulled in. The repository exists so that the interface can be developed, tested and released on its own schedule, and so that people building extensions or forks have a canonical source for the UI.
The audience is therefore narrow but real. ComfyUI users who need a newer interface than their install ships. Extension authors who need the front-end types and the graph API. Anyone maintaining a fork or a hosted deployment who has to reason about which UI version is live. If none of those describe you, this repository is not something you adopt; it is something you receive.
The release train is the real design decision
The README documents a three-phase cycle for each minor version: two weeks of development, two weeks of feature freeze where only bug fixes are cherry-picked to the release branch, then publication. Successive minor versions overlap. While 1.1 is frozen, 1.2 is in development. The README states that each feature has roughly four weeks from merge to ComfyUI stable release, split as two weeks on main and two weeks frozen on the release candidate.
The README's own example table makes the arithmetic concrete. In weeks 3 and 4, version 1.1 is in feature freeze while 1.2 is in development, and patch releases for 1.1 run daily. By weeks 5 and 6, 1.1 is released, 1.2 is frozen, 1.3 is in development, and both 1.1 and 1.2 are receiving daily patches.
The consequence is that patch releases are frequent and the stable line moves continuously. If you treat the ComfyUI front end as something you upgrade deliberately rather than inherit, you are signing up for a moving target. That is a trade-off, not a flaw. The alternative, a long-lived stable branch, would delay fixes for the canvas and the node library. The project chose responsiveness and pushed the stability burden onto the freeze window.
Nightly releases are published daily, separately from the minor version cadence. That gives you two distinct upgrade paths with different risk profiles, and the README treats them as different products, not as one channel with two names.
Installing and switching the front end to a nightly build
The README does not describe a standalone installation of the front end as a web application. It describes how to override the front end that ComfyUI uses. The documented mechanism is a command line argument passed to the ComfyUI launch script, which tells the server to fetch a specific front-end version instead of the bundled one.
Add this to your ComfyUI launch script to follow the latest nightly release:
--front-end-version Comfy-Org/ComfyUI_frontend@latestThe argument takes the form owner/repository@version, and the README uses latest as the version. After restarting ComfyUI, the interface served in the browser should be the nightly build rather than the shipped one. If nothing changes, the argument is not reaching the server process, so check the launch script rather than the browser.
The repository also ships a Python package. The top-level directory comfyui_frontend_package/ is present in the repository layout, and the package.json name is @comfyorg/comfyui-frontend, which is the npm-side identifier rather than the pip one. The related search data shows people asking about pip and PyPI installation of a comfyui frontend package, and the README does not spell out the pip command, so treat the package directory as the thing to inspect rather than guessing at an install line.
For development against the front end itself, the repository is a pnpm workspace. The package.json declares type: module, a build script that runs pnpm typecheck before vite build, and separate cloud and desktop distribution builds via DISTRIBUTION=cloud and DISTRIBUTION=desktop. The dev:cloud:test script points the dev server at https://testcloud.comfy.org/ through DEV_SERVER_COMFYUI_URL, which is how the front end is developed without a local server. The repository carries a .nvmrc, so the Node version is pinned rather than assumed.
Version skew is the failure mode to expect
The most common way this project goes wrong is not a crash. It is a mismatch. The Python package that installs ComfyUI has its own version, the front end has its own version, and the two are related but not identical. The repository's package.json is at 1.55.9 while the most recent tagged release in the release list is v1.53.4, which tells you the manifest version and the published release tag are not the same number at any given moment.
When those numbers disagree, the symptoms are confusing rather than obvious. A node pack written against a newer graph API may fail to register its widgets. A saved workflow may load with missing inputs. The interface may behave correctly but lack a feature you saw in a screenshot. None of that points at the front end, and the natural instinct is to debug the node pack.
The related searches include people reporting that the comfyui frontend is outdated and that the comfyui frontend package is not installed. Both describe the same underlying condition: the running install is not serving the front end the user expects. The README's answer to this is the version argument, which lets you override rather than wait for the next bundled release.
A second limitation is scope. This repository does not contain the server, the model loading code, or the sampling implementation. If your problem is that a graph runs slowly or a model fails to load, the front end is the wrong place to look, and no amount of front-end version pinning will change it.
ComfyUI Desktop and the browser build are not the same target
The build scripts make the distinction explicit. DISTRIBUTION=cloud and DISTRIBUTION=desktop produce different bundles from the same source through vite.config.mts. That is the project's own acknowledgement that the interface is deployed in more than one context, and it is why the related searches include questions about a ComfyUI frontend for Mac and for Android.
Those questions do not have a front-end answer. The front end is a web interface. Whether it runs on macOS depends on whether ComfyUI runs there and serves it, and whether it runs on Android depends on the same thing. The repository does not ship a mobile application, and nothing in the README points to one.
This is where the comparison with ComfyUI Desktop becomes relevant. The search data asks whether ComfyUI Portable is better than ComfyUI Desktop, and the honest answer is that the front end is not the deciding factor between them. Both serve a front end. The difference is in how the server is packaged and launched, which is outside this repository. What the front end repository does tell you is that desktop is a distinct build target with its own distribution flag, so behaviour can differ between a browser deployment and the desktop bundle even at the same version.
Licence and upgrade cost
The repository is licensed GPL-3.0. The package.json states GPL-3.0-only, and the repository carries THIRD_PARTY_NOTICES.md alongside LICENSE, which is the file to read if you need to know what else is bundled. For anyone embedding the front end in a product, the practical question is whether distributing a modified build triggers the GPL obligations, and that is a question for your own counsel rather than something the README answers.
The upgrade cost is mostly operational. Patch releases run daily during the freeze and post-release windows, which means the version you pin will be behind within a day or two. Following latest means taking whatever was published most recently, with no freeze window protecting you. Pinning a specific version means you get stability and stop receiving canvas fixes.
The repository's own contribution surface suggests the maintenance burden is taken seriously: there is a TROUBLESHOOTING.md, an AGENTS.md and CLAUDE.md for tooling, ADR checks via scripts/check-adrs.ts, and a codecov configuration. None of that reduces your upgrade cost, but it does mean the project documents its own process rather than leaving you to infer it.
Editorial conclusion
Adopt ComfyUI_frontend if you run ComfyUI and want the interface that upstream actually tests, or if you build on top of the graph canvas and need the exported types. Do not adopt it as a standalone browser app: it is not one, and the desktop and cloud builds are separate distribution targets. Before upgrading, verify which version your install is actually serving, because a Python package version and a front-end version can disagree, and check whether the node packs you depend on have caught up with the release you are about to move to.
Frequently asked questions
How do I update my ComfyUI frontend?
The README's documented route is the launch argument --front-end-version Comfy-Org/ComfyUI_frontend@latest, which makes ComfyUI fetch the latest nightly front end instead of the bundled one. Otherwise the front end updates when the ComfyUI package that contains it updates.
How do I install the ComfyUI frontend package?
The README does not give a pip command for the front-end package. The repository contains a comfyui_frontend_package/ directory and the package.json names the npm package @comfyorg/comfyui-frontend, so check that package directory for the actual distribution details rather than assuming a pip name.
What is ComfyUI frontend?
It is the official front-end implementation of ComfyUI, written in TypeScript. It covers the node graph canvas, sidebar tabs, queue and history views, settings, and the built-in translation layer, while the Python server that runs graphs lives in a separate project.
Why does ComfyUI say the frontend is outdated?
The front end is versioned separately from the ComfyUI package that installs it, so a bundled interface can lag behind the published releases. The README's version argument exists so you can point ComfyUI at a specific front-end release instead of waiting for the next bundle.
Is there a ComfyUI frontend alternative?
The README does not name one. It does note that the built-in translation support replaced third-party translation extensions, which is the one case where the project explicitly supersedes an external add-on.
Can ComfyUI be used on Linux?
This repository does not answer that. It is the browser front end and does not ship a platform-specific build for Linux, macOS or Android; whether ComfyUI runs on a given system depends on the server project, which the README links to separately.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/comfy-org-comfyui-frontend)