🧠Sogni Fast Worker Advanced Configuration

#Setting Your .env File Preferences

These configuration options are available for Sogni Fast Worker and can be set in the .env file. After making manual changes, restart the worker to apply them either through the .bat / .sh files or by running docker compose down and then docker compose up from the command line.

AUTO_DOWNLOAD_TO_MIN_MODEL_COUNT is available for the Stable Diffusion worker only. The installer sets it automatically, but you can also update it manually in the .env file.

#AUTO_DOWNLOAD_TO_MIN_MODEL_COUNT=6

Supported by: Stable Diffusion Worker

The Stable Diffusion worker comes bundled with 1 model by default (Sogni Artist SD1.5) and all 15 supported Controlnets. You may set the number of models you want your worker to download right away when it starts. Set this to 0 to disable automatic runtime model downloads.

While the count of models you are hosting is less than AUTO_DOWNLOAD_TO_MIN_MODEL_COUNT the worker will automatically download new models one at a time until this count of models is met. Models are downloaded based on real-time model popularity on the network with some models being 2gb and others being 6.7gb.

After this count is met, if your model folder size is still less than MAX_MODEL_FOLDER_SIZE_GB and AUTO_DOWNLOAD_TO_MIN_MODEL_COUNT is greater than 0 the worker will continue to automatically download new models but only as they are requested by the network. Sogni Supernet will only request new model downloads when the job queue for a model exceeds the amount of workers available to support it.

Models are cached on your local machine the first time they are downloaded so you won't have to download them again, unless you delete the models folder. The models are downloaded to the local folder /data-models/Stable-diffusion in the same directory as where your docker-compose file is ran. This folder is loaded as a persistent Docker Volume where both run-time downloaded and existing model files are automatically picked up by Fast Worker.

If you need to download all the models ahead of time, for example to manually seed the model folder of multiple separate Fast Worker machines during setup you can reference this api endpoint for the list of all Stable Diffusion worker model download links to use with your own download shell script.

You could also set AUTO_DOWNLOAD_TO_MIN_MODEL_COUNT to a very high number like 999 and wait till it automatically downloads all the models for you to copy through your network.

#MAX_MODEL_FOLDER_SIZE_GB=300

Supported by: Stable Diffusion Worker and Comfy Worker

Sets the maximum size of the worker's model folder in GB. For Stable Diffusion Worker this includes checkpoints, ControlNets, and related model files. For Comfy Worker it includes workflow assets and user-selectable LoRAs stored under the Comfy models directory. Automatic downloads stop before this limit is exceeded; files already on disk remain available. On Comfy Worker, setting the value to 0 is equivalent to the broad DISABLE_AUTOMATIC_DOWNLOADS=1 policy.

#PREFERRED_MODEL_IDS=

Supported by: Stable Diffusion Worker

You can use this option instead of AUTO_DOWNLOAD_TO_MIN_MODEL_COUNT to tell the worker exactly which models you want it to host by Sogni Model ID. If your worker model folder already has tons of models and is switching models too frequently you can use this feature to only share certain models. You can also specify models which you have not downloaded yet and they will automatically be downloaded in the order they are present in this list. Any invalid models will be skipped. Your worker instance will automatically connect to the Sogni Supernet and start taking on jobs as soon as one complete model is downloaded, it does not have to wait for all models.

You can find the list of supported model IDs for Stable Diffusion worker here: https://socket.sogni.ai/api/v1/config/models/nvidia.

The retired Sogni Flux Worker also used PREFERRED_MODEL_IDS, but it has been replaced with the Sogni Comfy Worker. Use PREFERRED_WORKFLOW_IDS for Flux-family workflows on Comfy Worker.

For example if you wanted to host only the 8 SDXL Turbo models used by the Photobooth app you could configure that as:
PREFERRED_MODEL_IDS=coreml-sogniXLturbo_alpha1_ad,coreml-dreamshaperXL_v21TurboDPMSDE,coreml-juggernautXL_v9Rdphoto2Lightning,coreml-wildcardxXLLIGHTNING_wildcardxXL,coreml-realvisxlV40_v40LightningBakedvae,coreml-realDream_sdxlLightning1,coreml-fenrisxl_SDXLLightning,coreml-epicrealismXL_VXIAbeast4SLightning

Note: Sogni Comfy Worker uses PREFERRED_WORKFLOW_IDS instead. See below.

