🧠Sogni Fast Worker Advanced Configuration

#Start in the Workers dashboard

For a current Sogni Comfy Worker, the simplest place to configure and monitor the worker is dashboard.sogni.ai/fast-workers.

1. Sign in to the Sogni account that owns the worker.
2. Select Workers, choose the Fast network, and select the worker.
3. Open the Settings tab.
4. Review the source shown for each value, make the change, and select Save.

The worker supplies its complete remote operator-settings catalog, allowed values, and validation rules to the dashboard. Every setting in that catalog is the same operator-tunable environment variable used by .env, presented as a validated dashboard control. Settings that support live updates take effect without interrupting the active render. The dashboard marks settings that take effect after the worker restarts.

On Windows and Linux, the catalog covers hardware protection, workflow selection and priority, optional models for mature themes, model and user-LoRA downloads, disk limits, warmup, and out-of-memory recovery. Compatible macOS workers add power, idle, thermal-throttling, and free-memory controls. Credentials, worker identity, provider secrets, and centrally managed Supernet behavior remain outside the remote catalog.

Remote settings require an online worker with dashboard configuration support. This first appeared in Sogni Comfy Worker 1.0.189; use the latest supported release for the current settings catalog and live-apply behavior described here. If Settings says that an upgrade is required, use the update action or the normal installer update process. Stable Diffusion Worker and LLM Worker settings still use their environment configuration.

For a complete tour of status, alerts, health telemetry, job history, earnings, and model analytics, see Using the Workers dashboard.

#Dashboard settings and .env precedence

A dashboard change is stored locally by that worker as <WORKER_DATA_DIR>/settings-overrides.json. The effective order is:

1. Dashboard override
2. .env or deployment environment variable
3. Built-in default

Select Clear override in the dashboard to return to the .env value or built-in default. A persistent worker data directory keeps the local copy through normal restarts and container replacement.

For a compatible worker, the Supernet also keeps a best-effort copy of accepted dashboard overrides under the Fast Worker NFT token ID. If that NFT reconnects on a fresh machine with no local override for a key, the Supernet restores the missing value; an existing local override remains authoritative. Clearing the final override clears the recovery copy after the worker reports the change. This recovery path does not preserve model files, local logs, boot history, or other worker data, and it does not replace persistent volumes or operator backups.

Because the recovery copy is keyed to the NFT, review and clear dashboard overrides before transferring an NFT if those machine-specific values should not follow it.

Credentials and worker identity are deliberately excluded from remote settings. Continue to manage API_KEY, NFT_TOKEN_ID, and provider secrets through the installer or hosting platform.

#Editing .env directly

Use .env when a setting is not offered by your worker, when preparing a deployment before its first connection, or when configuration must remain entirely under local deployment management.

After editing .env, restart through the scripts in the installation folder:

Windows: worker-stop.bat, then worker-start.bat
Linux:   ./worker-stop.sh, then ./worker-start.sh

You can also run docker compose down followed by docker compose up -d from the same installation directory. Do not mix an installer-managed deployment with an unrelated docker run command.

#Protecting your hardware

Current Comfy Workers provide two complementary load-management features by default: render-time rests and a GPU thermal guard. They reduce sustained load in different ways; neither feature interrupts a render already in progress.

#Render-time rests

Current Comfy Workers report actual rendering time to the Supernet. After the configured amount of accumulated render time, the scheduler waits for the configured rest duration before offering the next job.

• Only actual rendering counts. Waiting for work does not accumulate render time.
• An idle gap at least as long as the configured rest already satisfies the rest.
• Only sustained back-to-back rendering normally triggers a forced rest.
• The active render finishes. The rest affects admission of the next job.
• The worker remains connected during the rest.

The defaults provide a rest of 1 minute after 30 minutes of continuous rendering, about a 96.8% duty cycle while continuously busy. Shorten the render interval or lengthen the rest if independent monitoring shows that your system needs more recovery time.

