Native build orchestration for game studios.

Game CI is not a queue that runs YAML. It is a scarce-capacity coordination problem across large source trees, expensive cook and package steps, platform SDKs, licensed tools, console hardware, distributed caches, QA drops and symbols. Horu CI is the native system for that, built on the same engine as Horu CLI.

Request early access Read the status split

In development. The service exists and runs builds; several documented capabilities are not implemented. Do not plan a migration off your current CI around this page, talk to us first.

Mental model

Every build is a release-evidence object.

A green badge is a claim with nothing behind it. Two weeks later, when someone asks whether a specific package is safe to promote, the badge cannot answer and the runner that produced it has been recycled.

So the unit Horu CI stores is not a status. It is a build with everything attached that a promotion decision needs, and it stays attached whether the work was executed by a Horu runner or delegated to somebody else's.

source: Which source point produced this build.
pipeline: Which pipeline definition and which toolchain version ran.
executor: Which runner or external executor performed the work.
outputs: Which artifacts, logs, manifests, symbols and checksums were produced.
validation: Which tests and validations passed, and which failed.
gates: Which release gates were satisfied, and by whose approval.
links: Which tasks, bugs, QA records and documents reference it.

Go or no-go

Four problems that justify a native CI, or none of this is worth building.

These are not convenience features. If Horu CI does not make each of these materially easier than GitHub Actions, Jenkins and a studio's own shell scripts, then a native CI product is not differentiated enough to exist and we should stay a CLI company.

Each problem, and the product requirement it creates.
Problem	Requirement it creates
Slow game builds	Build duration is a first-class product concern, not an operations detail. That means supersedence, release lanes, staged rebuilds, cache locality, dependency-aware scheduling, duration baselines and time-saved reporting.
Broken or opaque caches	Cache correctness and hit rate become records rather than hidden runner state: keys, scopes, invalidation reasons, warm and cold runs, restored and saved size, and the cache's contribution to build time.
Accidental shipping files	A built-in sanitation stage that removes or blocks files by pattern, extension, directory, platform, configuration and release policy before packaging or promotion, with a report of what it did.
Low-signal logs	Noisy engine and tool output normalised into failure anchors, missing-tool diagnostics, warnings, stage summaries and remediation hints, without every build file hand-coding the basics.

The specific question a native CI has to answer

Why was this build slow? Source sync, compile, cook and content build, cache miss, package, upload, tests, hardware scarcity, or waiting on an external executor. A pipeline that can only report total duration leaves that diagnosis to whoever has been at the studio longest.

Modes

Four ways a build gets into Horu CI.

The design principle across all four: Horu CI owns build state and release evidence even when execution is delegated elsewhere.

Execution modes and the contract each one implies.
Mode	Contract
Native CI	Horu owns trigger intake, queueing, runner control, execution state, artifacts, logs, manifests, status and release gates.
GitHub Actions connector	Horu receives workflow, run, job and artifact evidence and maps it into Horu build records and release gates.
Jenkins connector	Horu receives job, build, stage, log and artifact evidence from Jenkins: through a CLI step first, and an API adapter only if that proves insufficient.
Artifact import	Horu ingests artifact, manifest, source metadata and gate evidence from a build produced somewhere else entirely.

Connected mode

Instrumented, not passive.

A connector that records a commit hash, a job URL, an artifact URL and a pass or fail is close to worthless: the studio still owns every line of Jenkinsfile and workflow complexity, and has gained a second place to look. The connected mode that matters is Horu CLI running inside the external orchestrator, mapping results into the same build model as a native run.

01 Passive import Records external status and artifact references. A migration fallback, or minimal visibility. Low value.
02 Horu CLI instrumentation The primary adoption path. Init checks, stages, logs, cache reports, sanitation, artifacts, manifests, tests and reports all captured by the CLI.
03 Managed external stage External CI launches a Horu-defined stage bundle instead of owning the build glue. For teams keeping their launcher but wanting Horu pipeline semantics.
04 Native Horu CI Horu owns orchestration, scheduling, runners, caches, logs, artifacts, sanitation, reports and package checks.

The go or no-go rule for connected mode is one sentence: it is only worth shipping if it measurably reduces custom CI glue while producing better logs, cache evidence, sanitation evidence, artifact manifests and release-package inputs than the external system produces on its own.

Core jobs

Seven things the service is responsible for.

accept intent: Source events, manual runs, schedules, release gates, connected callbacks and artifact imports all become explicit build records rather than ad-hoc triggers.
plan the run: Each native run resolves source revision, engine and toolchain version, target platform, configuration, dependencies, caches, credentials and the artifact contract before it starts.
normalise external runs: GitHub Actions and Jenkins runs land in the same build, stage, artifact, test and gate schema as native ones.
schedule scarce capacity: Queues respect priority, branch and stream importance, platform hardware scarcity, concurrency, fairness, supersedence and release lanes.

collect evidence: Logs, artifacts, symbols, manifests, test and validation results, environment metadata and retention decisions are preserved rather than discarded with the runner.
report status: Source control, notifications, audit and integrations receive consistent build status and links, from one source rather than several.
gate releases: A release candidate can require successful builds, checks, approvals, source readiness, artifact retention and traceability before it moves.

Why waiting matters as much as why failing

On console and platform hardware the queue is often the bottleneck, not the build. A native CI that cannot explain why a job waited (contention, fairness, supersedence, a lane reserved for a release)has moved the mystery rather than solved it.

Status

The honest split, for Horu CI specifically.

The implementation does not yet match the documented target. Here is where the line sits today.

Implemented today

Build records, pipeline records and manual run paths
Source-event triggers and queue items
Runner pools, leases and heartbeats
Runner agent with host, container and test executors
Artifact upload and manifest validation
Log upload, stage records, rerun, retry and cancel
Release candidates and release gate evaluation
Raw Horu CLI report upload, with list and detail history
Web views for the CI surfaces above

Documented, not yet built

Horu CI runners orchestrating the shared build modules as their native execution path
Real remote cache restore and save, with the cache evidence that depends on it
Deep Unity and Unreal rule packs beyond the MVP diagnostic baseline
Web views for reports, cache analytics and package output
Release lanes, quotas, fairness, supersedence and why-waiting explanations
Retention profiles and package integrity checks as configurable policy

Under the hood: Go services, PostgreSQL for service state, and S3-compatible object storage for logs, artifacts, manifests, reports and package outputs. Hosted services run as container images; the runner agent installs natively and does not need Docker to register, lease work, heartbeat, stream logs, upload artifacts or report status.

Non-goals

Things Horu CI will not try to be.

Each of these is a decision we expect to be asked to reverse, and expect to defend.

See the full product boundary

A replacement for every studio build script on day one.
A CI template marketplace, with templates as the subscription value.
An owner of game engine build internals.
A migration prerequisite: nobody should have to leave GitHub Actions or Jenkins before Horu is useful.
A generator of production-management or wiki updates from build logs alone, without links to source, artifact, test or gate evidence.

Start with the CLI. Add the service when it earns it.

The adoption path we actually recommend: instrument one lane with Horu CLI, get local reports worth reading, then turn on upload and decide whether team history is worth hosting. Native orchestration is the last step, not the first.

Request early access Read the Horu CLI reference