Rebuilding AUTOMATIC1111 with a Gradio Workflow

In a previous guide, five small gr.Workflow graphs demonstrated the basics of building connected workflows. Workflow1111 extends that approach into a larger application that recreates most of AUTOMATIC1111's stable-diffusion-webui feature set on one workflow canvas.

Workflow1111 contains eleven media pipelines made from seventy-three nodes. It combines models and functions for text-to-image generation, hi-resolution enhancement, image-to-image editing, prompt-matrix grids, vision-language-model interrogation, detection-based inpainting masks, ControlNet-style annotators, background removal, PNG metadata storage, and image-to-video generation.

Users can run the pipelines after signing in with a Hugging Face account or supplying an access token. Model calls then use the user's own quota.

What's on the canvas

The pipelines use four operator types described in the Gradio Workflow documentation:

fn: a Python function
model: a model called through InferenceClient
space: another Gradio Space
dataset: a row from a Hub dataset

Each canvas node wraps one operator. The operator's inputs and outputs become ports that can be connected with edges.

Text-to-image

The core pipeline provides controls associated with AUTOMATIC1111's txt2img tab, including a negative prompt, sampling steps, CFG, seed, width, height, and a model_id field for selecting a checkpoint.

The prompt first passes through a prompt-builder fn node. This node appends the selected style preset and cleans the text before sending it to a model node, which calls the checkpoint through Inference Providers. A post-processing fn node stores the generation parameters in the PNG metadata. The PNG Info pipeline can later read those values.

Hi-resolution fix

AUTOMATIC1111's hi-resolution fix upscales the txt2img result and performs a second denoising pass. Workflow1111 uses a two-node alternative. The generated image is sent to a FLUX.1-Kontext model node with the instruction enhance fine detail and micro-texture, keep the composition identical. The result is returned at a larger size with enhanced detail.

Image-to-image

The same Kontext node also supports image-to-image generation. Users upload an image and describe the desired change, and the node returns an edited version.

LLM-assisted prompt writing

A rough prompt such as A lighthouse in a storm. can be sent to a Qwen3-4B model node. A small fn node converts the response into a cleaned list of up to forty tags, such as stormy sea, wet rocks, dramatic composition, low angle shot, volumetric lighting, ominous tone.

The result can be connected to a diffusion model node for image generation. Both the language model and diffusion model are ordinary model operators on the same canvas, so no custom node is required.

Reading an image into a prompt

This pipeline provides functionality similar to AUTOMATIC1111's Interrogate button, using a vision-language model instead of CLIP. Qwen2.5-VL analyzes a night-market photograph and writes a prompt that could describe or reproduce it.

A ViT classifier receives the same image and returns labels, including restaurant at 51.9%, tobacco shop at 15.6%, and toyshop at 9.1%.

Because both nodes use the same image input, gr.Workflow can run them in parallel. The two results arrive in approximately the time required for one operation.

Detection to inpainting mask

AUTOMATIC1111 normally requires users to paint an inpainting mask manually. Workflow1111 can generate one from an object detector instead.

DETR identifies six objects in a street photograph: three people, a dog, a bicycle, and a car. The workflow then divides into two branches. One draws the detected boxes on the original image, while the other converts the detections into a mask for a downstream inpainting pipeline.

Pillow and NumPy perform the drawing and mask creation locally. Only the detection request leaves the machine.

Prompt matrix

The prompt-matrix pipeline starts with a lone oak tree and combines it with four suffixes:

at sunrise
in a thunderstorm
under the Milky Way
in autumn fog

A fn node creates the variants, and each variant is sent to its own text-to-image node. A final node combines the four results into a contact sheet.

gr.Workflow does not provide a loop operator, so the four text-to-image nodes appear side by side. Because they have the same dependency depth, they run in parallel and begin generating at the same time.

Upscaling and background removal

This section corresponds to functionality similar to AUTOMATIC1111's Extras tab. It includes two upscaling paths.

The first uses a local Lanczos resample inside an fn node. It requires no network request and runs as quickly as Pillow can resize the image.

The second uses AuraSR ×4, represented by a space node. The node calls the AuraSR Space on the Hub and treats its result like any other node output.

Background removal follows the same pattern. BRIA RMBG-2.0 runs in another space node, with the model hosted in its own Space.

Annotators

The canvas includes Canny, line art, sketch, luma-depth, and posterize preprocessors, similar to those available through the ControlNet extension in AUTOMATIC1111.

Each annotator is an fn node implemented with plain NumPy and does not use a model. On a preloaded example of a building facade, each annotator takes approximately half a second on a CPU.

