Skip to main content
Serverless API is in beta. Sign up for access at platform.comfy.org.
Serverless API gives a ComfyUI workflow a managed URL and on-demand GPU capacity. The new Build and Deploy CLI keeps the build definition in your project, creates releases from that definition, and deploys a release when it is ready to serve traffic.

1. Build

Create a local build specification 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.
1

Initialize

2

Create a release

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

Start a deployment

If you do not already know where the selected GPU is available, check first:
Then create or reconcile the deployment:
deploy up prints the new deployment ID. If you need to retrieve it later, list this Build’s ready deployments:
Use the returned dep_... value with --deployment.
4

Run the workflow

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.
Before pushing, check how the local spec compares with the install and the remote Build:

2. Update and release

After changing the local ComfyUI install, refresh the local build definition:
For the quick path, push the definition and release it for a target in one command:
When you need to create another release from an existing Build, inspect the supported targets and cut one explicitly:
Follow one release’s build log with:

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:
Use --region <region> to filter the results:
Copy a returned region and gpu pair into comfy deploy up:
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:
--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:
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

Inspect and clean up

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.

Next steps