Skip to main content

Workflow Runners

Workflow runners control how your workflows are executed across different queue types. Use runners when you want to decide how much compute each queue receives and how far it can scale. This helps you keep test traffic, synchronous requests, schedules, and background executions isolated from each other.

note

When you create or update a runner, Boltic applies settings per queue. Existing runner configurations are also normalized so missing CPU, memory, minimum pod, or maximum pod values fall back to the platform defaults.

Queue Types​

Each runner includes configuration for these workflow queues:

QueueWhat it handles
ActivityPublished asynchronous workflow executions, such as event, webhook, and non-sync manual runs.
SyncSynchronous HTTP-triggered workflow executions that return a response in the same request.
TestDraft and test workflow executions, including validation and retry flows for test-mode runs.
ScheduleScheduled workflow executions triggered by published schedules.
Schedule internalInternal and polling-based scheduled executions, such as cloud polling triggers.

The queue order in the runner form is: Activity, Sync, Test, Schedule, and Schedule internal.

Configure a Runner​

From the runners page, select Create Runner to add a new runner, or open an existing runner and choose Edit to update it.

Each runner includes:

  • Runner name for identifying the configuration in the UI
  • vCPU per queue
  • Memory per queue
  • Min pods per queue
  • Max pods per queue

Default values​

Every queue starts with the same default configuration:

  • vCPU: 0.5 vCPU (500m)
  • Memory: 512MB (512Mi)
  • Min: 1
  • Max: 3

Available resource options​

The current runner form supports these resource selections:

  • vCPU: 0.25 vCPU, 0.5 vCPU, 1 vCPU
  • Memory: 512MB, 1GB, 1.5GB, 2GB

Use Min and Max to control how many pods stay ready for a queue and how far that queue can scale when load increases.

Manage Existing Runners​

The runners listing shows these columns:

  • Name
  • Status
  • Modified At
  • Modified By
  • Actions

From this page, you can:

  • Create a runner
  • Update an existing runner
  • Refresh the listing
  • Delete a runner

Deleting a runner requires you to confirm the action by typing the runner name.

Best Practices​

  • Start with the defaults unless you already know a queue needs different capacity.
  • Increase resources for Sync carefully, because those runs serve request-response workloads.
  • Keep Test capacity separate from published traffic so drafts and retries do not compete with live workload.
  • Raise Min only for queues that need warm capacity all the time.
  • Increase Max when a queue sees bursts, such as scheduled or asynchronous execution spikes.