HoruSphere Systems

Product index

Two products in development. Four planned.

This page exists to disambiguate names, not to sell you anything. Each entry carries the status we would give it in a technical conversation. The argument for any one of them lives on its own page.

Build operations

Horu CLI is the adoption surface and the execution engine. Horu CI is the system that owns orchestration when a team decides it wants that. They share the build modules, so they cannot drift into two different definitions of a build.

Disambiguation

Which one you actually want.

Most teams should start on the left column and never think about the right one until something forces them to.

Product selection by situation.
Your situation Start with Why
Jenkinsfile has grown into build engineering glue Horu CLI The commands replace defensive scripting in place. Jenkins stays the orchestrator and nobody has to approve a migration.
Nobody can explain why a cache missed Horu CLI Cache keys are declared from named files, entries are split per path, and miss reasons land in the report rather than in someone's memory.
A development config shipped to a store build Horu CLI horu package makes sanitation a step with a report, and forbid rules fail the run instead of cleaning up quietly.
You want build history across the whole team Horu CLI, then Horu CI horu report --upload sends the same records to Horu CI for list and detail history. Local value comes first; hosting is a later decision.
Queueing and scarce platform hardware are the bottleneck Horu CI Runner pools, leases, queue items and release gates are service concerns. A CLI cannot arbitrate contention between machines.
You want to move off your current CI entirely Horu CI, with a caveat Native orchestration exists but is in development. Talk to us before planning a migration around it.

Planned products

  • Horu ReleaseOps Planned

    Release candidates and promotion gates

  • Horu PM Planned

    Evidence-backed production management

  • Horu Wiki Planned

    Evidence-linked studio knowledge

  • Horu VCS Planned

    Source intelligence for builds

These four have no product pages, and that is the point.

They are specified in our architecture documentation, and none of them is a first-year adoption requirement. Each becomes worth building only once build and package evidence is reliable enough to sit underneath it. A release-readiness dashboard built on cache reports we do not fully trust yet would be a dashboard about nothing.

What each deferred surface would own, and what has to be true first.
Surface Would own Blocked until
Horu ReleaseOps Release candidates, readiness views, evidence matrices, promotion gates, approvals, handoff packs, release-note inputs. Package manifests, sanitation reports and gate evaluation are trustworthy enough to promote a build on. Candidate-style views live inside Horu CI first.
Horu PM Tasks, bugs, milestones, asset work, QA triage, and milestone readiness backed by build records. Buyers ask for it. We will not sell production management as a condition of fixing a build pipeline.
Horu Wiki Design docs, technical specs, runbooks, release notes and postmortems linked to the runs that caused them. Build and package evidence is stable. Generated notes would remain draft-only and attributable by default.
Horu VCS Source-to-build-to-package traceability, large binary assets, branching, locks and review. CI artifacts and manifests are reliable. Connected Git source context comes long before any first-party Git server.

Scope

What we are not building.

A product index is more useful when it says where the edges are. These are standing decisions, not gaps waiting to be filled.

  • Replacing every studio build script on day one.
  • Selling CI templates as the subscription value.
  • Owning game engine build internals directly.
  • Requiring a migration off GitHub Actions or Jenkins before Horu is useful.
  • Asking a studio to move source control first.
  • Requiring a hosted signup for first value.
  • Generating production-management or wiki updates from build logs without links to source, artifact, test or gate evidence.
  • Making any language-model feature a prerequisite for CLI or CI value.

Start where the pain is.

One Unity or Unreal build lane, one config file, one before-and-after comparison. That is the entire evaluation we ask for.

Request early access Read the Horu CLI reference