#PREFERRED_WORKFLOW_IDS=

Supported by: Comfy Worker

This feature works the same way as PREFERRED_MODEL_IDS except against supported Comfy Workflows instead of model IDs. Model IDs and Workflow IDs look the same but the latter may involve several models, or the same models between several workflows. The live list of workflows and dependencies is in this configuration file: https://api.sogni.ai/v1/worker/config/comfy

Control exactly which workflows your worker will support. If not set, your worker will automatically download models for and support all workflows that fit within your GPU's VRAM capacity. When to use this:

• You want to reduce total model storage requirements
• You want to prevent automatic downloads of all models on startup
• You want to minimize model switching which can be significant with large video files by focusing on specific popular workflows instead of all of them. For example you could put wan_v2.2-14b-fp8_i2v_lightx2v,wan_v2.2-14b-fp8_i2v to only download and support image-to-video workflow jobs. Note that almost every WAN workflow shares the same VAE and Text Encoder but loads approximately 28gb of different model files, even between text-to-video and image-to-video.

How it works:

• Provide a comma-separated list of workflow IDs you want to host
• Models that are not yet downloaded will be automatically downloaded at startup in the order specified
• Your worker will only receive jobs for the workflows you specify
• If a workflow is invalid or requires more VRAM than available, it will be skipped

If this value is not populated then the Comfy worker will automatically download all supported models compatible with the amount of GPU VRAM you have and disk space you have available. As of July 2026, the full Comfy Worker model cache is about 470 GB for RTX 5090 and higher-VRAM GPUs (32GB+ VRAM). For 24GB GPUs such as RTX 4090 or RTX 3090, the worker skips files above the 24GB-class VRAM limit and needs about 435 GB for the automatically supported Comfy model cache. Reserve additional disk space for Docker images, temporary downloads, logs, and the operating system.

Available workflow IDs for Comfy Worker

Current high-demand Comfy Worker workflow IDs include:

Image workflows

• krea2_turbo_fp8_scaled — Krea 2 Turbo text-to-image and image-to-image. Requires at least 16 GB of VRAM at standard resolutions. Krea 2 Turbo is the newest open-source Krea image model hosted on Sogni and is separate from FLUX.1 Krea Dev.
• krea2_identity_edit_v1_2 — Krea 2 identity-preserving image editing with one- and two-reference modes. Requires at least 16 GB of VRAM at standard resolutions.
• krea2_identity_edit_sogni_v0_3_alpha — Sogni's Krea 2 identity-edit workflow for reframing, restoration, and subject edits. Requires at least 16 GB of VRAM at standard resolutions.
• dark_beast_krea2_fp8 — Dark Beast Krea 2 text-to-image and image-to-image. Requires at least 16 GB of VRAM at standard resolutions.
• dark_beast_krea2_identity_edit_v1_2 — Dark Beast Krea 2 identity-preserving editing. Requires at least 16 GB of VRAM at standard resolutions.
• z_image_turbo_bf16 and z_image_bf16 — Z-Image Turbo and Z-Image.
• chroma-v.46-flash_fp8 and chroma-v48-detail-svd_fp8 — Chroma image workflows.
• qwen_image_edit_2511_fp8_lightning and qwen_image_edit_2511_fp8 — Qwen Image Edit 2511 editing workflows, with Lightning as the fast edit path.
• qwen_image_2512_fp8 and qwen_image_2512_fp8_lightning — Qwen Image 2512 generation.
• flux2_dev_fp8, flux1-krea-dev_fp8_scaled, and flux1-schnell-fp8 — Flux.2 Dev, FLUX.1 Krea Dev, and FLUX.1 Schnell workflows.

Video workflows

Note: There are multiple Wan 2.2 video workflows and they are all supported by GPUs that have at least 24gb of VRAM. However due to speed optimizations on the platform >=24gb of VRAM GPUs are restricted to the "Lightning" version of models and only <=40 GB of VRAM GPUs receive jobs that are 720p+ in resolution.

MiniMax H3 video

MiniMax H3 and H3 Turbo create video and synchronized stereo audio together. All seven current workflows require a supported NVIDIA GPU with at least 32 GB of VRAM. An RTX 5090 is the entry consumer-class example and uses Sogni's Blackwell-specific runtime tuning; other supported NVIDIA GPUs with 32 GB or more VRAM may also be eligible.

