Comfy API deployments

Comfy API deployments are in beta. Sign up for access at platform.comfy.org.

Comfy API lets you deploy a ComfyUI workflow as a managed, autoscaling endpoint with on-demand GPU capacity. A Build is the versioned definition of a ComfyUI environment: the models, custom nodes, and settings captured from a local install. The Build and Deploy CLI keeps the Build definition in your project, creates releases from it, and deploys a release when it is ready to serve traffic.

1. Build

Create a local Build definition from your ComfyUI install.

2. Release

Cut an immutable Linux/NVIDIA release from the Build.

3. Deploy

Give the release a URL and managed GPU capacity.

4. Run

Submit an API-format workflow to the active deployment.

Quick start

Use these commands when the local install and API-format workflow are ready: Use the compute output to choose a valid region and GPU. Replace <region> and l4 if needed; copy the deployment ID that deploy up prints into the final command.

comfy build init --name "my-comfy-build" --models-dir ./models --custom-nodes-dir ./custom_nodes

comfy build push --release --target linux/nvidia
comfy deploy refs compute # get available regions and GPU classes
comfy deploy up --gpu l4 --region <region> --min 1 --max 4 --watch # prints the deployment ID
comfy deploy run --workflow workflow_api.json --deployment <deployment-id> --output-dir ./results

Initialize

comfy build init --name "my-comfy-build" --models-dir ./models --custom-nodes-dir ./custom_nodes

Create a release

comfy build push --release --target linux/nvidia

This syncs the Build and creates a release for the target.

Start a deployment

If you do not already know which regions and GPU classes are available, check first:

comfy deploy refs compute

Then create or reconcile the deployment:

comfy deploy up --gpu <gpu> --region <region> --min 1 --max 4 --watch

deploy up prints the new deployment ID. If you need to retrieve it later, list this Build’s ready deployments:

comfy deploy ls --status ready

Use the returned dep_... value with --deployment.

Run the workflow

comfy deploy run \
  --workflow workflow_api.json \
  --deployment <deployment-id> \
  --output-dir ./results

The CLI submits the API-format workflow and downloads its outputs into ./results.

The Build file

comfy-build.yaml is the local source of truth for a Build. It stores the Build definition and the last known remote state, so the CLI can choose the right Build automatically and warn before local changes overwrite a newer remote definition. Keep this file with the project. It describes the Build; it does not contain the model bytes themselves.

1. Initialize a Build

Start from a local ComfyUI install. This scans the models and custom nodes, then writes comfy-build.yaml.

comfy build init --name "my-comfy-build" --models-dir ./models --custom-nodes-dir ./custom_nodes

Before pushing, check how the local spec compares with the install and the remote Build:

comfy build status

2. Update and release

After changing the local ComfyUI install, refresh the local Build definition:

comfy build update --yes

For the quick path, push the definition and release it for a target in one command:

comfy build push --release --target linux/nvidia

When you need to create another release from an existing Build, inspect the supported targets and cut one explicitly:

comfy build refs build-targets
comfy build release create --target linux/nvidia --watch

Follow one release’s build log with:

comfy build release logs rel_123456 --target linux/nvidia --follow

Regions and GPU availability

Region capacity changes, so do not copy a static list into a script. Query the platform catalog when you choose a deployment target:

comfy deploy refs compute

Use --region <region> to filter the results:

comfy deploy refs compute --region <region>

Copy a returned region and gpu pair into comfy deploy up:

comfy deploy up --gpu <gpu> --region <region> --min 1 --max 4 --watch

The catalog is the source of truth for which GPU classes are available in each region at deployment time.

3. Deploy a release

Discover the available compute in a region, then create or reconcile a deployment for the selected release:

comfy deploy refs compute --region US-MO-2

comfy deploy up \
  --gpu l4 \
  --region US-MO-2 \
  --min 1 \
  --max 4 \
  --watch

--min and --max set the worker bounds. Use comfy deploy status --watch to follow deployment health, release freshness, and serving activity.

4. Run a workflow

Submit an API-format workflow to a ready deployment:

comfy deploy run \
  --workflow workflow_api.json \
  --deployment dep_123456 \
  --output-dir ./results

The endpoint can also be called from the Comfy SDKs by setting COMFY_BASE_URL to the deployment URL. The SDK request still needs an API key: see Choosing a base URL.

Operate a deployment

# Change the worker bounds
comfy deploy scale --deployment dep_123456 --min 2 --max 5

# Pause or resume while retaining the deployment record
comfy deploy stop --deployment dep_123456
comfy deploy start --deployment dep_123456

