Announcing ComputeSDK Actions: Run CI/CD where you want

Today we're announcing ComputeSDK Actions—our replacement for GitHub Actions for workloads of all kinds.

CI had become one of the biggest constraints on how fast we could build.

Over the past several months, we've run much of our business on GitHub Actions. It has orchestrated the benchmarks we use to evaluate AI gateways, sandboxes, browsers, storage, and more.

As our agents wrote more code and took on more of the development loop, a small mismatch became a real bottleneck. When we started building Actions, GitHub's workflow-dispatch API accepted a job but returned no run ID. An agent could trigger CI, then had to search for the run it had just created before it could follow logs or respond to a failure. GitHub has since added run details, but the experience made the larger problem obvious: the CI control plane wasn't designed around an agent owning the whole execution loop.

At the same time, our benchmark network grew to more than 50 infrastructure companies. Teams asked us to run the same benchmark in another region, on a specific provider, or across several providers. The larger shift was that development itself had become parallel. Multiple agents could work on features, fixes, and experiments at once, but every validation cycle still competed for capacity inside one runner fleet. Changing where a job ran became workflow work. Scaling how many development cycles could run at once became runner-provisioning work. CI was supposed to unblock development; instead, it was becoming the bottleneck.

So we built ComputeSDK Actions.

CI should scale with development cycles

Massive concurrency is a first-class feature of ComputeSDK Actions because software development no longer happens one branch at a time. Agents can open many development cycles simultaneously, and each one needs fast, isolated validation without waiting for another cycle to finish.

ComputeSDK Actions places runnable work into isolated sandboxes from providers including Namespace, Blaxel, Tensorlake, and Archil, across the regions they support. Instead of forcing every development cycle through one runner fleet, Actions can spread execution across the aggregate capacity of the sandbox ecosystem. More agents can keep shipping without CI becoming the synchronization point.

CI should not decide where a job runs

For infrastructure workloads, where a job runs is part of the work. Provider and region should be explicit inputs—not constraints inherited from the CI platform.

ComputeSDK doesn't depend on a single runner fleet. When a job is ready, Actions walks your ordered provider-and-region policy and places the work with the first provider that accepts it. If a provider rejects the job or cannot supply capacity, ComputeSDK tries the next candidate.

Provider choice gives you portability; ordered fallback gives you reliability. Switching between providers that support the workload doesn't require changing the workflow—update the placement policy and the same job runs somewhere else.

ComputeSDK records every placement attempt and the infrastructure that ran the job, making provider and region part of the workflow's observable output.

We're building a qualified provider catalog based on real compatibility, reliability, performance, and cost data—not a generic list of interchangeable runners.

Git is the contract

The Git protocol is ComputeSDK Actions' only hard dependency. The execution plane accepts a Git remote, credentials, and a ref or commit SHA, then discovers and runs the workflows stored in that repository.

Provider integrations terminate at the edge of the system. They can add installation flows, pull request events, and status checks, but Git remains the contract between your repository and the execution plane—not GitHub.

The goal is simple: if ComputeSDK can clone the repository, it can run its supported workflows. Keep working in Git and let ComputeSDK handle scheduling, placement, execution, and logs.

Keep the workflows that already work

GitHub pioneered an excellent workflow format. Replacing the execution layer shouldn't require rewriting the workflow.

ComputeSDK Actions runs supported GitHub Actions workflows, including existing actions, steps, secrets, matrices, schedules, and artifacts. We support a deliberate compatibility surface today and expand it as we validate more workflow behavior.

Give agents the whole development loop

Agents can trigger workflows, inspect state, follow logs, identify failed steps, download artifacts, cancel runs, and rerun workflows through the CLI and API.

Dispatch returns the run ID immediately, so the agent that started the work can follow that exact run through completion. The CLI supports structured output and error codes, scoped noninteractive authentication, and log streaming. When a workflow fails, an agent should be able to find the failed step, read the logs, and take the next action without handing the work back to a human with a browser.

Get CI out of the way

Agents are making code generation faster and development more parallel. That makes the verification loop more important, not less. CI can't become an opaque queue, an infrastructure constraint, or a browser-only debugging loop.

ComputeSDK Actions makes the verification layer scale with parallel development while keeping execution placement, workflow state, logs, artifacts, and recovery accessible to both humans and agents.

Your repository should define what runs. You should decide where it runs. That's ComputeSDK Actions.

Learn more about ComputeSDK Actions or sign up to start running workflows.

Add your provider to ComputeSDK Actions

Want developers and agents to run Actions workloads on your sandbox infrastructure? Reach out to us in Slack or email support@computesdk.com.