Why We Built Runzivo: Faster CI. Less Waiting.

CI is where a development team discovers whether a change holds up. It is also where time disappears. A pull request waits for a runner. A test suite waits for capacity. A release waits for the queue to clear. Those delays are easy to accept one at a time, but they add up across a week of small changes and a team of people trying to keep work moving.

We kept seeing the same trade-off. Hosted runners remove infrastructure work, but teams have limited control over startup time and performance. Self-hosted runners offer more control, but teams must maintain fleets, images, access boundaries, and cleanup. Teams should not have to choose between fast feedback and a manageable operating model.

CI compute should fade into the background.

That is why we started Runzivo. CI compute should be ready when a job needs it, isolated while it runs, and gone when it finishes. The workflow should stay familiar. Runzivo should handle the infrastructure behind it.

This is a narrow problem on purpose. We are not introducing a new CI language or asking teams to rebuild working pipelines. We are starting where a workflow asks for a machine. A small change is easier to evaluate, undo, and fit into systems teams already use.

A distributed team, close to the work.

A four-person team across Canada, the United Kingdom, and the United States is building Runzivo Technologies Inc., a Canadian developer-infrastructure company. We have different areas of focus, but share one practical concern: software delivery should not slow down because supporting compute is difficult to operate.

• Ditah Kumbong is Technical Lead, based in Ottawa, Canada, and focused on the platform foundations behind Runzivo.
• Nelson Chi is DevOps Lead, based in Wolverhampton, United Kingdom, and focused on the operational path from design to dependable service.
• Dylan Zotegouon is Software Engineering Lead, based in Ottawa, Canada, and focused on the product and software systems that customers use.
• Marvellous Chuyuoh leads Product from Dallas, Texas, USA, and is focused on making the first experience clear and useful for development teams.

We name the team to show who is accountable for the work. Product, platform, operations, and developer experience shape Runzivo together from the start.

What we are building first.

V1 is managed Linux x64 compute for GitHub Actions. Each approved job receives an isolated, ephemeral environment. When the job finishes, that environment is destroyed. Teams install the Runzivo GitHub App, choose the repositories they want to use, and change the runs-on label in a workflow. Their existing steps stay in place.

The first version is deliberately specific. It does not promise every operating system, architecture, or CI provider. It focuses on one integration and one runner target. That gives us a clear operating model to test with real jobs. We will measure performance before making speed claims. For V1, the goal is simple: less waiting around a CI workflow.

The principles behind the service.

Runzivo begins with a few principles. One job gets one isolated environment. Compute is ephemeral and is not reused across customers. GitHub integration stays simple. Customers should not have a runner fleet to patch, scale, or clean up. These are V1 design commitments. Early users will help us test them in practice.

A clear environment lifecycle helps us reason about security and performance. It is easier to inspect than a shared environment used across jobs. A small product surface also makes the limits easier to understand. We are keeping V1 narrow so users know what it does, where its boundaries are, and how to report gaps.

Why now.

Teams are shipping more changes and automating more of the work around them. Generated code, larger test suites, and additional pull-request checks all put pressure on CI. The bottleneck is often not the person writing the change. It is the wait between submitting it for validation and receiving a useful answer.

We do not think every team needs a new delivery platform to address that pressure. Many teams already have workflows they trust. They need a better place for selected jobs to run. That is the practical opening for Runzivo: keep the workflow familiar and make the compute layer easier to use and operate.

What comes after V1.

GitLab, macOS, additional regions, and observability are roadmap directions, not V1 features. We will consider them after early users test the GitHub Actions and Linux x64 experience. A roadmap item is not an available feature.

Our immediate job is more modest. Build the first service carefully. Listen to the teams trying it. Publish clear limits. Improve the parts that hold up in real use. Keep the rest on the roadmap until it earns its place in the product.

Build with us.

We are working with early users now. If your team spends too much time waiting on GitHub Actions, we would like to hear about the workflows that create the most friction. Request Early Access, and tell us what you are trying to run.

Runzivo is early, focused, and open to feedback from the people using it. Start with one workflow. Then help us make the wait smaller.