Daggr: chain Gradio apps and debug AI flows | Keryc
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: GradioNode can clone and run a Space locally with run_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.
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=True to 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 InferenceNode in 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?