• minimax-h3-fl2va-fp8_t2v
• minimax-h3-fl2va-fp8_i2v
• minimax-h3-fl2va-fp8_flf2v
• minimax-h3-ref2va-fp8_r2v
• minimax-h3-fl2va-fp8_t2v_turbo
• minimax-h3-fl2va-fp8_i2v_turbo
• minimax-h3-fl2va-fp8_flf2v_turbo

Wan 2.2 Video:

• wan_v2.2-14b-fp8_i2v_lightx2v
• wan_v2.2-14b-fp8_i2v
• wan_v2.2-14b-fp8_t2v_lightx2v
• wan_v2.2-14b-fp8_t2v
• wan_v2.2-14b-fp8_s2v_lightx2v
• wan_v2.2-14b-fp8_s2v
• wan_v2.2-14b-fp8_animate-move_lightx2v
• wan_v2.2-14b-fp8_animate-replace_lightx2v

LTX 2.3 Video:

• ltx23-22b-fp8_t2v_distilled, ltx23-22b-fp8_i2v_distilled, ltx23-22b-fp8_a2v_distilled, and ltx23-22b-fp8_ia2v_distilled
• ltx23-22b-fp8_t2v_dev, ltx23-22b-fp8_i2v_dev, ltx23-22b-fp8_a2v_dev, and ltx23-22b-fp8_ia2v_dev
• ltx23-22b-fp8_v2v_distilled and ltx23-22b-fp8_v2v_dev for video-to-video control workflows

Audio and music workflows:

• ace_step_1.5_xl_sft and ace_step_1.5_xl_turbo — Ace-Step 1.5 XL, the latest Ace-Step 1.5 family. Requires at least 20 GB of VRAM. Higher-VRAM workers may receive longer music jobs.
• ace_step_1.5_sft and ace_step_1.5_turbo — non-XL Ace-Step 1.5 workflows remain supported on the standard 16 GB VRAM Fast Worker floor.

#DEFAULT_MODEL_ID=

Supported by: Stable Diffusion Worker

Tells the Stable Diffusion worker to select a specific model by default whenever it boots up. This will be the model that is loaded when it connects to the Supernet and starts waiting for jobs. If the value is invalid it will be ignored and the default model for the worker type will be used. You may specify a model that is not yet available but is listed in your PREFERRED_MODEL_IDS. For example in the Photobooth case we set: DEFAULT_MODEL_ID=coreml-sogniXLturbo_alpha1_ad

The retired Sogni Flux Worker also used DEFAULT_MODEL_ID, but it has been replaced with the Sogni Comfy Worker. Use DEFAULT_WORKFLOW_ID for Flux-family workflows on Comfy Worker.

#DEFAULT_WORKFLOW_ID=

Supported by: Comfy Worker

Same functionality as DEFAULT_MODEL_ID but unique to the workflows supported by Sogni Comfy Worker. For example, this keeps the Krea 2 Turbo image workflow hot-loaded and ready for work:

DEFAULT_WORKFLOW_ID=krea2_turbo_fp8_scaled

#DISABLE_AUTOMATIC_DOWNLOADS=1

Supported by: All Worker Types

Prevents the worker from downloading any models automatically, either on startup or when jobs are requested. On Comfy Worker this is the broad master switch: it also disables on-demand user LoRA downloads. The worker continues to serve complete workflows and LoRAs already present on disk, and reports its cached inventory and download policy to the Sogni Supernet so jobs requiring missing files are routed elsewhere.

When to use this:

• You have manually pre-seeded your models folder
• You want complete control over which models are present
• You're running in an environment where downloads should not occur

Important notes:

• With this setting enabled, the worker will only support workflows for which all required models are already present in your models folder.
• Comfy Worker accepts 1, true, or yes.
• MAX_MODEL_FOLDER_SIZE_GB=0 has the same no-download effect on Comfy Worker.

Comfy Worker download policy summary

The broad settings take precedence if more than one setting is present. After the worker registers, the Supernet uses the explicit policy and cached LoRA filenames reported by that individual worker. A local worker also refreshes its inventory when files are added to or removed from the shared model volume.

#DISABLE_LORA_DOWNLOADS=1

Supported by: Comfy Worker

Disables only on-demand downloads of user-selectable LoRAs. Automatic workflow model downloads remain enabled. The worker still resolves LoRA IDs and serves LoRA files already present in models/loras; the Sogni Supernet routes jobs requiring uncached LoRAs to another worker.

