☁️Running Sogni Fast Worker Remotely

A Fast Worker can run on a hosted GPU platform that supports NVIDIA GPU containers, environment variables, persistent volumes, and enough memory and storage for the selected workloads. Maintained Sogni recipes on platforms such as Nosana and Salad are the simplest path when available.

After deployment, use dashboard.sogni.ai/fast-workers to verify the worker, enable downtime alerts, review health and jobs, and configure supported Comfy Worker settings.

The account owner remains responsible for the hosting account, credentials, deployment settings, costs, regional eligibility, provider terms, and safe operation of rented or owned hardware. Confirm the provider's power, cooling, persistence, and hardware-monitoring responsibilities before deploying. Sogni's software controls are best-effort aids; see Protecting your hardware.

#Use a maintained provider recipe

When the provider offers a current Sogni Fast Worker recipe:

Create or sign in to one Sogni account.
Prepare one unique Fast Worker NFT token ID for each GPU worker. Workers owned by the same account can share that account's API key, but must not share an NFT token ID while running.
Select the current Sogni recipe and choose the desired worker type.
Enter the Sogni API key and NFT token ID as secrets or environment variables.
Choose one replica. A provider that copies the same environment into several replicas would make them compete for the same worker identity.
Select a supported NVIDIA GPU and enough persistent storage and system memory for that worker's eligible workflows.
Deploy, then confirm the NFT is online in the Workers dashboard.

Provider screens and machine types change independently of Sogni. Follow the provider's current recipe defaults unless the Sogni dashboard or current documentation identifies a required change.

#Deploy a custom container

Use a custom deployment only when the platform gives the container direct NVIDIA GPU access and lets you configure secrets, persistent volumes, and health probes.

#Select the image

For Comfy Worker:

Use sogni/comfy-worker-cu13:latest only for compatible GeForce RTX 4090-series or Blackwell GPUs on NVIDIA driver branch R580 or later.
Use sogni/comfy-worker:latest for other supported GPUs or older compatible drivers.

The installer chooses between these runtimes automatically. A custom deployment must make that choice itself. The CUDA version printed by nvidia-smi describes the newest runtime supported by the driver; confirm the actual driver branch as well as the GPU model.

For LLM Worker:

Use sogni/sogni-llm-worker:latest.
Use a 24 GB-class NVIDIA GPU with at least 23 GB of usable VRAM. Assign exactly one GPU to the container; standard multi-GPU LLM configurations and model sharding are not supported.
Give every LLM Worker container its own Fast Worker NFT token ID and persistent /data directory, just as you would for a Comfy Worker.

The LLM Worker receives its compatible model catalog and inference settings from Sogni. Do not copy Comfy-only model or workflow environment variables into an LLM deployment.

Platforms that require immutable tags can query the production endpoints instead of hard-coding a version:

If the platform caches a :latest image, enable its equivalent of always pull or periodically replace the immutable tag with the value returned by the appropriate endpoint. The standard Sogni installer already pulls the selected :latest image whenever it starts the worker.

Do not deploy the former Flux Worker image. Flux Worker is retired and its current workflows are served by Comfy Worker.

#Configure identity and persistence

At minimum, supply these secrets or environment variables:

Variable	Purpose
`API_KEY`	API key for the Sogni account that owns the worker
`NFT_TOKEN_ID`	Unique Fast Worker NFT token ID for this GPU worker

Mount persistent storage for the paths used by the selected official image:

Worker	Container path	Contents
Comfy or LLM	`/data`	Worker identity, boot history, and other durable worker state
Comfy	`/data-models`	Downloaded Comfy models and related cache data
LLM	`/models`	Downloaded language models and related model data

Without a persistent /data mount, a replaced instance loses its stable local identity, boot history, and other worker data. A compatible Comfy Worker can recover the latest accepted dashboard overrides from a best-effort Supernet copy keyed to the Fast Worker NFT, but that recovery does not preserve the rest of /data. Without the applicable model mount, a replacement can download its eligible model files again. Do not assume that a provider's writable container layer survives replacement or rescheduling.

