ZSoftly CI Runners · Early access

# Managed CI runners, for the platform you use.

ZSoftly CI Runners is being designed for teams using GitHub Actions and GitLab CI who want to stop operating runner infrastructure themselves. Join the early-access list for a focused pilot on Canadian ZCP capacity.

[Join the early-access list](https://forms.gle/pALYZy5WrvvXKSkeA)

[Book a Google Meet with ZSoftly](https://calendar.app.google/ceY8b2bxhCYgB1ot9)

We are looking for GitHub Actions and GitLab CI teams to shape the first paid pilots.

The service model

Make CI a service your developers use, not infrastructure they operate.

Keep GitHub Actions or GitLab CI

No CI-platform replacement project.

Change the job target

Use a GitHub runner label or GitLab runner tag for selected jobs.

Pilot with a clear boundary

Define runner capacity, security boundaries, and success measures first.

One targeted configuration change

## Keep your pipeline. Change where selected jobs run.

GitHub Actions uses `runs-on`. GitLab CI uses runner tags. The diffs below show the small workflow change for selected jobs. During onboarding, ZSoftly configures the exact target for your approved repositories and workloads.

### GitHub Actions

.github/workflows/ci.yml

`jobs:`

`test:`

-
`runs-on: ubuntu-latest`

+
`runs-on: zsoftly-linux-x64`

### GitLab CI

.gitlab-ci.yml

`test:`

+
`tags:`

+
`- zsoftly-linux-x64`

`script:`

`- npm test`

Why managed runners

## CI workloads need a different operating model.

Build and test jobs are short-lived, bursty, and sensitive to queue time, CPU, storage, and cache behaviour. A managed runner service puts those concerns behind one clear operating model while your team keeps the GitHub Actions or GitLab CI workflows it already knows.

### Keep your CI platform

Keep GitHub Actions or GitLab CI as your control plane. A runner label or tag directs selected jobs to the managed runner pool.

### Purpose-built CI capacity

Runner capacity is designed for short-lived build and test jobs, not long-lived virtual machines. Choose the runner sizes and concurrency your team needs.

### Canadian operating model

ZSoftly designs the runner placement, access boundaries, visibility, and support model around Canadian ZCP infrastructure.

Is this the right fit?

## Move CI work off your team’s infrastructure backlog.

We start by assessing your GitHub Actions or GitLab CI workload, runner requirements, security controls, cache behaviour, and support expectations. Then we propose a controlled pilot with clear success measures.

 [Discuss your CI runners](https://calendar.app.google/ceY8b2bxhCYgB1ot9)

### A strong fit if

- GitHub Actions or GitLab CI queues are slowing pull requests, builds, or releases.
- Your team is tired of operating, patching, and debugging self-hosted runners.
- You need Canadian runner placement, clear support ownership, or CAD billing.
- Your CI workload is bursty and you want capacity that grows with jobs instead of idle servers.

Pilot process

## Start with one workflow, not a platform rewrite.

1. 01
   ### Join early access

   Tell us whether you use GitHub Actions, GitLab CI, or both, and what you need from your runners.
2. 02
   ### Design the pilot

   We define runner sizes, concurrency, security boundaries, caching needs, and the success metrics for your team.
3. 03
   ### Run and evaluate

   Move a controlled set of jobs first. Compare queue time, job duration, reliability, and operating effort before expanding.

Talk to the people operating the platform

## Bring us one slow or costly CI workflow.

We will help you decide whether a ZSoftly CI Runners pilot is the right fit for your GitHub Actions or GitLab CI jobs, what it should measure, and what it would take to run safely in your environment.

[Join the early-access list](https://forms.gle/pALYZy5WrvvXKSkeA)

[Book a Google Meet](https://calendar.app.google/ceY8b2bxhCYgB1ot9)