runnerless↗

Runnerless concept · not available yet

Deployment approvals tied to an exact artifact

An approval should say which bytes and environment it authorizes. A future Runnerless deployment workflow could connect a reviewed release or comment action to a verified artifact, with a narrow tool permission for the selected target. The current toolkit supplies useful building blocks, but it does not deploy applications.

Design direction for Runnerless. The workflow below is not implemented or available to install.

The proposed workflow

01 /

Identify the decision being approved

A useful approval record includes the repository, commit, artifact digest and environment. Approving “the latest build” is ambiguous when another build can arrive before the deployment runs. Commit-addressed URLs help locate a file, while the digest pins the bytes.

02 /

Check authority again before acting

The existing /merge implementation checks the actor’s current permission and refuses a disallowed merge method. Deployment actions could follow the same pattern: verify permission for the target environment at execution time, then perform only the approved action. A comment’s wording alone should not grant access to cloud credentials.

03 /

Separate delivery from recovery

A deployment result should record the published version and health outcome. Rollback is a distinct action whose compatibility depends on configuration and data changes. The workflow should explain a blocker when it cannot establish a safe action, rather than silently switching target, method or artifact.

A concrete example

Workflow example

Proposed approval record
  repository + commit
  artifact SHA-256
  target environment
  authorized actor
  permitted deployment action

Approval → recheck authority → publish exact artifact

Know the boundary

What is still to build

Environment approvals and cloud deployment actions are not current ci-toolkit features. The planned platform story includes Cloudflare, Vercel, AWS, GCP and Azure. Credentials, environment policies and rollback semantics would need provider-specific implementation and review.

Common questions

Does merging a toolkit release PR deploy my application?

No. Current release automation creates version and changelog changes, tags and optionally a GitHub Release. Deployment is separate.

Would a commit URL be enough to approve exact bytes?

No. A rerun can replace the available artifact for the same commit. An exact approval should include the digest.

Runnerless / early access

Want this in
your workflow?

Get early access ↗

Register interest and tell us what slows your CI down. The optional follow-up questions come after your email is saved.