Use this when you are willing to download and host supported workflows but want explicit control over which optional LoRAs are stored on your machine. The value accepts 1, true, or yes.

As of August 2, 2026, the artist-facing LoRA catalog lists 20 user-selectable LoRAs. The full worker LoRA manifest contains 23 distinct downloadable LoRA files when worker-internal entries are included, with a combined download size of about 5.04 GB (4.69 GiB). These counts and sizes are a dated snapshot; check the live endpoints because the catalog can change.

LoRAs that are fixed dependencies of a workflow—such as acceleration or control LoRAs embedded in its graph—remain workflow model files. Use DISABLE_AUTOMATIC_DOWNLOADS=1 if those files must not be downloaded either.

On a multi-GPU host, put the chosen download setting in every generated .envX file. The worker instances share one model volume; if even one instance still allows runtime LoRA downloads, that instance can add LoRAs to the shared disk.

If you manually add a LoRA while the worker is running, copy it with a temporary extension such as .part, then rename it to .safetensors only after the copy finishes. The worker detects the final rename and reports the completed file without briefly advertising a partial copy.

#DISABLE_SPICY_MODELS=1

Supported by: Comfy Worker

Some Comfy Worker models are "spicy" — uncensored or mature-content models such as LTX‑2.3 10Eros and the Dark Beast image models (Dark Beast Krea 2 and Dark Beast Z‑Image). Hosting these is opt-in by default: your Comfy Worker hosts them like any other supported workflow, provided your GPU meets their VRAM requirement.

If you would prefer that your machine not host or serve mature/uncensored content, set DISABLE_SPICY_MODELS=1 in your .env file and restart the worker (the value also accepts true/yes). When it is enabled:

• The worker will not download any model pack flagged as spicy.
• The worker will not advertise, and therefore will not receive, jobs for any workflow that depends on a spicy model pack — even if those model files are already present in your models folder from a previous run or a manual/pre-seeded download. Opting out excludes the workflow at the host level: it is removed from the list your worker reports to the Sogni Supernet regardless of whether the files are on disk, and regardless of your GPU's VRAM.

Plain opt-out keeps any spicy model files already on disk (so re-enabling later is instant).

Reclaiming disk space — DISABLE_SPICY_MODELS=purge

To also delete spicy model files you previously downloaded, set DISABLE_SPICY_MODELS=purge instead of 1. This does everything the plain opt-out does and, on startup, removes spicy model files from your models volume to free space. Only files used exclusively by spicy models are deleted — shared dependencies that non-spicy (SFW) models also use are always preserved (for example, an LTX text encoder or VAE shared with the standard LTX‑2.3 workflows is kept). Cleanup runs only on a local primary worker that owns the models volume; switching back to unset/0/1 re-downloads the files as needed.

