Comfy Registryへの公開では、まずregistry.comfy.orgでPublisher IDとAPIキーを作ります。次に、comfy node initで生成したpyproject.tomlへ必須フィールドを埋め、comfy node publishかGitHub Actionsで送ります。一度公開するとnameは変えられず、更新はSemVerのversionを上げるだけで配信されるため、公開前にRepositoryと安全基準を整えておきます。
情報確認日：2026年8月22日（日本時間）
結論：名前は一度きり、versionは毎回、安全基準は最初から
責任範囲
- Registryに載せることで何が変わるか（発見性・version管理・保守責任）
- 公開前にRepositoryへ揃えるもの（README・License・Requirements・Changelog）
- 現行の
pyproject.tomlスキーマ（[project]と[tool.comfy]） - CLIとGitHub Actionsの2経路の公開手順と、確認した日時・version
- SemVerでの更新と破壊的変更の扱い
- Registryの安全基準（eval/exec・実行時install・難読化の禁止）
ノード自体の実装はComfyUIカスタムノードの作り方、利用者側からRegistryのノードを入れて更新する操作はComfyUI Manager新UIの使い方にあります。テストと公開を自動化する設計は別記事で扱います。
Registry公開の意味
Comfy Registryは、ComfyUI-Managerの検索・インストール元になる公式のノード台帳です。ここに載せると、利用者はManagerの一覧から名前で見つけ、versionを選んで入れ、更新を受け取れます。GitHubのURLを手で貼ってもらう配布と比べ、届く範囲と更新の確実さが変わります。
公開で得られること
- Managerの検索で見つかり、versionを指定して入れられる
- 更新がversion単位で配信され、利用者が戻せる
nameがRegistry上のURLになり、同名の衝突が起きない
公開で負うこと
- 利用者のComfyUIが更新されたら、追従して動作を保つ責任
- 安全基準に反する実装は書き直しを求められる
nameとPublisher IDは後から変えられない
公開は「他人のComfyUIで動き続ける」と約束することなので、次の節の準備が済んでから進めます。
Repositoryを整える
公開前に、利用者と審査の両方が読む4つのfileを揃えます。
| file | 書くこと | 欠けると起きること |
|---|---|---|
| README | 何をするノードか、入出力、最小のworkflow例、対応ComfyUI version | Registryの説明欄が空になり、使い方が伝わらない |
| LICENSE | 利用条件。pyproject.tomlのlicenseと一致させる |
商用可否が分からず、採用されない |
| requirements.txt | Python依存。ComfyUI本体が持つものは書かない | Managerの依存解決で失敗する |
| CHANGELOG | versionごとの変更点。破壊的変更は見出しで明示 | 更新で何が変わったか利用者が判断できない |
開発用のfile（テスト画像、ノートブック、ローカル設定）は、公開アーカイブから外します。公式ドキュメントでは.gitignoreと同じ書式の.comfyignoreで除外できます。
# .comfyignore
tests/fixtures/
*.ipynb
.env
docs/drafts/MetadataとVersion
Registryが読むのはpyproject.tomlです。現行の仕様（2026年8月22日に公式specificationsページで確認）では、[project]と[tool.comfy]の2つのテーブルを使います。
[project]
name = "my-image-tools"
description = "Resize and pad images with aspect presets for ComfyUI."
version = "1.0.0"
license = { file = "LICENSE" }
requires-python = ">=3.10"
dependencies = ["pillow>=10.0"]
[project.urls]
Repository = "https://github.com/example/my-image-tools"
"Bug Tracker" = "https://github.com/example/my-image-tools/issues"
[tool.comfy]
PublisherId = "example"
DisplayName = "My Image Tools"
Icon = "https://raw.githubusercontent.com/example/my-image-tools/main/icon.png"
requires-comfyui = ">=0.3.0"| フィールド | 必須 | 制約（公式specifications） |
|---|---|---|
project.name |
必須 | Registry上のID。100文字未満、英数字・ハイフン・アンダースコア・ピリオドのみ、先頭は英字、記号の連続不可。公開後は変更不可 |
project.version |
必須 | SemVer（X.Y.Z） |
project.description |
推奨 | 一覧に出る短い説明 |
project.license |
推奨 | fileの参照またはライセンス名 |
project.dependencies |
任意 | Python依存。frontendのversion要件はcomfyui-frontend-packageで指定 |
tool.comfy.PublisherId |
必須 | Registryのプロフィールで@の後ろに出るID |
tool.comfy.DisplayName |
必須 | 一覧の表示名（こちらは後から変えられる） |
tool.comfy.Icon |
推奨 | 正方形画像のURL。上限サイズは公式specificationsページの現行値を確認 |
tool.comfy.Banner |
任意 | 21:9の画像URL |
tool.comfy.requires-comfyui |
任意 | 対応するComfyUIのversion範囲 |
tool.comfy.includes |
任意 | アーカイブに必ず含めるfolder |
nameは「後から直せない」唯一のフィールドです。個人名や一時的なプロジェクト名ではなく、ノードの機能を表す名前を、他のRegistry項目と重ならないか検索してから決めます。versionは1.0.0からでも0.1.0からでも構いませんが、公開後の更新はこの値を上げないと配信されません。
Registryへ公開する
手順は公式publishingページ（2026年8月22日確認）の順です。CLIのversionは作業時にpip show comfy-cliで控え、公開記録に残します。
- registry.comfy.orgでアカウントを作る
- プロフィールでPublisher IDを確認する（
@の後ろ。作成後は変更不可） - publishersの画面でAPIキーを作る。キーはCLIとGitHub Actionsの両方で使う
pip install comfy-cliでCLIを入れる- Repositoryの直下で
comfy node initを実行し、pyproject.tomlの雛形を作る - 前節の必須フィールドを埋める
- 公開する（CLIまたはGitHub Actions）
経路1：CLIで手動公開
pip install comfy-cli
pip show comfy-cli # version を記録する
cd my-image-tools
comfy node init # pyproject.toml を生成
# 必須フィールドを編集してから
comfy node publish # 求められたら API キーを入力経路2：GitHub Actionsで自動公開
RepositoryのsecretにREGISTRY_ACCESS_TOKENという名前でAPIキーを登録し、/.github/workflows/publish_action.ymlに公式が案内するworkflowを置きます。以後はpyproject.tomlのversionを上げてpushすると公開が走ります。workflowの中身は公式ページのテンプレートをそのまま使います。
APIキーはRepositoryにcommitしません。.envや設定fileに書いた場合は.comfyignoreと.gitignoreの両方で除外し、漏れた場合はRegistryで失効させて作り直します。
公開手順を記録する
Sample Repositoryで一度通したときの記録を次の形で残すと、次回や別の人が再現できます。
| 項目 | 記録 |
|---|---|
| 実施日時 | |
| comfy-cli version | |
| Python version | |
| 公開経路（CLI / Actions） | |
公開したnameとversion |
|
| Registryに表示されるまでの確認方法 | |
| Managerから新規インストールして動いたか | |
| 詰まった箇所と対処 |
審査の所要時間や自動審査の有無は、公式ドキュメントに記載がありません。公開後にRegistryの自分のページとManagerの検索で実際に見えるかを確認し、その時刻を記録します。
更新版を出す
更新はpyproject.tomlのversionを上げて再公開するだけです。どの桁を上げるかで、利用者への意味が変わります。
| 変更の種類 | 上げる桁 | 例 | 利用者のworkflowへの影響 |
|---|---|---|---|
| バグ修正・内部の整理 | PATCH | 1.0.0 → 1.0.1 | なし。そのまま更新できる |
| 入力の追加（既定値あり）、新ノード追加 | MINOR | 1.0.1 → 1.1.0 | 既存workflowはそのまま動く |
| 入力の削除・名前変更、出力型の変更、ノード名の変更 | MAJOR | 1.1.0 → 2.0.0 | 既存workflowが読めなくなる、または値がずれる |
ComfyUIでは、ノードのclass名とINPUT_TYPESの順序が保存workflowと直結しています。入力を1つ消すだけで、利用者が保存していたworkflowのwidgets_valuesの対応がずれます。こうした変更はMAJORとして扱い、CHANGELOGの先頭に「何が動かなくなるか」「移行の手順」を書きます。古いノードを残して新しい名前のノードを追加し、旧ノードに非推奨の表示を出す方法なら、MINORで段階的に移行できます。
# CHANGELOG.md
## 2.0.0 — 2026-09-XX
### Breaking
- `ResizeImage` の入力 `mode` を削除。`ResizeImageV2` を使ってください。
- 1.x の workflow は `ResizeImage` ノードを置き換える必要があります。
### Migration
- ノードを `ResizeImageV2` に差し替え、`preset` を選び直す。
## 1.1.0 — 2026-09-XX
### Added
- `PadImage` ノードを追加（既存ノードへの影響なし）。Security監査
Registryには、公式の「standards」で定めた安全基準があります。違反するノードは書き直しを求められるため、公開前に自分で確認します。
eval・execを使っていない。文字列をコードとして実行する経路は、任意コード実行の入口になるため禁止- 実行時に
pip installしていない。subprocessで依存を入れる処理は禁止。依存はrequirements.txtとpyproject.tomlに書き、Managerに任せる - コードを難読化していない。読めないコードは審査できず、悪意があるものとして扱われる
- 他のカスタムノードのinstall・update・removeに干渉していない。他ノードのfolderを触る処理は禁止
- 外部から実行可能なコードをダウンロードしていない。モデルfileのダウンロードと、コードのダウンロードは別。後者は避ける
- ネットワークアクセスの目的をREADMEに書いている。外部に何を送るか、利用者が判断できる状態にする
自分のRepositoryに対する簡単な検査は、公開前の習慣にできます。
grep -rnE "\b(eval|exec)\(" --include="*.py" .
grep -rnE "subprocess|os\.system|pip install" --include="*.py" .
grep -rnE "urllib|requests\.get|httpx" --include="*.py" . # 用途を README と照合このgrepは「出たら説明が必要」の印です。モデルfileを取得するrequests.getは取得先と目的がREADMEにあれば問題ありませんが、取得したものを実行する経路があれば基準に反します。
よくある質問
GitHubのURLだけで配布しているノードも、Registryに載せ直すべきですか？
利用者に更新を届けたいなら載せる価値があります。その場合、nameは今後変えられないため、現在のRepository名をそのまま使うかを先に決めてください。
公開後にnameを間違えたと気づいたら？
nameは変更できません。表示名（DisplayName）は変えられるので、利用者に見える名前はそちらで直します。IDを変えたい場合は別項目として新規公開し、旧項目を非推奨として案内します。
審査にはどれくらいかかりますか？
公式ドキュメントに所要時間の記載はありません。公開後、Registryの自分のページとManagerの検索で実際に見えるかを確認し、見えない場合は公式のサポート窓口に問い合わせてください。
まとめ
Comfy Registryへの公開は、Publisher IDとAPIキーを作り、comfy node initで生成したpyproject.tomlにname・version・PublisherId・DisplayNameなどを埋め、comfy node publishかGitHub Actionsで送る流れです。nameは変更できないため慎重に決め、更新はSemVerで利用者のworkflowへの影響を示します。eval/exec・実行時install・難読化・他ノードへの干渉は公式基準で禁止されているので、公開前に自分で検査し、手順と環境を記録して次回に備えてください。