Dynamic Routing

StarSling runs its GitHub Actions runners and agentic compute on multiple high-performance sandbox providers. StarSling Runner labels automatically select the highest-performance environment for the workload you run. You pick a label for the size of the job. Dynamic routing selects the environment behind it.

Distributed & Resilient Compute

Most CI providers buy hardware and lock you into a specific hardware shape. StarSling does the opposite. Our agents distribute your CI jobs across high-performance sandbox providers in multiple regions and failover at the job level in under 1 second.

A regional power or cooling failure at a single-operator datacenter can take down every runner hosted there. StarSling routes around that failure: when a provider cannot start a sandbox, the job falls back to another provider. The result is higher resilience and availability than a CI platform that depends on a limited number of datacenters.

Failover is automatic. If a provider rejects a job or has an outage, the job goes to the next healthy provider.

Telemetry Drives Routing

The same granular telemetry StarSling's AI agents use to open optimization PRs also determines the fastest environment for each job. Routing keeps a preferred provider for each workflow, and provider weights for the organization. Both update from jobs that have already run, and both place the next job.

High-Performance Wall-Clock Time

The wall-clock time of a CI job is queue time plus the job's own execution time. Dynamic routing optimizes that total.

Queue time between phases

A workflow with several dependent jobs, chained with needs:, waits in queue again at every handoff.

jobs:
  install:
    runs-on: starsling-ubuntu-24.04
  test:
    needs: install
    runs-on: starsling-ubuntu-24.04
  package:
    needs: test
    runs-on: starsling-ubuntu-24.04

In a hypothetical three-job chain, each job runs for 60 seconds, and each needs: handoff waits 45 seconds in queue. Those two handoffs add 90 seconds of queue time to 3 minutes of execution, so a third of the wall clock is waiting between phases. For an organization whose workflows look like this, dynamic routing shifts that organization's provider weights toward a provider with a faster time-to-start.

Disk-bound jobs on the same CPU

Two sandbox providers can run the same bare-metal CPU and still finish a disk-bound CI job at different speeds. The job is limited by disk I/O — installing dependencies, writing a large build output, or running tests that create thousands of files — so it is not waiting on the CPU. Suppose the same job takes 3 minutes on one provider and 5 minutes on the other. Dynamic routing places it on the faster provider. For disk-bound workloads, StarSling Runners may also provision sandboxes with extreme disk performance, such as tmpfs (RAM-backed) workspaces.

Zero Configuration

StarSling believes agent-native CI should be automatic and feel like magic. Dynamic routing is zero-configuration. It is enabled by default on StarSling Runner labels, and it needs no YAML change. Keep the runs-on label you already use:

runs-on: starsling-ubuntu-24.04

Need exotic hardware for your CI?

If a workload needs hardware performance the existing StarSling Runner labels do not provide, contact founders@starsling.dev.

StarSling's dynamic routing architecture enables us to source specialized hardware. The industry-leading GPU Runners started exactly this way.

FAQ

Do I have to change my workflows?

No. Dynamic routing needs no configuration. The only change is the runs-on label that moves a job onto StarSling Runners. If your jobs already use a StarSling Runner label, there is nothing to change.

Can I pin a provider or region?

Yes. If a workload needs a specific provider or region, contact founders@starsling.dev.

What happens during a provider outage?

Jobs waiting to start go to a healthy provider first. A provider that rejects jobs or has no capacity is skipped, and a degraded provider is tried only after the healthy ones, as described in Distributed Compute. No workflow change is needed.