Project

ComfyUI Content Production Backend

A multi-tenant SaaS backend that wraps ComfyUI workflows with permissions, credits, node allowlists, and DAG-based production flow governance.

  • Python
  • FastAPI
  • SQLAlchemy
  • Pydantic
  • ComfyUI
  • MinIO
  • Postgres
  • Stripe
  • DAG
Wrapped ComfyUI workflows as capabilities with parameter, output, resource, and node contractsUsed an event ledger for credits, with precharging and idempotent failure refundsBlocked path traversal before object migration from ComfyUI output referencesModeled content production with capability, transform, and manual review nodes in a DAG

ComfyUI Content Production Backend is a backend project that wraps ComfyUI workflows into a governed multi-tenant SaaS capability layer. It targets individual creators, MCN-style studios, and internal content teams.

There is no public repository or live demo yet. This page records the sanitized architecture, module boundaries, and engineering tradeoffs.

Problem Definition

ComfyUI solves how engineers edit and run node graphs. A content production platform has a different job:

  • Turn a graph into a reusable capability for non-engineers.
  • Restrict allowed nodes and undeclared dependencies.
  • Separate permissions and budgets across organizations, roles, and plans.
  • Check credits and concurrency before compute is consumed.
  • Move local outputs to object storage without path traversal risk.
  • Connect multiple capabilities, text transforms, and human review checkpoints into a production flow.

Tech Stack

The backend uses Python 3.11+, FastAPI, SQLAlchemy 2.0, and Pydantic 2. ComfyUI is called through httpx. Generated assets are migrated to MinIO. Persistent data lives in Postgres. Stripe is reserved for subscription and billing integration.

Architecture

user / organization / role
  -> capability catalog
  -> permissions and node allowlists
  -> task creation
  -> prepaid credit ledger
  -> workflow JSON parameter injection
  -> ComfyUI runtime
  -> history refresh
  -> object-storage migration
  -> production-flow DAG progression

ComfyUI remains the runtime. The platform owns capability contracts, permissions, credit events, task state, and production-flow state.

Core Modules

1. Thin ComfyUI Client

ComfyClient only submits prompts, reads history, and extracts output references. Keeping the coupling surface small makes it easier to separate platform state from runtime execution.

2. Capability Contract

Before a capability can be published, it must declare:

  • parameter_schema
  • output_schema
  • resource_profile
  • node_dependencies

Every actual workflow node must appear in node_dependencies. Parameter injection supports eight types: string, integer, number, boolean, image, object, array, and json.

3. Permissions And Node Allowlists

Node constraints are enforced in two layers. The capability declares what the workflow uses. The role permission layer decides whether the current user may run those node types.

4. Task And Credit Ledger

Task creation checks concurrency and balance before work starts. Credits are precharged. The balance is derived from ledger events instead of stored as a mutable field. Submission and execution failures are handled through idempotent refund events.

5. Object Migration

The backend treats ComfyUI filename and subfolder values as untrusted. It rejects absolute paths, resolves the real path, verifies that the path is still inside the configured output directory, and only then uploads to MinIO.

6. Production Flow DAG

Production flows are modeled as DAGs with capability, transform, and manual review nodes. Node inputs can come from static values, run inputs, preferences, or upstream node outputs. Runtime progression follows topological order.

My Role

I implemented the backend core: capability contracts, task execution, credit ledgering, permission boundaries, object migration, path traversal protection, and DAG production flows.

The product direction was defined together with my collaborator. I did not rewrite ComfyUI itself; the backend governs and integrates it.

Hard Parts

The first hard part was reducing freedom. ComfyUI is useful because it is flexible, but a SaaS product cannot hand all that flexibility to every user. I moved the flexibility to the administrator packaging layer and gave creators a constrained parameter contract.

The second hard part was credit boundaries. The backend needs to know whether a task may run before compute is consumed, and it needs a clear refund path when execution fails. A ledger is more work than a balance field, but it is easier to audit.

The third hard part was file safety. The tests cover inputs such as ../secret.png, /tmp/secret.png, and subfolder="../". The backend must reject those before object upload.

How To Run

There is no public repository or demo URL at the moment, so this project page does not include runnable commands.

If the repository becomes public, this page should add environment variables, dependency installation, database migration, ComfyUI endpoint configuration, and a local task-run example.

Next Steps

  • Add a sanitized example production-flow DAG.
  • Collect public trial data after real usage begins.
  • Expand transform nodes while keeping allowlists and permission checks.
  • Improve the admin experience for configuring capability contracts.

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.

Contact

Book a 30-minute technical diagnosis

Share the business context first. I will help assess whether the AI application is worth building, how to approach it, and where the main risks are.

Telegram @NieErAI Message me on Telegram