Daggr was born to solve a real pain: have you ever had to rerun an entire 10-step pipeline just to see what broke on step 7?
With Daggr you define flows in Python and get an automatic visual interface where you inspect intermediate outputs, re-run isolated steps, and manage state — all with just a few lines of code.
What is Daggr and why it matters
Daggr is an open source Python library (requires Python 3.10+) built by the Gradio team to construct AI workflows that connect Gradio Spaces, inference models, and your custom functions.
The key: a code-first approach that generates a visual canvas. This isn't the usual node editor where you drag-and-drop without version control. Here you work in code (git-friendly) and the visual interface is a tool for inspection and debugging.
Why does this change how you experiment? Because it lets you iterate fast without building heavy infrastructure: you debug a step, swap a model for a fallback, or relaunch only the piece that matters.
Technical concepts
- Graph: represents your flow, contains nodes and metadata.
- Nodes: three main types:
GradioNode,FnNode,InferenceNode. - State: Daggr persists inputs, cached results and the canvas position. You can have multiple sheets for different workspaces.
- Local vs remote execution:
GradioNodecan clone and run a Space locally withrun_locally=True. If that fails, Daggr gracefully falls back to the remote endpoint.
Nodes in detail (with examples)
GradioNode
Calls a Space (public or private). If you set run_locally=True, Daggr clones the Space, creates an isolated environment and launches it locally.
from daggr import GradioNode
node = GradioNode(
'username/space-name',
api_name='/predict',
inputs={'text': gr.Textbox(label='Input')},
outputs={'result': gr.Textbox(label='Output')},
)
FnNode
Runs local Python functions. Useful for preprocessing, resizing, or postprocessing.
from daggr import FnNode
def process(text: str) -> str:
return text.upper()
node = FnNode(fn=process, inputs={'text': gr.Textbox(label='Input')}, outputs={'result': gr.Textbox(label='Output')})
InferenceNode
Calls models via Hugging Face Inference Providers. Great when you want to use hosted models without embedding their logic in your app.
from daggr import InferenceNode
node = InferenceNode(
model='moonshotai/Kimi-K2.5:novita',
inputs={'prompt': gr.Textbox(label='Prompt')},
outputs={'response': gr.Textbox(label='Response')},
)
Quick example: generate an image and remove the background
Installation:
pip install daggr
# or with uv
uv pip install daggr
Minimal example that connects two Spaces (generation and background removal):
import random
import gradio as gr
from daggr import GradioNode, Graph
image_gen = GradioNode(
'hf-applications/Z-Image-Turbo',
api_name='/generate_image',
inputs={
'prompt': gr.Textbox(label='Prompt', value='A cheetah sprints across the grassy savanna.', lines=3),
'height': 1024,
'width': 1024,
'seed': random.random,
},
outputs={'image': gr.Image(label='Generated Image')},
)
bg_remover = GradioNode(
'hf-applications/background-removal',
api_name='/image',
inputs={'image': image_gen.image},
outputs={'original_image': None, 'final_image': gr.Image(label='Final Image')},
)
graph = Graph(name='Transparent Background Generator', nodes=[image_gen, bg_remover])
graph.launch()
When you run this you get a canvas at http://localhost:7860 and a public link if you enable share=True. In the interface you can inspect each node's output, tweak inputs and re-run individual nodes.
Advanced pipeline: from image to 3D asset (technical summary)
Daggr makes it easy to chain more complex steps: clone a Space that removes backgrounds locally, downscale with an FnNode, enhance with a model via InferenceNode, and finally generate a glb with another Space.
Technical points we handle in the full example:
- Save temporary files with
daggr.state.get_daggr_files_dir()so nodes share paths. - Use
run_locally=Trueto clone Spaces and control whether models go to CUDA or CPU. If you don't have NVIDIA, clone and tweak the Space to force CPU. - For
InferenceNodein deploys to Spaces, use a Hugging Face token with the permission "Make calls to Inference Providers".
Best practices and current limitations
- Daggr is in beta and its API can change between versions. Keep in mind local persistence can suffer data loss during updates.
- For production: Daggr is excellent for prototypes and demos. For mission-critical pipelines, more robust orchestrators are still advisable.
- If you clone Spaces locally and will run on CPU, review the Space files to avoid models doing
.to('cuda')automatically. - Share workflows on Gradio for demos and feedback. The Gradio team highlights some community projects.
Practical reflection
If you're a developer, researcher, or founder testing ideas with multiple models, Daggr saves you hours of repetitive debugging. The real value is being able to inspect every stage without losing traceability in your code.
Isn't that exactly what you need when iterating quickly on demos and PoCs?