Older media workers use the legacy COOLDOWN_EVERY_X_JOBS_COUNT and COOLDOWN_EVERY_X_JOBS_SEC fields. A current Comfy Worker reports render-time settings, so the scheduler uses render-time pacing and ignores the legacy pair. Do not rely on the legacy fields to replace render-time pacing on a current Comfy Worker.

#GPU thermal guard

The GPU thermal guard is available on current Sogni Comfy Workers when the worker can read a local CUDA GPU. It is enabled by default. It is not currently a Stable Diffusion Worker or LLM Worker feature.

The guard samples GPU core temperature every 20 seconds. At or above the hold temperature, the worker finishes any admitted render and stops accepting new jobs. It resumes after the GPU reaches the lower resume temperature and the hold has lasted at least 60 seconds. Hysteresis and the minimum hold reduce rapid queue changes near the threshold.

The active render is not canceled. In-render clock and temperature behavior remains under the GPU, firmware, driver, and operating system. If the worker cannot obtain a valid temperature reading, this software guard does not pause the worker. That fail-open behavior is one reason independent monitoring and adequate physical cooling remain necessary.

The dashboard's Worker Health tab shows the rolling temperature, VRAM, utilization, and power window. When the guard is enabled, the temperature chart also shows its hold threshold. The Settings tab reports whether the guard is armed or currently holding new work.

Disabling the guard is not recommended. A lower threshold can provide more margin, but the correct limit depends on the complete system and its manufacturer's specifications.

#Comfy Worker workload and storage

The current workflow catalog and its dependencies are published at api.sogni.ai/v1/worker/config/comfy. Use that live catalog instead of copying a dated workflow list from documentation.

#PREFERRED_WORKFLOW_IDS

In the dashboard, select the workflows this worker should serve; selecting none means serve all normal eligible workflows. In .env, provide the same selection as a comma-separated list of workflow IDs. The worker validates dashboard choices against the workflows currently available to that machine.

The same picker also shows optional workflow families that the production catalog declares eligible for this worker. Selecting one opts the worker into that family and permits its model pack to download. Clearing the selection returns to all normal eligible workflows without adding optional families. There is no separate optional-workflow setting.

Use this to reduce storage, focus on selected workload types, or reduce model switching. A workflow can depend on multiple model files, and several workflows can share the same files.

#EXCLUDED_LORA_IDS

Use Excluded LoRAs in the dashboard, or a comma-separated list of exact catalog LoRA IDs in .env, to block individual installed LoRAs on this worker. The setting applies live.

An excluded ID is omitted from the positive loaded-LoRA inventory and is sent to Sogni separately as a negative routing fence, so a matching job is not assigned back to this worker while cleanup is pending. The worker also refuses to download or use that LoRA. At the next idle point it deletes a cached file used exclusively by that catalog LoRA. A file shared with another catalog LoRA, a workflow, or a built-in acceleration/detailer path is retained.

The dashboard offers installed catalog LoRAs rather than accepting arbitrary IDs. A restored worker-settings backup can retain a previously excluded ID after its file has already been removed.

#DEFAULT_WORKFLOW_ID

Sets the workflow prioritized for model downloads and hot loading at startup. A dashboard change updates download priority immediately but does not force a model switch in the current session; the startup hot-load choice applies on the next start. If the selection is unavailable or invalid, the worker chooses an available fallback.

#Download controls

The full Comfy cache changes whenever workflows are added or retired and can consume several hundred gigabytes. Reserve additional space for Docker images, temporary downloads, logs, and the operating system. The worker verifies existing files at startup and downloads only what is missing for its eligible workflows.

#Optional models for mature themes

DISABLE_SPICY_MODELS controls optional model packs intended for private mature-theme creativity:

• 0 or unset: host eligible packs.
• 1: do not download or advertise workflows that depend on those packs. Existing files remain on disk.
• purge: apply the opt-out and delete files used exclusively by opted-out packs. Shared dependencies are retained.

This host-level policy is separate from artist-selected per-job content filtering. The live worker configuration identifies the affected packs, so the set can change without a worker release.

#Startup and recovery

Current Comfy Workers expose these additional operator settings. Only the three warmup settings wait for the next start; retry-after-OOM applies live.

