RiceRound Publish

This is the node the whole pack exists to feed into. Everything else in ComfyUI_RiceRound - the labeled Int/Float/Boolean fields, the URL downloaders, the image pickers - is there to build a workflow you can hand to RiceRound Publish (its class name is RiceRoundEncryptNode, which tells you more about what it actually does than the display name does). Drop it at the very end of your graph, run once, and ComfyUI writes an encrypted workflow.json to your output folder. Upload that to riceround.online and the platform turns your local workflow into a public web page plus a callable "cloud node," with the stated pitch being pay-per-use, and - per the pack's own README - the creator keeps all of the revenue.

What it's actually doing

Think of it as a build step, not a generation node. It doesn't touch pixels or run a model; it packages the graph you just executed into something the RiceRound platform can host and re-run on someone else's behalf, with the internal node structure hidden from whoever ends up using the resulting page. That's the "encrypt" half of the name.

Whether encryption actually stops someone from lifting your workflow is a fair question to ask before you build a business around it. A near-identical pitch from an unrelated pack (ComfyUI-Workflow-Encrypt, 2024) got picked apart on r/comfyui within a few comments - people pointed out you can run the graph headless and export it, or just re-save it without the key, because anything that has to execute to be useful is inherently hard to lock down client-side. This pack's own authors shipped an earlier, more bluntly-named sibling project pitched the same way ("Secure Your Profits: ComfyUI's Encrypted Workflows for Business Success!"), so this isn't a hypothetical concern for this specific team - it's the exact category of promise they've made before. Treat "encrypted" here as "not trivially viewable in the UI," not as DRM.

The inputs that matter

Three required fields, no outputs - this is a terminal node, which is why is_output_node is true and there's nothing to wire downstream:

• project_name (default my_project) - the label for this publish. Rename it before you actually ship something; the default is a placeholder, not a suggestion.
• template_id (default 86e0820c23a241e7890b1892cd550a25) - this ships pre-filled with what's clearly a demo ID. You get your real one from your riceround.online dashboard after registering a project there; leave the default in and you're publishing against demo data, not your project.
• images (IMAGE) - the final output(s) your workflow produces. This is what gets shown on the generated page, so wire it from wherever your real result lands, not an intermediate preview.

Installing it

ComfyUI Manager: search "RiceRound," install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/RiceRound/ComfyUI_RiceRound

then restart. No requirements.txt or model downloads are called out in the README - this is a packaging/upload layer, not a generation pack, so the install itself should be fast. The README does point you to a separate hosted docs site (help.riceround.online) rather than a GitHub wiki, and it's mostly Chinese-language.

Common issues & troubleshooting

Only use RiceRound → Input nodes upstream of this. The README is explicit and puts a warning emoji on it: build your graph with RiceRound's Input-category nodes for anything you want exposed as a parameter, and treat the Output-category nodes (Upload Image, RiceRound Cloud, Output Boolean, etc.) as debugging aids you strip out before you actually publish. Leaving a debug output node wired in isn't documented as fatal, but it's not the supported path either.

Nothing shows up on riceround.online after you run this. The node only writes a local file - it doesn't itself confirm an upload succeeded. Check the output folder for workflow.json first, then confirm you're logged into the same account on riceround.online you're managing the project from.

You're stuck past what the README covers. The stated support channel for anything the docs and demo files don't cover is the maintainer's personal WeChat - there's no GitHub issue template or Discord pointed to in the README, which is worth knowing before you're mid-launch and looking for help.

Deciding whether to bother with the encryption angle at all. If your actual goal is just "share a workflow without handing over the graph," a service-side deployment (running it behind your own API, the way most people who actually need this solve it) is the more defensible route community sentiment converges on - the key-based encryption model is the part with the credible bypass, not the hosting-and-billing part.