FAQ

Why is it faster than GitHub Actions?

Four reasons, each a design choice rather than a bigger machine. A warm workspace at a fixed path keeps Cargo's incremental state, target/, node_modules/ and the package stores between jobs (hosted runners start cold every time). Affected selection runs only the targets a change touches, computed in the cell from the diff and cargo metadata. Identical requests from two agents or two retries are one job. Test binaries are compiled once and sharded across ephemeral workers without recompiling.

What does it cost?

Every job is metered in cost units (one vCPU-second of the executing worker); ciresk ci budget shows your spend and limits. A worker you run yourself costs what its host costs you: on AWS in eu-central-1 (on-demand prices read on 2026-10-20) a five-minute build on a 32 vCPU c8g.8xlarge is about $0.12 of compute, and a stopped instance costs its volume ($19 per month for 200 GB). A worker with idle_stop_secs set stops its own host after that long without a lease.

Do I need Bazel?

No. The platform is shaped like Bazel (a content-addressed action cache with remote execution) but the unit of work is a manifest task, not a BUILD target, so Cargo, pnpm, CMake and Gradle repositories onboard with one file.

Which regions?

The EU only, today: one cell, eu1, in AWS eu-central-1, at ci.eu.ciresk.com. An organization is pinned to one cell by its jurisdiction, and a credential from another region is refused before any query.

Where does my data live?

Source deltas, logs, artifacts, caches and test results stay in your organization's cell, under your organization's prefix, encrypted with the cell's key. Only identity, organization placement and API key records live in the shared Ciresk control plane. Running your own workers does not move that data: the cell hands a worker presigned URLs into the cell's own bucket, so it stays at Ciresk in the EU. A worker belongs to exactly one organization and receives no other organization's data; pass_env values are resolved on the worker from its own secrets backend. See Security.

What happens when the control plane is down?

A running task keeps running: the worker buffers log chunks locally (up to 256 MiB) and retries with backoff. If the outage outlasts the lease TTL (300 s, renewed every 30 s; see Limits) the worker kills the task and the cell requeues it when it returns, up to three times, after which the job is infra_error. New submissions fail with exit 8 after retries. Nothing is lost that was already reported: the journal is append-only in Postgres with point-in-time recovery. Workers are disposable; the API is stateless.

How does deduplication work?

A job is keyed by the organization, the repository, the base commit, the diff digest, the kind, the targets, full, the toolchains and the uploaded tree's root. An identical key already queued or running returns the existing job with deduplicated: true, and the budget is charged once, to the first submitter. Separately, every submission carries an idempotency key, so a retry after a timeout returns the same job rather than a second one. Cache entries are keyed by content too, so an unchanged task on a second run is a cache hit (verdict reused, outputs restored).

Why no YAML pipelines?

A pipeline run has no identity derived from its content, so two agents asking the same question get two runs and two bills, caching is bolted on per step, and the shape fits humans better than agents. Ciresk CI's unit is a task from .ciresk/ci.yaml: a command, its inputs, its outputs, its toolchains. That gives deduplication, caching and a one-line verdict for free. Orchestration across repositories, deploys and approvals belong to the tools that already do them; a GitHub Actions job can call ciresk ci run test --wait as one step.

Can I run it on my own hardware, in Azure or GCP, or air-gapped?

Workers, yes: ciresk-ci-worker runs on any Linux host, which includes an Azure or GCP VM you start yourself, and connects outbound to the cell. The control plane, no: Ciresk CI is offered as a service in the EU today, and self-hosted, hybrid and air-gapped installs are not available yet. See Run your own worker.

What happens to fork PRs and agent-generated branches?

Fork PRs, refs your policy marks untrusted and unknown principals run as untrusted: a fresh clone with no link to the shared mirror, its own network namespace whose only exit is the egress proxy in block mode, only on workers labelled isolation=vm or disposable, and a cache it reads from trusted_ci and writes only for its own job. See Security model. Agent-generated branches run like their submitter's unless your policy sets agent_branches_untrusted, which runs every agent:* job as untrusted. CI systems on protected branches run as trusted_ci; your own developers and their local agents run trusted_interactive on warm workspaces. In the trusted tiers the worker's egress proxy runs in audit mode by default: it records every destination and blocks none, unless your policy switches it to block.

Which languages?

Any: the runner executes what the manifest declares and knows no language. Rust is first-class because Cargo needs a warm, path-fixed workspace that nothing else provides. TypeScript, C++ with CMake, Java, .NET and others onboard with the same file.

Does it replace GitHub Actions?

It replaces the build, check and test step, not the event model. A GitHub Actions job exchanges its OIDC token for a one-hour Ciresk token, runs ciresk ci run test --wait --json, and its exit code becomes the check result that reviewers and auto-fix agents already subscribe to. The same command works from a developer's shell, from Claude Code and from Codex, which no GitHub-queue-only runner can do.

Does my agent see secrets?

Not through Ciresk CI's output. pass_env values are resolved on the worker from its own secrets backend and injected into the task process's environment; they are masked in log chunks and are not part of keys, results, events or summaries. The agent's token is scoped; a person's token lives in the OS keychain, not in a config file; GitHub Actions gets one-hour tokens through OIDC exchange. The CLI sends no prompts or transcripts.

What happens when the budget runs out?

Budgets are per actor, per session and per day, in cost units (one vCPU-second of the executing worker). Past the soft budget a job still runs at the lowest priority; past the hard cap the CLI exits 5 with the reset time, and an MCP result says remaining: 0. Every response carries the budget, ciresk ci budget shows it, and --budget <units> caps one job.

Is git required?

No. A folder with a .ciresk/ci.yaml and no remote is registered under a slug of its own on the first run; the working tree travels as a tree of content digests and only what the cell lacks is uploaded. See Caching and tree sync.