Inspect and clean up

# Build state
comfy build ls
comfy build show --id bld_123456
comfy build release ls
comfy build release show rel_123456

# Deployment state
comfy deploy ls --workspace --status ready
comfy deploy logs --deployment dep_123456
comfy deploy events --deployment dep_123456

Deleting a deployment and deleting a Build are separate irreversible operations. Confirm the target before using comfy deploy delete --yes or comfy build delete --id bld_123456 --yes.

FAQ

What does a Comfy API deployment provide?

A Comfy API deployment is a managed, autoscaling endpoint for running API-format workflows. Submit a workflow with comfy deploy run or the Comfy SDKs.

Can one Build come from multiple workflows?

Yes. In the Builder, upload one or more workflows to preselect their models and custom nodes. Include the dependencies needed by all the workflows you plan to run, then submit each API-format workflow to the deployed endpoint.Each deployment uses one GPU type. To run workflows on different GPU types, create separate deployments of the same Build.

Am I charged for storing Builds that are not deployed?

No. Builds and their releases are stored on your account at no charge. You are not billed for the storage footprint of a Build until you deploy it.Storage billing starts with a deployment:

When you deploy a release, its models are staged onto network storage shared by the deployment’s workers. The storage is read-only after deployment and billed per GB-month for as long as any deployment of the Build exists in that region, including while a deployment is paused with comfy deploy stop.
Each worker also gets a fixed 50 GB container disk. It is ephemeral and is only billed while the worker is running, as part of the worker’s compute cost.
Deleting a deployment releases its compute. Staged network storage is cleaned up shortly after the last deployment using it in that region is deleted, and billing for it ends.

For current storage rates, see the Comfy pricing page. The compute catalog (comfy deploy refs compute) and the deploy dialog also show the rates that apply to a deployment.

How are active workers billed, and at what hourly rates?

--min sets the number of active workers: workers that stay running at all times so requests never wait for a cold start. An active worker is billed per second for the entire time it is running, whether or not it is processing jobs.Workers above --min, up to --max, are flex workers. A flex worker is billed per second from the moment it starts (including startup and model loading), through job processing, plus a short idle window (currently 30 seconds) before it scales back down. When flex workers are scaled down, they cost nothing. With --min 0 the whole deployment scales to zero and bills no compute while idle, at the cost of a cold start on the first request.Billing meters actual per-second worker usage, multiplied by the number of workers running. If your workspace runs out of credits, deployments are stopped automatically.For current per-worker GPU rates, see the Comfy pricing page. Rates are quoted per worker-hour and billed per second. GPU availability per region comes from the compute catalog: run comfy deploy refs compute for the current list.

How does a deployment handle multiple requests?

A deployment automatically distributes requests across its workers and scales within the configured --min and --max bounds. Requests that cannot run immediately are queued and processed as worker capacity becomes available.

What should I do if provisioning takes a long time?

Follow the deployment state, then inspect its logs and events for the cause:

comfy deploy status --deployment <deployment-id> --watch
comfy deploy logs --deployment <deployment-id>
comfy deploy events --deployment <deployment-id>

If the selected GPU or region has no capacity, retry later or run comfy deploy refs compute and choose an available region and GPU pair. Include the Build, release, and deployment IDs when asking for help.

What happens when I delete a deployment?

Deleting a deployment removes its endpoint and releases its compute. It does not delete the Build or its releases. After you delete the last deployment using that Build in a region, its staged network storage is cleaned up and storage billing ends shortly afterward.Deleting the Build is a separate operation: comfy build delete --id <build-id> --yes.

Develop with Comfy

Deploy ComfyUI

Run Workflows

Comfy Router

Comfy CLI

Specifications

Comfy API deployments

1. Build

2. Release

3. Deploy

4. Run

Quick start

The Build file

1. Initialize a Build

2. Update and release

Regions and GPU availability

3. Deploy a release

4. Run a workflow

Operate a deployment

Inspect and clean up

FAQ

Next steps

1. Build

2. Release

3. Deploy

4. Run

​Quick start

​The Build file

​1. Initialize a Build

​2. Update and release

​Regions and GPU availability

​3. Deploy a release

​4. Run a workflow

​Operate a deployment

​Inspect and clean up

​FAQ

​Next steps

Quick start

The Build file

1. Initialize a Build

2. Update and release

Regions and GPU availability

3. Deploy a release

4. Run a workflow

Operate a deployment

Inspect and clean up

FAQ

Next steps