Afterburner
Adaptive, per-second resourcing that boosts CI jobs with up to 25% more CPU and 50% more RAM at no extra cost
StarSling Runners run exclusively on high-performance sandboxes, not the fixed hardware shapes of GitHub and traditional CI providers. That architecture is what makes Afterburner possible.
Afterburner boosts performance during the intensive CI steps that put pressure on memory and compute. Your label sets the resources you pay for. When a step comes under CPU or memory pressure, Afterburner engages up to 25% more CPU cores and 50% more RAM, at no extra cost. When the pressure passes, the job returns to its label's resources. You get a higher-performance CI job without moving to a larger label.
Afterburner is in private beta. Contact founders@starsling.dev to request access.
Fixed Fleets Lock You Into Fixed Shapes
Typical CI providers run fixed fleets of identical machines, so every job runs on one of a few fixed shapes. That forces a bad trade-off:
- CPU-bound spikes cost you a bigger shape. If a workload is short on CPU cores for only part of the job, the only fix is a larger fixed shape. You then pay for those cores for the whole job, including the parts that never use them.
- Memory spikes fail jobs. If a job sometimes uses more memory than the machine's RAM and swap, the job fails. A job that passes most of the time and sometimes runs out of memory is a flaky job.
Adaptive, Not Overprovisioned
Afterburner is not overprovisioning. StarSling Runners resize resources live, every second, in response to the pressure each step puts on CPU and memory. Resources follow demand within the job, step by step, instead of staying fixed for the whole job.
- A compile step that saturates every core gets up to 25% more CPU cores while it runs.
- A test step with a memory spike gets up to 50% more RAM before it runs out of memory and swap.
The same label, at the same price, compared with GitHub-hosted ubuntu-latest:
| Runner | Afterburner | vCPU | Memory | Speedup vs. ubuntu-latest |
|---|---|---|---|---|
starsling-ubuntu-24.04 | Off | 4 | 16 GB | Up to 1.7x |
starsling-ubuntu-24.04 | Engaged | Up to 5 | Up to 24 GB | Up to 2.44x |
Built on dynamic routing
StarSling Runners run on sandbox providers in multiple regions instead of one fixed fleet. Afterburner is only possible because of StarSling's dynamic routing and its sandbox-oriented architecture. Each job runs in its own sandbox, not on a shared host with a fixed shape, so each job's resources can be resized on their own. This elasticity gets better value from the hardware, and Afterburner passes some of that value back to you.
Telemetry Picks the Jobs That Benefit
The same machine-level telemetry that StarSling's AI agents and dynamic routing use also records how much CPU and memory a job usually uses. That tells us which jobs are most likely to benefit from more resources, so Afterburner engages where it helps most.
FAQ
Do I have to change my workflows?
No. Once your organization has access, Afterburner needs no YAML change. Keep the runs-on label you already use:
runs-on: starsling-ubuntu-24.04Can Afterburner reduce my resources?
No. Afterburner carries zero risk: a job never gets fewer resources than the label you pay for. Afterburner only adds resources above that.
How often does Afterburner engage?
It depends on the job's typical resource use and on the resources available when the CI job starts. Use the sling CLI to see how often Afterburner engages for each job. The job logs also show when Afterburner was engaged.
Is this a replacement for right-sizing workloads?
No. If a workload is always short on resources, the StarSling AI agents send a PR that recommends the right label. Afterburner is for CI jobs where the runner label is right overall, but individual steps are short on resources.