A delivery pipeline can be correct and still be fragile. If the repository host, workflow scheduler, and job runtime share the same failure domain, one incident can stop every path to production.
Runnable separates those responsibilities. GitHub or Entire remains the source of truth for code. Runnable receives the event, plans the workflow, schedules the jobs, and runs them on clean Linux machines through an independent control plane.
The migration constraint is deliberately narrow: keep the workflow semantics you already understand. A compatibility report identifies what can move, what needs review, and what should stay on the current CI before a single production run is switched.
The control plane after git push
A signed repository event enters Runnable and becomes a workflow run. The scheduler evaluates triggers and conditions, expands matrices, resolves dependencies, and releases each job only when its prerequisites are satisfied.
Ready jobs are dispatched to single-use runners. Logs stream while the job is active; conclusions, usage, and retained outputs remain attached to the run after the machine is gone. Cancellation and reruns are control-plane operations rather than best-effort signals sent to an opaque worker.
One workflow. Two repository sources.
Runnable accepts GitHub repositories through the GitHub App and repositories on Entire through regional mirrors or Entire-native remotes. Both sources enter the same planning and execution path.
The repository stays authoritative. A job receives the exact commit requested by the event, and the credential used to fetch it is short-lived and scoped to that job. Runnable does not need to become a second long-lived home for your source code in order to execute it.
One clean machine per job
A runner is created for one job and discarded when that job reaches a terminal state. Secrets are decrypted for the job that needs them, masked from logs, and withheld from untrusted fork pull requests.
Isolation is part of the execution model, not an enterprise add-on. Every plan uses the same job boundary; plans change capacity, concurrency, and retention rather than the security contract.
Compatibility is a report, not a surprise
Familiar YAML does not guarantee familiar behavior. Actions, expressions, service topology, identity, and platform assumptions all affect whether a workflow can move without changing what it means.
Runnable scans those constructs before migration and produces a reviewable result. Supported behavior can run in parallel. Ambiguous behavior is called out for review. Unsupported behavior stays on the current CI until the boundary changes.
- Runs hereTriggers, matrices, dependencies, conditions, outputs, environments, artifacts, cache, cancellation, and reruns.
- Needs reviewWorkflows whose behavior depends on provider-specific permissions, topology, or runtime assumptions.
- Stays putAnything outside the published runtime contract. Runnable fails closed instead of approximating it.
The boundary ships with the product
Runnable starts with Linux x64 and a documented compatibility surface. The point is not to claim that every workflow belongs here. The point is to tell you which workflows do before they become an incident.
Connect a repository, inspect the report, and pilot compatible workflows in parallel. Your existing CI remains available until the evidence says a switch is boring.