ComfyUI SaaS Backend Engineering Notes | Nie Er

A ComfyUI content production backend wraps node-graph workflows into governed capabilities with permissions, credit charging, node allowlists, and object-storage boundaries.

I recently built the backend core for a small SaaS project with a friend. The target users are individual creators, MCN-style studios, and internal content teams. The project has just finished its backend core and has not run in production yet, so this note stays on architecture and boundaries. No user scale. No production metrics.

The easy part was calling /prompt.

The hard part was deciding what the platform should refuse to expose.

A Node Graph Is Too Free For SaaS Users

ComfyUI works well for engineers because the graph is visible. You can inspect nodes, models, parameters, and outputs directly.

That is not the right interface for a content production product.

A creator wants an approved image generation capability or an image transformation capability. They should not need to know which custom node can read files, how much resource a workflow may use, or what output shape a node returns.

So I did not build a thin UI over raw ComfyUI graphs. I added a capability layer.

Each capability declares a parameter schema, output schema, resource profile, and node dependency list. Before it can be published, the backend checks that the contract is complete and that every workflow class_type appears in the declared allowlist.

That adds maintenance work. Every new node has to be declared, and role permissions have to allow it too. But the platform gains something more important: it can reason about allowed inputs, expected outputs, resource cost, and who may run the capability.

A Capability Is Also A Permission And Cost Boundary

Storing a ComfyUI workflow JSON in a database is not enough. The platform still needs to decide whether a user can run it, whether the organization has enough credits, and whether the role is allowed to use its nodes.

The task creation flow ended up like this:

request
  -> capability and role checks
  -> concurrency and credit checks
  -> credit precharge
  -> parameter injection into workflow JSON
  -> ComfyUI submission
  -> status refresh and output migration

The important product decision here is precharging.

Post-charging feels nicer, but generation consumes real compute. If the platform runs first and charges later, unpaid compute becomes a messy edge case. With precharging, the harder work moves into the failure path: submission failures and execution failures must refund, and refunds must be idempotent.

The balance is not a mutable field on the user row. It is derived from a credit event ledger with sum(delta_credits). Task cost is calculated as max(1, round(default_cost_credits * credits_multiplier)).

It is a plain design. That is a good thing.

Production Flow Belongs Outside ComfyUI

Content production is not only generation.

A real flow may include parameter selection, generation, text formatting, human review, and another processing step. Those actions should not all be hidden inside one ComfyUI graph.

The backend models production flow as a DAG. Nodes pass data through input_mapping; sources include static values, run inputs, user preferences, and upstream node outputs. Runtime progression uses Kahn topological ordering. A node_output mapping can only reference upstream nodes.

I kept this intentionally small. The transform node supports limited text formatting, and manual_review works as a human checkpoint.

For this stage, that is enough. The first job is not to build a huge workflow engine. The first job is to make capabilities, permissions, credits, state, and output safety work together.

The Small Storage Detail Was Not Small

One test case mattered more than it looked.

ComfyUI history returns output references with filename and subfolder. The obvious implementation is to join those fields, read the file, and upload it to MinIO.

Then you ask: what if filename is ../secret.png? What if it is /tmp/secret.png? What if subfolder is ../?

The backend rejects absolute paths, resolves the final path, and verifies that the real path still sits inside the configured output directory before any MinIO call happens. Otherwise it raises output_path_forbidden.

This is not demo-friendly work. But in a multi-tenant system, trusting runtime file paths would undermine storage isolation.

Current Boundary

The backend core now covers capability contracts, task execution, credit ledgering, permission boundaries, object migration, path traversal protection, and DAG-based production flows.

It is still not a production-proven platform. I would not claim scale, reliability, or commercial traction yet.

The next useful evidence would be a sanitized real production-flow DAG and production trial data. Until then, the honest story is narrower: this is the backend foundation for turning ComfyUI from a node-graph tool into governed content production infrastructure.

My takeaway: the difficult part of productizing ComfyUI is not sending a prompt. It is deciding which freedoms must be constrained before non-engineers can safely use it.

If you are evaluating an enterprise RAG, knowledge base, AI support, or agent workflow project, contact me by email at contact@aildnc.com. For China-based inquiries, use the WeChat QR code below the article.