Horde and Custom Build Systems

Start a build-system decision with work that must be coordinated, not a product comparison. Identify the missing boundary: scheduling, agent lifecycle, artifact identity, access control, or failure ownership. Improve existing CI when that resolves it. Consider Horde when its operating model matches the boundary; build custom only for a smaller contract that can be owned for its lifetime.

This is a decision framework, not a description of a prior customer production deployment of Horde. Validate any adoption against the local source-control model, worker environment, security requirements, and operational ownership before it carries release work.

Start with the workload boundary#

Describe work independently of an orchestrator: source events, dependencies, targets, shared resources, outputs, promotion decisions, and stop conditions. Distinguish compilation and cooking from signing, tests, content processing, and release assembly; they may need different scheduling, identity, and recovery rules.

Existing CI is often right when its jobs can express these boundaries and gaps are unclear scripts, mutable workspaces, or weak artifacts. Replacing a scheduler cannot repair unknown inputs. Make the worker contract and artifact manifest explicit before judging the orchestrator.

Evaluate the agent boundary#

A build platform earns complexity when it places work on declared capabilities and recovers from worker loss without preserving a machine. Define the agent contract before selecting tooling: operating system, toolchain, engine revision, storage, network access, hardware, identity, and cleanup.

Horde may fit coordinated work across agent pools, shared build definitions, and visibility that would otherwise require substantial integration. A narrow custom system may fit a stable workflow with explicit jobs, provided it does not become an undocumented scheduler, credential store, and artifact index.

Keep capabilities and trust separate#

Classify an agent by what it can do and what it may access. A worker capable of compiling source should not automatically receive release credentials. A worker with a specialized platform SDK should not silently become the fallback for unrelated jobs. The chosen system must let the build definition request both capability and trust level, then make that selection inspectable.

Define the artifact boundary#

No scheduler should be the only record of a build. Publish immutable artifacts with a manifest containing source and build-definition revisions, environment identity, target, checksums, and compatibility information. Promotion should select that manifest rather than search a workspace or latest label.

This boundary is also where an existing CI path can often be improved cheaply. If artifacts cannot be reproduced or found without a particular agent, fix that before adopting a broader platform. Horde or a custom service should consume and publish the same explicit artifact contract.

Define the security boundary#

Build automation crosses source, cache, artifact, signing, and administration trust zones. Map them to separate identities with narrow permissions. Inject secrets only for the needed task, exclude them from images and logs, and make them revocable without rebuilding workers.

Evaluate whether a candidate system exposes enough control to audit who started work, which identity performed a privileged action, and what source revision received that action. If it cannot, compensate with a surrounding control only when that control has a clear owner and a tested failure mode.

Price the operations boundary#

Every system has operations work. Assign ownership for upgrades, recovery, access review, agent registration, credential rotation, incidents, capacity policy, and documentation. A custom system is not small if operators recreate broader-platform features; a broad platform is not free if its services exceed operational capacity.

Choose the smallest system that exposes the necessary boundaries and can be recovered by the people responsible for it. Avoid treating a proof of concept as an operations plan.

Adopt in a bounded sequence#

• Map one existing delivery path, including handoffs and recovery dependencies.
• Make source inputs, worker capabilities, artifact manifests, and identities explicit.
• Select a noncritical workload with representative agent and artifact needs.
• Validate the candidate path with replacement workers, unavailable cache, failed jobs, and revoked access.
• Document operational ownership before adding release-critical or privileged work.
• Expand only when the prior boundary has a clear recovery procedure.

Set exit criteria before expansion#

A trial should answer whether the chosen system can run the selected workload without hidden local state, identify artifacts after a worker is gone, isolate privileged actions, explain failures to an accountable owner, and recover from routine infrastructure loss. It should also establish whether the configuration can be reviewed and changed safely.

If those conditions are not met, stop expansion and improve the missing boundary. The right outcome may be a better existing CI path, a smaller custom component, or a different adoption sequence. Exit criteria protect the team from treating novelty as progress.

Practical checklist#

• The workload is described independently of any orchestration product.
• Existing CI has been evaluated after inputs and artifacts were made explicit.
• Agent capabilities, trust levels, and replacement behavior are defined.
• Immutable artifact manifests exist outside worker storage.
• Source, cache, publishing, and signing access use separate identities.
• Privileged work has a visible approval and audit boundary.
• Operational ownership covers recovery, upgrades, access, and incident response.
• A representative noncritical path is selected for validation.
• The evaluation includes worker, cache, job, and credential failure cases.
• Expansion depends on stated exit criteria rather than tool preference.