App Inputs and Outputs

What the platform is allowed to fill in when it runs your workflow, what to call each one, and which ones are filled in for you.

A workflow you run from a recipe is not run as it stands. Ordinary Animator fills things in first -- the prompt you typed, the reference image you dropped on the step, the size you picked -- and then submits it. App inputs are how a workflow says which of its settings may be filled in that way.

An App input is a setting that already exists on one of your nodes: the prompt box on a text node, the file field on a Load Image node, the width on an empty-latent node. Marking it as an App input does not add anything to the graph. It says "this one is not fixed -- the app supplies it".

App outputs are the other end: which node produces the result worth keeping, so the platform knows what to collect and put in your gallery.

You set both in ComfyUI's App builder, and save. A workflow with no App inputs at all still runs in ComfyUI, but in Ordinary Animator it cannot be given a prompt or an image, so a recipe step bound to it has nothing to fill in and every run produces the same thing.

What an App input is -- and what it is not

The App input is the loader's or the node's own setting. When you mark the file field on a Load Image node as an App input, the platform hands that node the image directly.

An older way of building the same thing was to put a separate little text node next to the loader, feed its value in, and expose that instead. It works in ComfyUI, but it is the indirection that turns a file name into a path -- and a path is not what the platform supplies. If you have one of those, delete it, mark the loader's own field instead, and give the input the same name the old one had so anything already using it stays connected.

A text node feeding something that is not a media loader -- a fixed piece of prompt text, a naming prefix -- is fine and common. It is only the media loaders that care.

Use the names everything else uses

Every App input has a name, and the name is not decoration: it is how a recipe step keeps its settings when you swap one workflow for another.

Because a recipe step offers you every workflow in a category, someone can replace the workflow in a step with yours. When they do, each value moves across by name. Positive Prompt lands in Positive Prompt. An input with no counterpart in the new workflow is parked, not lost -- but nothing lands in it either, so the step has to be filled in again by hand.

So use the names already in use:

Use this name For
Positive Prompt The main prompt
Negative Prompt What to avoid, where the model supports it
Input Image 1, Input Image 2 Images the step feeds in, numbered in the order they matter
Input Video 1 A video the step feeds in
Output Width, Output Height The size of the result
Voice Reference Audio The audio clip a voice is copied from

The quickest way to get this right is to open a workflow already in the category you are declaring, look at what its inputs are called, and use the same names. A name that is gratuitously different costs whoever swaps your workflow in a manual re-wire; it does not stop your workflow working.

Names ending in a media word decide how the input is presented, too: an input whose name ends in image, video or audio becomes a drop zone rather than a text box.

Seed and Filename Prefix are filled in for you

Two inputs are handled by the platform and never shown to you as fields to fill in.

Seed. Every run gets a fresh random seed, which is why running the same step twice gives you two different pictures rather than the same one. Name the seed input Seed and it is filled in automatically. If your workflow has several samplers that must agree, they all receive the same value on a given run.

Filename Prefix. Where the result is saved, and how the platform works out which output belongs to which step. Name it Filename Prefix and leave it alone. A workflow that saves more than one kind of result names each one -- Filename Prefix #img1, Filename Prefix #mask -- and the part after the # becomes the label you see on that output in the recipe step.

Do not type values into either of these, and do not leave them out: they are inputs the platform expects to fill.

Clip length is deliberately not an App input. A frame count is not a free number -- each video model accepts only certain values -- so you do not set one. A workflow states its length in its description, in seconds, and you get a shorter result by setting the shot's duration and a longer one by chaining clips together.

App outputs -- where the result comes from

Mark the node that saves the result as an App output. Without it the platform does not know which node produced the thing worth keeping, so a run can finish successfully and still put nothing in your gallery.

One save node is the normal case. If your workflow saves two different things -- a picture and its mask, say -- mark both, and give each one's naming prefix its own #label as above, so the recipe step can show them separately and a later step can take just the one it wants.

When an input points at something that is not there

If you delete or replace a node after setting up the App inputs, an input can be left pointing at a node that no longer exists. The workflow still opens in ComfyUI, but the platform has nothing to put that value into, and the failure looks like the value being ignored.

The fix is the same either way: open the workflow in ComfyUI's App builder, set the App inputs again against the nodes that are actually there, save, and import it into your project again.

Text-to-speech workflows

A speech workflow declares voice_type in its OA Workflow Metadata, and it also has to take the inputs the rest of the product expects. There are two shapes, and a text-to-speech workflow should be one of them:

  • A voice copied from a sample. The workflow takes the text to speak and an audio clip of the voice: name the inputs Text and Voice Reference Audio. The audio input is presented as a drop zone, so a character's recorded sample can be dropped straight on it.
  • A voice picked from a list. The workflow takes the text to speak and the name or id of one of the model's built-in speakers: name the inputs Text and Voice Id. That one is presented as a text box.

Where to go next