Source: https://docs.sogni.ai/run-a-worker/fast-worker/running-sogni-fast-worker-remotely/

# ☁️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](https://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](https://docs.sogni.ai/run-a-worker/fast-worker/sogni-fast-worker-advanced-configuration/#protecting-your-hardware).

## [#](https://docs.sogni.ai/run-a-worker/fast-worker/running-sogni-fast-worker-remotely/#use-a-maintained-provider-recipe)Use a maintained provider recipe

When the provider offers a current **Sogni Fast Worker** recipe:

1.  Create or sign in to one [Sogni account](https://app.sogni.ai/).
2.  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.
3.  Select the current Sogni recipe and choose the desired worker type.
4.  Enter the Sogni API key and NFT token ID as secrets or environment variables.
5.  Choose one replica. A provider that copies the same environment into several replicas would make them compete for the same worker identity.
6.  Select a supported NVIDIA GPU and enough persistent storage and system memory for that worker's eligible workflows.
7.  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.

## [#](https://docs.sogni.ai/run-a-worker/fast-worker/running-sogni-fast-worker-remotely/#deploy-a-custom-container)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.

### [#](https://docs.sogni.ai/run-a-worker/fast-worker/running-sogni-fast-worker-remotely/#select-the-image)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:

-   [Standard Comfy Worker image](https://api.sogni.ai/v1/worker-images/comfy)
-   [CUDA 13 Comfy Worker image](https://api.sogni.ai/v1/worker-images/comfy?cuda=13)
-   [LLM Worker image](https://api.sogni.ai/v1/worker-images/llm)
-   [Stable Diffusion Worker image](https://api.sogni.ai/v1/worker-images/stable-diffusion/full)

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.

### [#](https://docs.sogni.ai/run-a-worker/fast-worker/running-sogni-fast-worker-remotely/#configure-identity-and-persistence)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](https://docs.sogni.ai/run-a-worker/fast-worker/sogni-fast-worker-advanced-configuration/#comfy-worker-workload-and-storage) 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.

### [#](https://docs.sogni.ai/run-a-worker/fast-worker/running-sogni-fast-worker-remotely/#health-endpoints)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.

### [#](https://docs.sogni.ai/run-a-worker/fast-worker/running-sogni-fast-worker-remotely/#configure-optional-behavior)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](https://docs.sogni.ai/run-a-worker/fast-worker/sogni-fast-worker-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.

## [#](https://docs.sogni.ai/run-a-worker/fast-worker/running-sogni-fast-worker-remotely/#verify-the-deployment)Verify the deployment

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

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

For help, email [app@sogni.ai](mailto:app@sogni.ai) or join the [Sogni Discord](https://discord.com/invite/2JjzA2zrrc).