The application contains 36 operator nodes, including 32 fn nodes. Of those function nodes, 22 run entirely in process without a network request. As a result, roughly two-thirds of the canvas remains operational if the connection is lost. Since these are regular Python functions, they can also be tested directly without a canvas, server, or GPU.

PNG Info

AUTOMATIC1111 stores generation details in the PNG parameters text chunk, and its PNG Info tab reads those details back. Workflow1111 follows the same pattern.

The text-to-image post-processing node writes metadata containing the prompt, negative prompt, steps, CFG, seed, image dimensions, and model. The PNG Info pipeline extracts those values from the image.

Image-to-video

The image node used by PNG Info also feeds a Wan 2.2 I2V A14B node, which animates the image. In the example, a sleeping fox wakes up and begins moving.

A second upload field is unnecessary because one reference node can feed multiple downstream pipelines. One uploaded image can therefore have its metadata read and be animated on the same canvas.

Running models on a local GPU

The model calls in the preceding examples use external hardware through Inference Providers or Spaces. This allows Workflow1111 to run without a GPU owned by the user.

An fn node is still ordinary Python, so it can also load a model locally and execute it on a user's GPU. FastVideo/fastvideo-fasth3-preview is a gr.Workflow application that uses this approach. It runs FastH3, a four-step distillation of MiniMax-H3, to generate video with a soundtrack on ZeroGPU.

The application is based on one bound function:

@spaces.GPU(duration=get_duration, size=GPU_SIZE)
def _generate(prompt_embeds, text_token_tags, height, width, num_frames, seed):
    ...

gr.Workflow(bind={"generate": generate, "status": status}).launch()

ZeroGPU assigns a GPU to the function when required and releases it after the call finishes. gr.Workflow does not need to manage those details. It simply calls the fn node.

The same design can be used outside Spaces. A workflow can point bind= to a function that loads a local checkpoint, then call .launch() on a user's own machine. The Workflow1111 canvas can then drive that local GPU.

Every output is an API

Each output node on the canvas becomes a REST endpoint without requiring routes to be written manually. Workflow1111 exposes nine endpoints:

/image
/edited_image
/generated_prompt
/recovered_prompt
/detected_objects
/x_y_grid
/upscaled_local
/annotator_map
/png_info

A client can call an endpoint with gradio_client:

from gradio_client import Client

client = Client("ysharma/Workflow1111", oauth_token="hf_...")

image, params, hires = client.predict(
    "a red fox in a snowy pine forest",  # Prompt
    "",                                  # Negative prompt
    "Cinematic",                         # Style preset
    "enhance fine detail",               # Hires refine instruction
    api_name="/image",
)

The same endpoints can also act as MCP tools. When the application is launched with mcp_server=True, every output node is exposed as a tool that an AI assistant can call.

An MCP client can connect to the server with a configuration such as:

{
  "mcpServers": {
    "workflow1111": {
      "url": "https://ysharma-workflow1111.hf.space/gradio_api/mcp/",
      "headers": { "X-HF-Token": "hf_..." }
    }
  }
}

An agent can then generate an image, recover a prompt, or run detection as part of a larger task without additional glue code. Each caller supplies its own token through the X-HF-Token header, so the Space does not store its own token.

Position relative to ComfyUI

AUTOMATIC1111 provides the feature set that Workflow1111 reproduces, while ComfyUI is the closer comparison because both systems use node graphs. For many workflows that users need to build and deploy, gr.Workflow provides similar capabilities.

Nodes can use hardware outside the user's machine. A node can run through Inference Providers, call a Space on the Hub or another API, or retrieve data from a dataset. This is how Workflow1111 operates without its own GPU.
Outputs become typed REST endpoints. The endpoints are generated from the workflow graph.
Visitors can run workflows under their own identity. With OAuth enabled, users can sign in through a public URL without installing the application.
Models and modalities can be combined on one canvas. Diffusion models, LLMs, VLMs, detectors, and video models can participate in the same workflow.
Custom behavior can be written as a function. A custom node is a Python function and can perform any task available to Python.

The resulting pipeline can be opened in a browser, used after sign-in, and called from code.

Building a workflow

Workflow1111 contains 73 nodes, but its basic structure can start with a single function:

import gradio as gr

def your_function(text: str) -> str:
    pass

gr.Workflow(bind=[your_function]).launch()

bind= converts functions into nodes, edges= connects them, and .launch() opens the canvas in a browser for continued editing. Once the workflow is ready, gradio deploy places the application on a Space.

The Gradio Workflow guide provides additional details, including the JSON schema and the supported operator types. Existing workflows can also be modified by opening Workflow1111 and changing one of its eleven pipelines, deleting nodes, replacing models, or rewiring connections. Smaller examples are available in the earlier workflow guide.

Rebuilding AUTOMATIC1111 with a Gradio Workflow