runnerless

Early access / building in the open

A one-second
check shouldn’t
need a runner.

Less machinery between an idea and a green check.

Fast repository checks, programmable automations, and custom AI hooks. Across the CI you already use.

See what it could look like
Small tasks. Smaller footprint.Bring your CI.Keep your control.

01 / The overhead problem

It’s a tiny check.
Why the whole production?

A missing license. A broken link. One policy rule. The work is small. The machinery around it isn’t.

A familiar chain of eventsIllustration / not to scale
  1. 01Wait in queue
  2. 02Provision runner
  3. 03Pull an image
  4. 04Install dependencies
  5. 05 / the actual workRun the check ✓
  6. 06Store artifacts

The check is the point. Everything else should earn its place.

A /

Same policy.
Four implementations.

Rules drift between CI providers. Shared JavaScript could put repository logic in one place.

B /

Simple idea.
Complicated rules.

Conditions and workarounds accumulate. Use real code when a configuration file stops helping.

C /

Tiny task.
Infrastructure attached.

Queueing, setup, storage, and runner time are part of the bill. Give small checks a smaller place to run.

02 / A little config. Real code when you need it.

Your YAML is welcome.
So is your JavaScript.

Describe a check once. Reuse its logic. Start beside your existing pipeline, one small task at a time.

API preview 
# 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.

Working examples / ci-toolkit today

The workflows
behind the idea.

These automations already run in our ci-toolkit Cloudflare Worker. They’re concrete starting points for Runnerless, whose runtime and integrations are still in development.

Explore all 12 current capabilities and 6 Runnerless concepts ↗

01 / Actual ci-toolkit configuration

A consistent title.
A clean commit history.

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-commits
02 /

Review the code
that’s actually merging.

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.

Read about the Codex review gate ↗
03 /

Make merge
a command.

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.

Explore the /merge command ↗
04 /

Build finishes.
Report appears.

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

05 /

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

03 / Connect the work

Across pipelines.
Beyond the green tick.

The planned integration story: small checks, useful artifacts, and a path from source to deployment.

Cloudflare / planned integration

Compiled Worker.
Ready for the edge.

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

Keep the small
things correct.

Check manifests, required files, licenses, links, and repository policy without treating every sanity check like a full build.

Artifact handling

One workflow.
Many sources.

Find, validate, move, and retain artifacts across GitHub Actions, CircleCI, GitLab CI, and BuildBuddy.

Planned adapters / community extensible

Deployment workflows

Choose your
destination.

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.

04 / Your AI. Your boundaries.

Hooks for the work
between the jobs.

Bring AI into a workflow where it helps. Decide which tools it can call, which context it can read, and which actions require your approval.

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

05 / Built to be opened up

A small core.
An open horizon.

The plan is an open-source, extensible runtime with integrations the community can build on.

Use a hosted service or run it yourself. Serverless platforms or conventional servers. The ambition is portable automation, with deployment choices that fit your team.

The public runtime and contribution workflow are still to come. Join early access to help shape what lands first.

Less waiting. More doing.

Give the small
work a fast lane↗

Get early access ↗

Early interest. No product access yet.

A few practical questions

Before you ask.

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.

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.