runnerless↗

Runnerless concept · not available yet

Deploy compiled Cloudflare Workers from CI artifacts

A compiled Worker is already a deployable build output. Runnerless could make the handoff from trusted CI artifact to Cloudflare deployment a small, inspectable workflow: identify the exact bundle, verify it, apply the intended configuration and publish it with a recorded version.

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

The proposed workflow

01 /

Start with the output the build already produced

Compilation stays in existing CI when it needs a toolchain or a large dependency graph. The deployment workflow would consume the resulting Worker bundle and its manifest, bound to a commit and digest. Rebuilding a different bundle during deployment would weaken that relationship.

02 /

Treat optimization as a visible step

A proposed optimization hook could report bundle size, remove unused packaging or apply an agreed transformation before publishing. Any transformation changes the deployed bytes, so it should produce a new digest and an inspectable result. The site does not claim an implemented optimizer or guaranteed size reduction.

03 /

Publish with deliberate bindings and recovery

Deployment needs more than JavaScript: environment selection, bindings, secrets and permissions must agree with the intended target. A future workflow should distinguish application publication from durable infrastructure ownership and record enough version information to select a compatible rollback.

A concrete example

Workflow example

Proposed deployment flow
  trusted CI bundle + manifest
    → verify commit and SHA-256
    → optional reviewed optimization
    → publish compiled Worker
    → record deployment version and health result

Availability and limits

What is still to build

This is a Runnerless integration concept, not an existing ci-toolkit deployment adapter. It does not implement compilation, minification, automatic rollback or secret provisioning today. Databases and schema changes may need a separate recovery decision even when application code can roll back.

Common questions

Would a deployment require a full CI runner?

The direction is to avoid a separate runner for the small publication step. The original compilation may still need one.

Is Cloudflare the only planned target?

Cloudflare compiled Worker publishing is a primary direction. Vercel, AWS, GCP and Azure are also in the planned integration story, without implemented adapters or launch commitments.

Credential handling during publication

Verifying an artifact’s origin does not establish that its contents are free of secrets. Read about accidental CI secret leaks and how modern CI protects secrets for the exposure paths, existing controls, and planned isolation model. Why your publishing service should pull artifacts explains the benefit of fetching and verifying build output in the publisher.

Runnerless / early access

Interested in this 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.