GitHub Actions
.github/workflows/ci.ymljobs: test:-
runs-on: ubuntu-latest+
runs-on: zsoftly-linux-x64ZSoftly 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.
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.
GitLab CI
.gitlab-ci.ymltest:+
tags:+
- zsoftly-linux-x64 script: - npm testWhy 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 runnersA 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.
- 01
Join early access
Tell us whether you use GitHub Actions, GitLab CI, or both, and what you need from your runners.
- 02
Design the pilot
We define runner sizes, concurrency, security boundaries, caching needs, and the success metrics for your team.
- 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.