The dashboard labels a saved warmup change as waiting for the next start. A pending value is already persisted even though the running worker continues using its boot value.

#Stable Diffusion Worker settings

Stable Diffusion Worker does not currently expose remote dashboard configuration. Set these values in .env and restart the worker.

#AUTO_DOWNLOAD_TO_MIN_MODEL_COUNT

The worker downloads models until it reaches this count, subject to the model-folder limit. The built-in default is 5, and the installer writes its selected value into the environment. Set 0 to disable this startup minimum.

#PREFERRED_MODEL_IDS

Provide a comma-separated list of exact model IDs to restrict the worker to those models. Valid missing models are downloaded in list order. The worker can connect after the first complete preferred model is ready and continue preparing the remainder in the background.

The live Stable Diffusion model list is socket.sogni.ai/api/v1/config/models/nvidia.

#DEFAULT_MODEL_ID

Selects the model loaded by default at startup. If it is invalid or unavailable, the worker selects an available fallback. A preferred model may be selected before its download finishes.

#Stable Diffusion download controls

MAX_MODEL_FOLDER_SIZE_GB must be positive for downloads. The official deployment environment normally supplies it; 0 or an omitted value at the worker process disables downloads. DISABLE_AUTOMATIC_DOWNLOADS=1 blocks model downloads requested later by the Supernet, but it does not override an explicit preferred-model or startup-minimum download plan. To prohibit all Stable Diffusion model downloads, also set AUTO_DOWNLOAD_TO_MIN_MODEL_COUNT=0, leave PREFERRED_MODEL_IDS unset, and set MAX_MODEL_FOLDER_SIZE_GB=0.

#Docker Compose persistence and updates

The installer-generated Compose file normally includes:

• restart: unless-stopped to start the worker again with Docker.
• pull_policy: always to check the configured image tag when the worker starts.
• ./data:/data to persist identity, boot history, and dashboard overrides.
• ./data-models:/data-models to persist downloaded models.

Removing a volume mapping makes the corresponding data ephemeral. Do not remove persistence unless losing that data on container replacement is intentional.

Use the installer's managed image choice. On x86-64, current installers select sogni/comfy-worker-cu13:latest only when every detected NVIDIA GPU reports an R580-or-newer driver and CUDA compute capability 8.0 or newer. Product names and memory suffixes do not affect the choice; an older driver, or an older, unreadable, or malformed capability inventory, keeps the standard sogni/comfy-worker:latest image.

On Linux ARM64, the installer selects sogni/comfy-worker-spark:latest only for an NVIDIA DGX Spark: a GB10 GPU with compute capability 12.1 and an R580-or-newer driver. Any other ARM64 host fails closed with no image selected rather than falling back to an x86-64 image it cannot run. See the Comfy Worker (DGX Spark) release notes for that family's requirements and supported workflows.

Version-pinned deployments can query the current official image from:

• Standard Comfy Worker image
• CUDA 13 Comfy Worker image
• DGX Spark Comfy Worker image
• Stable Diffusion Worker image

The Flux Worker is retired. Do not deploy or reactivate it; use Comfy Worker for current Flux-family workflows.

#Multiple GPUs on one host

The multi-GPU generator creates one worker service and one .envN file per GPU while sharing the model cache. Each GPU worker needs its own Fast Worker NFT token ID. Workers owned by the same Sogni account can use the same account API key.

1. Run worker-generator.bat on Windows or ./worker-generator.sh on Linux.
2. Add the correct API_KEY and unique NFT_TOKEN_ID to every generated .envN file.
3. Start all services with docker compose -f docker-compose-generated.yml up -d.
4. Check them with docker compose -f docker-compose-generated.yml ps and dashboard.sogni.ai/fast-workers.
5. Stop them with docker compose -f docker-compose-generated.yml down.

GPU memory is not the only capacity requirement. Size host RAM, storage bandwidth, power delivery, cooling, and Internet connectivity for all concurrently active workers. Do not assume that a configuration safe for one GPU remains safe when several GPUs share one chassis.