Skip to content
Orvanta Docs

Workers and worker groups

Workers are autonomous processes that execute jobs sequentially using available CPU and memory. They form the foundation of Orvanta’s architecture, pulling jobs from queues in order of their scheduled_for datetime.

Key capabilities

Section titled “Key capabilities”

Each worker can handle approximately 26 million jobs monthly (assuming ~100ms per job). By default, all workers are interchangeable, but worker groups enable specialized configurations for specific workloads.

Worker groups and tags

Section titled “Worker groups and tags”

Tags identify job queues that specific worker groups listen to. Jobs are routed to workers based on matching tags.

Default worker group tags

Section titled “Default worker group tags”
  • Language-specific: deno, python3, go, bash, powershell, bun, php, rust, ansible, csharp, java, nu, ruby
  • Special: dependency, flow, hub, duckdb, other

Native worker group tags

Section titled “Native worker group tags”

Dedicated to high-throughput native jobs with subworkers:

  • nativets (REST/GraphQL)
  • postgresql, mysql, mssql, graphql, snowflake, bigquery, oracledb

Enable via the NATIVE_MODE=true environment variable, which spawns 8 subworkers.

Configuration methods

Section titled “Configuration methods”

Community Edition: assign tags via the WORKER_TAGS environment variable.

Cloud / Enterprise: full UI-based management with:

  • Custom worker group creation
  • Init scripts (run at startup)
  • Periodic scripts (run at intervals ≥60 seconds)
  • Environment variables
  • Autoscaling
  • Python runtime settings

Assignment

Section titled “Assignment”

Assign custom groups to scripts and flows through:

  • Script editor settings
  • Flow module headers
  • Flow-level settings

Advanced features

Section titled “Advanced features”

Dynamic tags: use the $workspace substring for workspace-specific routing, or $args[argName] for argument-based routing.

Dedicated workers: single-script workers for high-throughput scenarios (Enterprise feature). See Dedicated workers.

Isolation: PID namespace isolation is enabled by default; optional NSJAIL sandboxing is available via DISABLE_NSJAIL=false.

Alerts: configure notifications when worker count falls below thresholds via Critical alert channels.

Compute units

Section titled “Compute units”

Pricing uses compute units (1 unit = 2 worker-GB-month). A standard 2GB worker = 1 compute unit; larger workers = 2+ units. Staging instances marked ‘Non-prod’ don’t count toward billing.

Section titled “Related”
  • Autoscaling — Adjust worker count automatically based on workload.
  • Agent workers — Remote workers that connect over HTTP.