Leave this option unset (or 0) to keep hosting spicy models, which is the default behavior. Which packs count as spicy is defined by Sogni in the live worker configuration file (https://api.sogni.ai/v1/worker/config/comfy) via a spicy flag on each download group, so the set can change over time without a worker update.

Note: This is a host-side choice about which categories of models your machine is willing to host at all. It is separate from the per-job Sensitive Content Filter that requesting artists control.

#DATA_DOG_API_KEY=

Supported by: All Worker Types

Input the DATA_DOG API key assigned to you if participating in Sogni Supernet debug logs.

#COOLDOWN_EVERY_X_JOBS_COUNT=100

Supported by: All Worker Types

Configure your worker to take periodic "cool down" breaks after every N successful jobs. By default, workers cool down after every 100 jobs. Set to any positive integer to change the interval.

Important: A value of 0 uses the default of 100 jobs. We provide a general default, but it is your responsibility to ensure your cooldown values are appropriate for your machine's thermal characteristics.

Note: Video generation workflows are computationally intensive and can generate significant heat. Some popular workflows could keep machines active 24/7 during periods of heavy network job requests, so proper cooling configuration intervals (and proper physical cooling hardware) are essential for hardware longevity.

#COOLDOWN_EVERY_X_JOBS_SEC=30

Supported by: All Worker Types

During a worker "cool down" period, this value determines how many seconds the worker should wait before accepting new jobs. The default is 30 seconds.How cooldowns work:

• The worker remains connected to the Supernet during cooldown
• No new jobs are accepted during the cooldown period
• There is no penalty to job priority after exiting cooldown
• However, if your cooldown settings are inadequate and your machine thermally throttles due to insufficient cooling, this can impact your job assignment rate

Important: Set realistic cooldown settings for your specific hardware and cooling setup. Video generation workloads are significantly more intensive than image generation.

#Setting Up Your docker-compose.yaml File Preferences

• restart: unless-stopped: Remove or comment this line with # if you don't want the worker to start automatically when your computer starts. There are additional options outlined within the docker-compose.yaml file.
• pull_policy: always: This setting ensures Docker Hub checks for the latest version of the worker each time it runs. Comment it out if you want to stay on the current version (not recommended).
• ./data:/data: This maps where Sogni Fast Worker persists configuration. Comment it out if you want all settings to reset with each launch.
• ./data-models:/data-models: This maps where downloaded models are stored between reboots. Comment it out if you don't want to persist models across reboots. You can also manually place models here or map this folder to another location, like an existing Automatic1111 install, to share models.

#Running Fast Worker on a machine with multiple GPUs

Running Fast Worker on multiple GPUs is fully supported but the install process is not quite as streamlined as our single GPU installs. Please reach out if you have any difficulty.

1. DOWNLOAD INSTALLER FOR YOUR OS
   The multi-GPU worker installer is bundled with the regular Windows and Linux Sogni Fast Worker installer. Just download and unzip the installer files into the folder you want to run the workers from.

2. RUN THE MULTI-GPU INSTALLER
   In the unzipped folder run ./worker-generator.bat for Windows or ./worker-generator.sh. for Linux. This will generate a separate .env configuration file for each GPU detected and then a single docker-compose-generated.yml file which maps these .env files to docker instances so you can run all worker instances at the same time through this single Docker Compose file.

3. CONFIGURE AUTHENTICATION FOR EACH GPU
   Open each .envX file in a text editor and add API_KEY and NFT_TOKEN_ID values. Note that for multi-GPU installs the .env file names have a zero-based index appended to the file name. For example if you are running 2 GPUs then the files will be named .env0 and .env1.
   
   Note that you will need a separate Fast Worker NFT for each worker. So each should have a separate NFT_TOKEN_ID. The API_KEY can be the same if the NFTs are under the same Sogni Account. See details on acquiring an API_KEY and NFT_TOKEN_ID in the FAQ.

4. CONFIGURE WORKER TYPE
   By default each worker runs the Comfy Worker image. If you would like to switch instances to Stable Diffusion Worker, update the image: sogni/comfy-worker:latest line in the generated docker-compose to image: sogni/sogni-stable-diffusion-worker:latest.

5. START ALL WORKER INSTANCES

   docker compose -f docker-compose-generated.yml up -d
   

6. STOP ALL WORKER INSTANCES

   docker compose -f docker-compose-generated.yml down
   

Once connected to the Sogni Supernet you can view live worker status and activity on the Fast Worker Dashboard:

You can additionally view the health status of all worker Docker instances locally via:

docker compose -f docker-compose-generated.yml ps
# or alternatively
docker compose ps

To tail the logs of a particular worker instance for troubleshooting grab the ID from docker compose psand run the following:

docker logs -f ID_OF_DOCKER_INSTANCE_FROM_DOCKER_PS
# or alternatively by a worker service name
docker compose -f docker-compose-generated.yml logs -f worker0

Note that you can also send job requests directly to your workers to troubleshoot them.

#Worker Analytics API Endpoints

Sogni provides several REST API endpoints for you to pull analytics and earnings data for your workers from. Many of these power the existing Sogni Dashboards like the Fast Worker Dashboard but you may also call them directly. These are public HTTP GET endpoints:

1. Account address lifetime analytics
   https://api.sogni.ai/v1/analytics/lifetime?address=${address}&keys=uloginWorker,jobAcceptedWorker,jobCompleteWorker,renderTokenCompleteWorker,renderUSDCompleteWorker,renderEarnPaidSparkWorker,renderEarnActualSogniWorker,jobErrorWorker,renderEarnSogniWorker
2. Account address UTC day analytics
   https://api.sogni.ai/v1/analytics/day/2025-11-10?address=0x91eD6f531d6de80c22C55D2c223BE919CfC3E08a

#Need help? Join our Discord!

If you have any issues or questions setting up your Sogni Fast Worker you can reach out on Discord or via email to [email protected] for technical support.

Join Sogni Discord ✨