ComfyUI for Teams: How Studios Share Workflows, Track Results, and Run Production
For studio leads, VFX supervisors, production managers, and AI consultants trying to move ComfyUI from a single-user tool to a team workflow. This page covers what your setup needs to get right, how production teams are solving each piece today, and how Floyo supports it as the enterprise layer for ComfyUI.
Production is a team sport
If you are reading this, you probably already have one or two people on your team doing great work in ComfyUI. The question now is how to scale that to the rest of the team without everything falling apart.
The collaboration state of ComfyUI today is roughly where software was before GitHub: technically possible with enough manual process, but nowhere near streamlined. Studios that have successfully adopted ComfyUI for real production work have all had to solve the same set of problems.
This page walks through each one and how teams are handling it.
Floyo is the only ComfyUI platform built for team production. Shared run history, Team Pages, role-based access, model governance, and workspace separation. The open-source ecosystem stays open. The collaboration and controls above it are what make it production-safe.
Private teams, multiple workspaces, and pipeline organization
Before anything else, a team needs a private space to work. Workflows, LoRAs, inputs, and outputs need to be visible only to the people who should see them. Studios working with client IP may need separate workspaces per client, per project, or per department. And within each workspace, you need structure: workflows organized by pipeline, with instructions and context alongside them, so new team members can find what they need without asking.
- Private teams. Create a team workspace that is invisible to anyone outside it. Workflows, LoRAs, inputs, run history, and outputs stay inside the team. Other teams on the platform cannot see them.
- Multiple workspaces. Create separate workspaces per client, per project, or per department. Large agencies create a workspace for each end client, each with its own model restrictions and member access.
- Team Pages. Your team's private homepage. Curate workflows into coordinated pipelines: Product Shots, Video, Character Design, VFX. Embed instructions, tips, knowledge base articles, and training materials directly alongside the runnable workflows. When you add a team member, they get the full picture without asking. Team Pages are private to your workspace.
Sharing workflows across the team
Once you have a team workspace, the next friction point is getting a working workflow from the person who built it to the people who need to run it.
The common approach and why it breaks
Sharing the workflow JSON is the easy part. Most teams do it over Slack or Google Drive. The hard part is everything the JSON depends on: the right models, the right custom nodes, the right versions of each, and all the supporting files. If any of those differ between machines, the workflow either breaks or produces different output. And you might not notice until the client does.
For a team generating dozens of workflow variants per week, finding the right version becomes its own problem. No native search, tagging, or discovery. Just a folder of files.
What teams are actually doing today
Most studios have not solved this. They are living with the friction.
Small teams install ComfyUI on each machine and share JSONs over Google Drive or Slack. When something breaks, someone walks over and fixes it. It works until it does not.
Larger teams hit the wall faster. More people, more models, more nodes, more versions to keep in sync. At some point it becomes clear this is not something you can manage with manual process alone.
On Floyo, every workflow is a runnable link. Share it with a teammate, they open it and click Run. Same models, same nodes, every time. No JSON exports, no environment debugging. New team members open a browser and run their first workflow in minutes.
Tracking what worked
Someone on the team got a great result last Tuesday. What workflow was it? What model? What seed? What settings? If you are running ComfyUI locally, the answer is usually "I don't know." The parameters are gone unless someone manually saved the workflow JSON and named it something useful.
For a team, this is where knowledge gets lost. Artists repeat each other's experiments. Nobody can pick up where someone else left off. When a client says "give me more like that one from last week," there is no reliable way to reproduce it.
What teams need
Every execution from every team member, saved automatically with the full workflow state: every node, every setting, every model loaded, every input, every output. Not just the final image. The complete state so someone else can open it, tweak one value, and rerun.
Every run is saved with the full workflow state: every node, every setting, every model, every input, every output. An art director gets a great result. A junior artist opens that exact run from shared history, tweaks one value, and keeps going. Failed runs are saved too. History is retained as long as your account exists.
This is also what makes provenance tracking possible. The EU AI Act takes effect in August 2026, and among its requirements: organizations using AI for content generation must be able to document which model produced an output, with what settings, and when. Shared run history is not just convenient for collaboration. It is becoming a compliance requirement.
Managing access, roles, and GPU spend
Once your team is past a handful of people, you need to answer some operational questions. Who can install models and nodes? Who manages billing? How do you prevent a junior artist from accidentally using a non-commercial model in a client project?
Roles and permissions
Not everyone needs the same level of access. Your workflow builders need different permissions than your operators. Someone needs to manage billing without giving everyone admin access.
Three roles:
- Owner – full control including billing and ownership transfer
- Admin – manage settings, members, models, and billing
- Member – run workflows and access team files, cannot change settings or invite others
Model and node governance
For teams working with client IP or in regulated industries, you may need to restrict which models and nodes the team can use. A non-commercial model in a paid project creates legal risk. An unvetted custom node creates a security risk. Open-source ComfyUI has no mechanism for this.
This ties directly into the licensing and IP problem. If you need the full breakdown of model governance, the Licensing & IP page covers it in depth.
Admins control which models and nodes are available to the team. Block a model and it disappears from the workspace entirely. Block a node and it cannot execute through any path, including the API. If a workflow contains a blocked model, it fails with an error listing what is blocked.
Production workspaces can be locked to approved models while R&D workspaces stay open. Different teams, different policies, same platform.
GPU spend and usage
If your team uses a shared GPU budget, someone needs visibility into who is using how much and on what.
One shared compute budget for the whole team. Each member adds hours to the pool. The meter only runs while the GPU is generating. Building, editing, and tweaking is free.
Admins get a usage statistics dashboard to monitor every member's GPU usage, spend by day, and run activity across the team. Concurrent run slots scale with team size.
Workspace separation: discovery vs. production
Every team has two modes of working. There is an exploration phase where artists test everything, try new models, break things, and iterate fast. And there is a production phase where the team is working on client deliverables and everything needs to be locked down.
If the same environment handles both, problems compound. An artist tests a non-commercial model in the exploration workspace, likes the result, and uses it in a client project without realizing the license does not allow it. Or worse, a custom node installed for R&D introduces a security vulnerability into the production environment.
The pattern that production teams converge on is workspace separation. One workspace for discovery (full model access, any node, no restrictions). One workspace for production (commercial-only models, vetted nodes, locked down). Same team, different rules per workspace.
Large agencies use this structure: a discovery team that has full flexibility to use any model, and an isolated production team with only compliant models available. They create a workspace for each end client, each with its own model restrictions.
Create multiple workspaces within the same organization. Each workspace has its own model policies, node restrictions, and member access. Your R&D workspace stays open. Your production workspace locks to approved models only. Admins control each independently.
Your options: self-hosted, cloud ComfyUI, closed platforms, or Floyo
If your team is evaluating how to run ComfyUI in production, here is what each path gives you and what it does not.
Self-hosted ComfyUI. Full flexibility. Any model, any node. But no team collaboration layer. No shared run history, no Team Pages, no role-based access, no model governance. You get the ecosystem without the structure.
ComfyUI cloud platforms. Easier to get started than self-hosted. But typically limited node support, no model registry, and no real collaboration features. You get convenience without the team layer.
Closed platforms. Clean interface, some team features. But you are locked to their models. When you hit their ceiling, you are stuck. You cannot bring your own LoRAs, custom nodes, or workflows. You get structure without flexibility.
The question for teams is whether you can get both: the full open-source ecosystem with a collaboration and governance layer built on top.
Floyo runs the full ComfyUI ecosystem: any model, any node, any workflow. Team Pages, shared run history, role-based access, model governance, and workspace separation are built on top.
If it is possible to create, it is possible on Floyo. The team structure and controls are what make it production-safe.
How studios structure their ComfyUI teams
The most common concern from team leads: "ComfyUI has a steep learning curve. I can't train everyone on node graphs." You do not need to. Not everyone needs to touch the node editor.
What we are seeing as the future of AI production teams is a clear split between two sides. On one side, creative leadership: directors, creative directors, and art directors who set the vision, protect the visual standard, and make sure every output serves the story. On the other side, workflow engineering: the people who turn those creative needs into working pipeline systems, train the models, and carry the production forward shot by shot. Every team will look different depending on size and budget, but this is the direction things are moving.
On smaller teams, one person covers multiple roles. Some studios structure this as two-person AI pods: one creative, one technical. They scale by duplicating the pod. The key insight is that expertise compounds across the team. Your workflow lead builds the pipeline once. Everyone else runs it. When someone finds a better approach, it becomes the new baseline for the whole team. Past runs stay in shared history, so new team members learn from every result that came before. One expert's judgment scales to the entire team.
We will publish a deeper breakdown of AI production team structure separately.
FAQ
Yes, but not on a single local install. A single ComfyUI instance processes one workflow at a time. For teams, you either give each person their own install or use a shared cloud platform. On Floyo, every team member can run workflows at the same time. Each person gets their own concurrent run slots, all drawing from a shared GPU pool.
Sharing the JSON is easy. The hard part is making sure every machine has the right models, custom nodes, versions, and supporting files. If any dependency differs, the workflow breaks or produces different output. A shared cloud environment solves this by giving everyone the same setup. On Floyo, you share a link and it runs.
No. Most production teams have one to two workflow builders who create the pipelines, while everyone else operates them: load the workflow, change inputs, click generate. The builder-operator model means you do not need everyone trained on node graphs.
A record of every workflow execution across your team. On Floyo, each run records exact settings, inputs, and outputs. Any team member can open a past run, tweak one value, and rerun. History is retained as long as your account exists.
Most use a builder-operator model. One to two workflow builders create and maintain pipelines. The rest operate them. Some studios use two-person AI pods (one technical, one creative) that scale by duplicating the pod.
Your team's private homepage on Floyo. Curate workflows into coordinated pipelines, embed instructions, knowledge base articles, and training materials alongside runnable workflows. When you add a team member, they get the full picture without asking. Team Pages are private to your workspace and invisible to other teams or the public.
Yes. The builder-operator model means your workflow leads build the pipelines and everyone else runs them. On Floyo, operators load a workflow, change inputs, and click Run. They never need to see the node graph. One expert's judgment scales to the whole team.
Flexible. Controlled. Built for teams.
Any model, any node, the full ComfyUI ecosystem. Governance and controls to keep production safe. Collaboration tools that make it a team sport. Floyo is the only platform that does all three.
Floyo for TeamsResources
Floyo 101 for Enterprise and Teams 6 Enterprise Walkthroughs to Share with Your Team Create a Team Page Run History Team Member Roles and Access Add Workflows to a Private TeamThis page is part of the ComfyUI in Production guide. Related: Licensing & IP · ·