A Comfy Worker's model cache can occupy several hundred gigabytes and changes with the catalog. Use workflow selection and storage controls rather than relying on a dated fixed disk estimate. The LLM catalog also changes over time, so size /models for every currently eligible model plus download headroom. For either worker, leave room for partial downloads, Docker layers, logs, and provider filesystem overhead.

#Health endpoints

Configure provider probes against the worker's HTTP health server on port 8000. Use HTTP/1.x unless the provider requires a different label for ordinary HTTP.

Current Comfy Worker and LLM Worker images expose these endpoints:

Path	Intended use
`/startup`	Passes once startup has reached a valid connected, downloading, or backend-spawning state
`/liveness`	Fails when the backend has crashed or the worker is no longer viable
`/readiness`	Passes only when the worker is connected and ready to accept service
`/health`	Returns combined diagnostics; a degraded response can still use HTTP 200, so do not substitute it for readiness

Use these provider-probe defaults for Comfy and LLM Workers:

Probe	Path	Initial delay	Period	Timeout	Success threshold	Failure threshold
Startup	`/startup`	90 seconds	5 seconds	5 seconds	2	120
Liveness	`/liveness`	90 seconds	10 seconds	30 seconds	1	6
Readiness, when supported	`/readiness`	90 seconds	10 seconds	5 seconds	1	6

The startup settings allow roughly 10 minutes of failed checks after the initial 90-second delay. They are grounded in 1,939 distinct production Comfy Worker boot records sampled on August 23–24 and August 31, 2026 PT: median time from container start to accepting jobs was 22 seconds, p95 was 1 minute 32 seconds, and p99 was 6 minutes 14 seconds. /startup intentionally passes while a model download is progressing, so the entire model cache does not need to finish downloading inside that window. A worker still unable to reach a valid startup state after the failure budget is more likely stuck than merely slow.

The Stable Diffusion Worker exposes only /startup and /liveness. For the Salad deployment fields shown in its container-group editor, restore these established defaults:

Probe	Protocol	Path	Port	Initial delay	Period	Timeout	Success threshold	Failure threshold
Startup	HTTP/1.X	`/startup`	8000	90 seconds	5 seconds	5 seconds	2	120
Liveness	HTTP/1.X	`/liveness`	8000	90 seconds	10 seconds	30 seconds	1	6

Both Stable Diffusion endpoints require its Automatic1111 backend to be running and responsive and the worker to be connected to Sogni. Do not configure /readiness or /health for this image; those routes are not exposed.

If a provider does not support every probe type, configure startup and liveness first. These workers also have internal supervision, but provider-level probes improve replacement and visibility.

The LLM Worker also runs its local inference backend on port 8080. The Sogni supervisor reaches that port inside the deployment; it does not need to be exposed publicly for a normal worker.

#Configure optional behavior

Current Comfy Workers can receive supported overrides from the dashboard after their first successful connection. Restart-required values, initial deployment settings, and unsupported worker types still use the hosting environment. LLM model selection and inference-quality settings are server-managed; do not attempt to override them with Comfy settings.

See Advanced Configuration for:

Dashboard-versus-environment precedence and persistence.
Render-time rests and GPU thermal admission control.
Preferred workflows and default workflow selection.
Model-cache and automatic-download controls.
Stable Diffusion Worker settings.

#Verify the deployment

Do not treat a running container alone as proof that the worker is ready.

Confirm the worker is Online at dashboard.sogni.ai/fast-workers.
Check its reported worker version, GPU, loaded models, and current model.
Review Worker Health for startup stages and telemetry.
Review Failed Jobs & Errors and Job History after work arrives.
Enable account-wide downtime alerts at a delay appropriate for the hosting platform's normal rescheduling behavior.

For help, email [email protected] or join the Sogni Discord.