Capability-Based Routing

In distributed environments, you may have multiple runners deployed across different servers, operating systems, or networking zones. Rescile uses Capability-Based Routing to ensure actions are only executed by runners that meet the necessary prerequisites.

Actions can define a constraints array in their .toml definition. These constraints are evaluated against the available runners in the system before a job is dispatched.

# actions/start_acme_gateway.toml
name = "start_acme_gateway"
run_mode = "service"

constraints = [
    "linux",                          # Static OS constraint
    "rescile-ce",                     # Static runner type constraint 
    "hostname:{{ input.target_server }}" # Dynamic constraint based on user input
]

[[input]]
name = "target_server"
type = "string"
required = true

Dynamic Constraints

Because capabilities can depend on user input at execution time, constraints fully support Tera templating. When the action is queued, the Controller renders templates like hostname:{{ input.target_server }} using the incoming JSON payload.

Runner Capabilities & Labels

When a runner connects to the Controller (in Agent mode), it automatically registers its base hardware capabilities:

• Operating System (linux, macos, windows)
• Architecture (x86_64, aarch64)
• Hostname (formatted as hostname:your-server-name)
• Runner Binary type (rescile-ce, system, nix, etc.)

Custom Labels: You can also assign custom tags to runners by starting them with the --agent-labels argument. For example, if you have a runner specifically deployed in a secure PCI zone, you can start it like this:

rescile-ce runner --mode agent --controller-url http://127.0.0.1:7600 --agent-labels="zone:pci,gpu-enabled"

Then, you can require these custom tags in your action definitions:

constraints = ["zone:pci", "gpu-enabled"]

The dispatcher will only route the action to a runner that satisfies all constraints listed in the action definition.