Connect a repository
The planned hosted service handles execution for supported checks. You won’t need to provision a runner fleet, container, or VM just for that automation. Your existing build jobs can stay as they are.
In development / register early interest
Reduce CI costs without replacing your pipeline.
Spend less on runner setup for small checks.
Runnerless is a repository automation product in development, designed to move small checks and release coordination off paid CI runners. The aim is fewer machines and setup scripts to maintain, while keeping your existing CI for builds and tests.
Early interest only. Public installation and pricing are still to come.
Skip runner setup for small checks.
Keep builds in your existing CI.
Start with one automation.
01 / Simple setup · planned experience
Start with one repository automation
The setup we’re building: install the GitHub App on selected repositories, choose a supported automation, and move that small job off your runner. Start with one check; expand when it earns its place.
Choose a small job
Start with a PR title check, repository rule, or release coordination. Moving a separate job off a runner billed in whole minutes can remove its rounded-up usage. Your plan, allowance, and Runnerless costs determine the money saved. Estimate your savings →
Reduce setup maintenance
Stop maintaining runner images, operating-system packages, and setup scripts just to label a PR or enforce a repository rule. Use a built-in automation, then add YAML or shared JavaScript when you need custom logic. Those configuration options are part of the plan. YAML and JavaScript examples →
02 / Your CI costs · today’s usage first
Estimate avoided CI runner charges
Using release-please or release-plz? Release checks, PR policies, and repository housekeeping can consume paid runner minutes on every push. See what those jobs already cost your project.
The goal: one click to move release coordination off your runners. Keep builds, tests, and artifact production in your existing CI. One-click migration is planned; release-plz integration is not available yet. See the release automation already running in our private ci-toolkit App →
At current volume / month$30.00
At current volume / year$360.00
Per triggering commit / before allowances3¢
Potential avoided CI charges for these jobs only, before Runnerless costs. Annualized at your current monthly volume.
┄ Current volume
View monthly numbers and calculation
Each job uses its runtime rounded up to whole minutes. Multiply by jobs per triggering commit and monthly triggering commits, subtract remaining included minutes (down to zero), then multiply by the runner rate. Included minutes reset each month.
| Month | Current commits | Runner minutes | Avoided charges | Cumulative |
|---|---|---|---|---|
| 1 | 1,000 | 5,000 | $30.00 | $30.00 |
| 2 | 1,000 | 5,000 | $30.00 | $60.00 |
| 3 | 1,000 | 5,000 | $30.00 | $90.00 |
| 4 | 1,000 | 5,000 | $30.00 | $120.00 |
| 5 | 1,000 | 5,000 | $30.00 | $150.00 |
| 6 | 1,000 | 5,000 | $30.00 | $180.00 |
| 7 | 1,000 | 5,000 | $30.00 | $210.00 |
| 8 | 1,000 | 5,000 | $30.00 | $240.00 |
| 9 | 1,000 | 5,000 | $30.00 | $270.00 |
| 10 | 1,000 | 5,000 | $30.00 | $300.00 |
| 11 | 1,000 | 5,000 | $30.00 | $330.00 |
| 12 | 1,000 | 5,000 | $30.00 | $360.00 |
Five separate five-second jobs mean 25 seconds of work but five billed minutes. Moving those jobs can remove that runner usage; included allowances or free runners can make the cash savings zero. These estimates exclude Runnerless/BYOC costs, taxes, and storage. Runnerless pricing is not published yet.
Source: GitHub Actions runner pricing, checked September 8, 2026. Enter your actual rate; this model uses whole-minute rounding per job.
Get early access ↗03 / Working examples · private ci-toolkit today
Automation running in our private ci-toolkit App
These automations already run in our private ci-toolkit GitHub App, powered by a Cloudflare Worker. They are the working foundation for Runnerless. Public installation, the general-purpose runtime, and wider integrations are still in development; signup records interest.
12 private ci-toolkit capabilities and 6 planned Runnerless features ↗
01 / Actual ci-toolkit configuration
Check PR titles and commit messages
Check PR titles and individual commit messages against Conventional Commits. The effective policy comes from the trusted default branch, so a PR cannot authorize itself.
.ci-toolkit.yml · supported today
How PR title checks work ↗api_version: ci-toolkit/v1alpha1
pull_requests:
title:
format: conventional-commits
commit_messages:
format: conventional-commitsRequire review of the current PR commit
Apply codex: auto-review to request a review for the
current PR head. The review gate checks the trusted verdict and
unresolved threads before going green.
Request a merge from a PR comment
An authorized /merge comment requests a squash merge.
Pending checks or an outdated base enable auto-merge; conflicts
and draft PRs return a blocker. Existing checks still decide
eligibility.
Link build reports from the PR
A trusted BuildBuddy status triggers artifact validation and publication to an immutable public URL, then updates one PR comment. Checksums and configured retention travel with the report.
BuildBuddy → artifact → PR comment
How test reports reach your PR →Prepare the next release
The toolkit.release-please@v1 automation prepares
version-file and changelog changes in a release PR, then creates
the configured tag and GitHub Release after merge.
Commits → release PR → tag + release
Release configuration and workflow → What do your release checks cost? →04 / Why runner overhead adds up
Why setup can take longer than the check
Checking a license file, a link, or a policy rule in a dedicated CI job can take more time to set up than to run. Runnerless aims to remove that setup for supported automations.
A familiar chain of eventsIllustration / not to scale
- 01Wait in queue
- 02Provision runner
- 03Pull an image
- 04Install dependencies
- 05 / the actual workRun the check ✓
- 06Store artifacts
The target is about one second for small, local checks. This is an ambition, not a measured benchmark; network calls and AI take their own time.
Reuse policy across CI providers
Rules drift between CI providers. Shared JavaScript could put repository logic in one place.
Use code for complex conditions
Conditions and workarounds accumulate. Use real code when a configuration file stops helping.
Reduce overhead for short jobs
Queueing, setup, storage, and runner time are part of the bill. Give small checks a smaller place to run.
05 / Configuration · API preview
Configure checks with YAML or JavaScript
The planned configuration lets YAML and JavaScript call the same check logic. Adopt it alongside your existing pipeline, one task at a time.
# API preview · not a released schema
on: pull_request
checks:
repository:
use: ./checks/repository.js
with:
requireLicense: true// .runnerless.js · API preview
import { repository } from './checks/repository.js';
export default {
on: 'pull_request',
checks: {
repository: () => repository({
requireLicense: true,
}),
},
};# .runnerless.yml · API preview
# YAML describes when. Shared JS defines the check.
on: pull_request
checks:
repository:
use: ./checks/repository.js
with:
requireLicense: true
# Keep large builds in your existing CI.
# Adopt one small check at a time.// checks/repository.js · shared by YAML and JavaScript
// API preview: repository context is supplied by the runtime.
export function repository({ requireLicense }, context) {
return !requireLicense || context.files.has('LICENSE');
}01 Same repository check in every mode.
02 Shared logic in checks/repository.js.
03 Proposed syntax, subject to change.
06 / Integrations · planned
Planned CI and deployment integrations
The planned integration story: small checks, useful artifacts, and a path from source to deployment.
Cloudflare / planned integration
Publish a compiled Cloudflare Worker
Verify a compiled Worker, optimize the output, and publish it as part of a programmable workflow. Make deployment logic reusable across repositories.
Compiled output→Check + optimize→Publish ↗
Product direction. Publishing and optimization are not available
yet.
Repository verification / planned
Check repository files and policies
Check manifests, required files, licenses, links, and repository policy without treating every sanity check like a full build.
Artifact handling / planned adapters
Handle artifacts from several CI providers
Find, validate, move, and retain artifacts across GitHub Actions, CircleCI, GitLab CI, and BuildBuddy.
Planned adapters / community extensible
Deployment workflows / planned
Connect your deployment platform
Cloudflare first in this preview. Vercel, AWS, GCP, and Azure are part of the planned integration story.
Keep large builds where they work today. Connect the steps around them.
07 / Security and ownership · planned
Where automation runs and how credentials are handled
Decide where automation runs, how it connects to your CI, and which credentials it may use. These are design goals for the public runtime; deployment packages and the credential service are still to come.
Keep credentials outside automation code
The planned security model keeps integration credentials outside your automation code. Code requests an allowed action; a separate service uses the credential. This would keep the downstream credential out of build-process memory, provided the service enforces isolation and never returns it. Why core dumps can contain secrets →
Coordinate work around your existing builds
Keep compilation, tests, and artifact production in your existing CI. Let Runnerless take care of the surrounding checks, approvals, artifact delivery, and release and deployment coordination as integrations become available.
Run in your cloud with your API keys
Planned BYOC lets you run Runnerless in your own cloud account. BYOK lets you connect your own API keys for AI and integrations, with credentials kept outside automation code. Choose hosted convenience or infrastructure you control.
08 / AI hooks · planned
AI hooks for issues, reviews, and proposed changes
The planned hooks let you bring AI into a workflow where it helps: summarize an issue, request a review, or propose a change. Configure which tools it can call, which context it can read, and which actions require your approval. Proposed AI tasks and permissions →
AI inference and network-dependent workflows have their own latency. The one-second target is for small, local checks.
01Comments & issues ↗
02Code review & analysis ↗
03Proposed code changes ↗
04Tool calls & workflow actions ↗
Planned hooks / configurable tool access
09 / Open source and hosting · planned
Plans for an open-source runtime
The plan is an open-source, extensible runtime with integrations the community can build on.
We plan to support a hosted service and self-hosting on serverless platforms or conventional servers, so teams can choose where their automation runs.
The public runtime and contribution workflow are still to come. Join early access to help shape what lands first.
A few practical questions
Runnerless FAQ
What is Runnerless?
Runnerless is a repository automation product in development. It aims to reduce CI runner costs and maintenance by running small checks and workflow coordination outside dedicated CI jobs. The planned experience starts with a GitHub App and supports YAML, JavaScript, and existing CI pipelines.
Which jobs are a good fit to move first?
Start with short, separate jobs: PR title and commit checks, required-file policies, release coordination, or publishing a finished build’s report. The best candidates spend more time on runner setup than their actual work. Compilation, large test suites, and artifact production stay in your existing CI.
Checks sharing a build job may add little billable time. The CI savings calculator counts separate jobs and included minutes so you can estimate your own case.
What does Runnerless cost?
Runnerless pricing has not been announced. The calculator estimates CI charges you could avoid, before Runnerless, hosting, API, or AI costs. It is not a quote or a net-savings guarantee. Free runner usage or unused included minutes can mean no immediate bill reduction.
Can I use Runnerless today?
Not yet. We’re building the product and gathering early interest. This is the launch page for that work, not a released execution engine. There is no announced launch date.
Do I have to replace my YAML?
No. The planned approach supports YAML, JavaScript, and both together. Keep existing CI and adopt individual checks incrementally. The configuration above is an API preview.
What about large builds?
Keep compilation, large test suites, and resource-intensive builds on the infrastructure that suits them. Runnerless focuses on small checks and automation around existing pipelines.
Will AI hooks run in one second?
That is not the target. AI inference, external tools, and network calls take their own time. The one-second ambition applies to small, local checks, and is not a measured benchmark.
Can I self-host it?
Self-hosting is part of the product plan, alongside a hosted offering. We’re exploring serverless and conventional server deployments. Deployment packages are not released yet.
Will installing the app immediately lower my bill?
The aim is to cut runner usage as soon as you move supported automations. For example, GitHub documents rounding billable job time up to the next minute for private repositories using GitHub-hosted runners. Moving those jobs removes their runner minutes; whether your bill falls depends on included allowances, usage, and the cost of running Runnerless. Public installation and Runnerless pricing are not available yet.
Why can a core dump contain CI secrets?
A core dump records a process’s memory when it crashes. In a typical CI job, secrets injected as environment variables or read by an SDK can be present in that memory. If core dumps are enabled, those values can end up in a crash file and then in an uploaded debugging artifact. Masking console logs does not scrub that file. systemd’s core dump documentation explains how process memory is collected and stored.
Runnerless’s planned approach is to keep integration secrets out of automation memory entirely: code gets permission to request an action, not the credential itself. That removes this leak path for those secrets. The service holding credentials still needs protection; secrets you put in your own code or inputs remain exposed. This isolation is a design goal, not a shipped guarantee. Accidental CI secret leaks explains these exposure paths. Read how modern CI protects secrets for the controls and their limits.
What do BYOC and BYOK mean here?
Bring your own cloud: run the planned runtime in your cloud account. Bring your own keys: use your own AI-provider and integration API credentials through the planned secret-handling service. You control the accounts and their usage bills. Supported providers and deployment packages are still being developed.
How can I contribute?
Tell us which checks and integrations you need using the optional questions after signup, or email hello@runnerlesshq.com. The open-source repository and contribution guide will follow.
Help choose the first automations
Which CI task would you move first?
Get early access ↗Early interest. No product access yet.