# Introducing the Fibonacci Benchmark™ (https://depot.dev/blog/the-fibonacci-benchmark)

> By Peter Hasko-Nagy (Staff Engineer at Depot)
> Published 2026-08-26

## The way sandboxes are measured today

As we approach 2027, the line between a sandbox and a CI runner is getting somewhat blurry. This is certainly the case for Depot CI, since the same orchestrator, build environment, and infrastructure layer ([Depot Metal](/blog/announcing-depot-metal)) is responsible for running both our sandboxes and our CI jobs. This is true for some other providers as well. Sandbox infrastructure has a relatively established way of being benchmarked. Probably the most well-known sandbox benchmarking suite was created by [ComputeSDK](https://www.computesdk.com/benchmarks/sandboxes/), which measures `Burst TTI` among other things.

When I saw the Burst TTI benchmark, I started to wonder whether I could come up with some other fun benchmark that makes sense in the context of CI runners. After some thinking, it came to me: I would calculate Fibonacci numbers by computing each step in a separate CI runner! Depot CI (and other providers) tend to ship a CLI that can be used to trigger other CI jobs, so we could start from there.

## What we're measuring with the Fibonacci benchmark

For this benchmark session, I compared Depot CI with GitHub, for obvious reasons.

Each provider is tested with 10 iterations per variation, and each measurement calculates the 20th Fibonacci number. The measurements are run on 2 vCPU VMs, using the `depot-ubuntu-24.04` and `ubuntu-24.04` labels respectively.

I came up with 2 variations for the benchmark: one invokes the Fibonacci calculations sequentially, the other concurrently (burst).
Sequential emulates constant pressure on the system, while burst measures the capability of starting many runners at the same time.

The code used for benchmarking, along with the workflows, is available in this [repository](https://github.com/depot/fibonacci-benchmark).

### Sequential

For both providers, the dispatched workflow performs its own calculation, then invokes the next calculation, providing its "output" as the next calculation's input. This particular benchmark measures cold start time rather than execution time; the calculation itself is super fast (around a second).

To be precise, it measures the elapsed time between the benchmark invocation and the finish time of the final workflow. For a depth of 20, a total of 18 workflows are dispatched (the first 2 Fibonacci numbers are known).

<ImageWithCaption src="/images/fibonacci-sequential.webp" alt="A CLI trigger starts a chain of runners, each computing the next Fibonacci number from the previous runner's output" className="not-prose mx-auto my-8 w-full" />

### Concurrent

This one is a little trickier. In this case, all 18 workflows are dispatched concurrently. The runs are identified by a unique ID, and each dispatched workflow is passed its predecessor's ID. Each workflow uploads the result of its calculation to the artifact store. Before they can calculate their Fibonacci numbers, the workflows first need to wait for their predecessor to upload its result, so that it can be downloaded and used for the actual calculation.

As before, the elapsed time between the benchmark invocation and the finish time of the final workflow is measured. This benchmark incorporates cold start time as well as artifact upload and download time.

<ImageWithCaption src="/images/fibonacci-concurrent.webp" alt="All runners are dispatched at once, each computing one Fibonacci number and uploading its result to a shared artifact store" className="not-prose mx-auto my-8 w-full" />

## Benchmark results

Each iteration of the benchmark calculates the 20th Fibonacci number across all 18 workflows and produces one elapsed time. The figures in the following tables are the mean, median, and range of 10 elapsed times per provider.

### Sequential execution

`POLL_TIME_MS` = 1000\
`DEPTH` = 20

|                      | Depot | GitHub |
| -------------------- | ----- | ------ |
| mean duration \[s]   | 123.8 | 142.2  |
| median duration \[s] | 123   | 128    |
| range \[s]           | 13    | 148    |

### Concurrent execution

`POLL_TIME_MS` = 1000\
`DEPTH` = 20

|                      | Depot | GitHub |
| -------------------- | ----- | ------ |
| mean duration \[s]   | 47.3  | 52.7   |
| median duration \[s] | 47.5  | 52     |
| range \[s]           | 9     | 17     |

## Aftermath

This isn't a super serious benchmark, and it's not intended to dunk on GitHub, especially because they put up decent numbers. As you can see, in the sequential measurement they had an outlier (which happened just before their August 17 outage), but overall their startup numbers are pretty consistent.

While this little experiment started out as fun, it actually shed light on some inefficiencies in our own system. We identified a few components that, depending on the workflow (repo size, dependencies, etc.), can make cold start times vary greatly. We also identified components that, simply put, we could speed up significantly. (Stay tuned for later blog posts.)

Triggering Depot CI workflows is pretty fast today, but we live and die by performance, so rest assured, we're working to improve CI runner startup times even further. And who knows, maybe we'll keep the Fibonacci Benchmark™ as part of our internal benchmark suite.

## FAQ

<FAQSection>
  <FAQItem question="What is the Fibonacci benchmark?">
    It calculates the 20th Fibonacci number by computing each step in a separate CI runner. For a depth of 20 that's 18
    dispatched workflows per iteration, since the first 2 Fibonacci numbers are known. The calculation itself takes about
    a second, so what the benchmark really measures is runner cold start time, plus artifact upload and download time in
    the concurrent variation.
  </FAQItem>

  <FAQItem question="Why benchmark both sequential and concurrent execution?">
    They stress the system in different ways. Sequential dispatches one runner at a time, so it emulates constant pressure
    and isolates cold start time on its own. Concurrent dispatches all 18 workflows at once, so it measures the capability
    of starting many runners simultaneously, and because each runner waits on its predecessor's result from the artifact
    store, it folds in artifact upload and download time too.
  </FAQItem>

  <FAQItem question="Which is faster, Depot CI or GitHub Actions?">
    On this benchmark, [Depot CI](/products/ci). Sequentially, Depot averaged 123.8s against GitHub's 142.2s, with
    medians of 123s and 128s. Concurrently, Depot averaged 47.3s against GitHub's 52.7s, with medians of 47.5s and 52s.
    GitHub had one sequential outlier just before their August 17 outage, which is what stretches their sequential range
    to 148s. This measures runner startup, not overall CI performance.
  </FAQItem>
</FAQSection>

## For AI Agents

The full site index is at [llms.txt](https://depot.dev/llms.txt). Append `.md` to any documentation, blog, changelog, or customer URL to fetch its markdown source directly.