Skip to main content
Schedulers manage task distribution to workers for remote execution.

Scheduler Definition

name
string
required
Unique identifier for the scheduler. Referenced in server execution services and worker configurations.
<type>
object
required
Scheduler type and configuration. Only one type can be specified.

Scheduler Types

Core scheduler for worker task distribution.
{
  name: "MAIN_SCHEDULER",
  simple: {
    supported_platform_properties: {
      cpu_count: "minimum",
      cpu_arch: "exact",
      OSFamily: "priority"
    },
    retain_completed_for_s: 60,
    worker_timeout_s: 5,
    max_job_retries: 3
  }
}
supported_platform_properties
object
Map of platform property names to match strategies. Keys must match worker-published capabilities.Property types:
  • "minimum" - Worker value must be >= task value (numeric)
  • "exact" - Worker value must exactly match task value (string)
  • "priority" - Informational, doesn’t restrict matching
  • "ignore" - Allows property in tasks without requiring worker support
supported_platform_properties: {
  cpu_count: "minimum",      // Worker needs >= cores
  memory_kb: "minimum",      // Worker needs >= memory
  cpu_arch: "exact",         // Must match exactly (e.g., "x86_64")
  gpu_model: "exact",        // Must match exactly
  OSFamily: "priority",      // Preference hint
  "container-image": "priority"
}
retain_completed_for_s
number
default:"60"
Seconds to keep completed action results in memory for WaitExecution calls.
client_action_timeout_s
number
default:"60"
Mark actions as failed if no client updates within this duration.
worker_timeout_s
number
default:"5"
Remove workers from pool after this many seconds without keepalive.
max_action_executing_timeout_s
number
default:"0"
Maximum time an action can execute without worker updates before timing out and re-queueing. Set to 0 to disable (rely only on worker_timeout_s).
max_job_retries
number
default:"3"
Maximum retries for jobs that fail with internal errors or timeouts.
allocation_strategy
enum
default:"least_recently_used"
Worker selection strategy when multiple workers can run a task.Options:
  • least_recently_used - Prefer idle workers
  • most_recently_used - Prefer active workers
worker_match_logging_interval_s
number
default:"10"
Log worker matching status every N seconds. Set to -1 to disable.
experimental_backend
object
Storage backend for scheduler state.

Platform Properties

Platform properties match tasks to workers. Workers advertise capabilities, and the scheduler filters based on property type:
Property TypeBehaviorExample Use Case
minimumWorker value >= task valueCPU cores, memory, disk
exactString exact matchArchitecture, OS, GPU model
prioritySoft preferenceContainer images
ignoreAccept task property without worker requirementOptional labels

Example Configuration

{
  name: "PRODUCTION_SCHEDULER",
  simple: {
    supported_platform_properties: {
      // Resource minimums
      cpu_count: "minimum",
      memory_kb: "minimum",
      disk_read_iops: "minimum",
      
      // Exact matches
      cpu_arch: "exact",        // "x86_64", "aarch64"
      cpu_vendor: "exact",      // "intel", "amd"
      OSFamily: "exact",        // "Linux", "Windows"
      
      // Preferences
      "container-image": "priority",
      
      // Optional
      "build-id": "ignore"
    },
    allocation_strategy: "least_recently_used",
    worker_timeout_s: 10,
    max_job_retries: 5
  }
}

Build docs developers (and LLMs) love