Kestrix: Redefining CI Trigger Logic with DAG and HCL

When CI Stops Idling on Irrelevant Changes

Most teams' complaints about CI aren't about "running slowly" — they're about "running unnecessarily." A docs change in one repo, a minor style tweak in a frontend component — these often trigger the entire pipeline, wasting not just machine time but also developers' patience waiting for feedback. Kestrix, launched on Product Hunt, is aimed squarely at this pain point: it positions itself as a repo-agnostic CI control plane, organizing task dependencies with a DAG (directed acyclic graph) and ensuring tasks only execute when the repositories they declare have actually changed.

The tool currently has 68 votes and 3 comments, ranking 17th on Product Hunt for the day in the Developer Tools category, authored by Damian Giebas.

The DAG Isn't Just a Diagram — It's an Execution Boundary

Kestrix's core mechanism can be broken into two layers. The first is how you declare things: CI/CD pipelines are defined in HCL, reminiscent of Terraform's configuration style — the infrastructure-as-code philosophy extended to pipeline orchestration. The second is how they're parsed: these declarations are parsed into a DAG, where the ordering of task dependencies is determined by the graph's topology rather than implicitly assumed from a top-to-bottom script order.

What's really interesting is the trigger semantics. The original text explicitly states: "A task runs only when the repositories its trigger names have changed." In other words, each task can declare which repositories it cares about, and only when those repositories change does the task enter the execution queue. For cross-repository collaboration projects — say, a frontend repo, a backend repo, and a shared library — this granularity means a change to the shared library only wakes up the tasks that actually depend on it, rather than re-running the entire graph.

The underlying insight is this: CI efficiency problems are often not about insufficient parallelism, but about the execution set being too large. Pushing the "should this run?" decision down from a global judgment to the task level is a structural optimization, not something you patch with caching or faster machines.

DAG (Directed Acyclic Graph) is a fundamental data structure in computer science for describing task dependencies: nodes represent tasks, directed edges represent "A must complete before B" constraints, and "acyclic" ensures dependency chains don't form infinite loops. In the CI/CD context, the value of a DAG lies in making explicit the ordering relationships that are implicit in linear scripts — a task only needs to wait for its direct upstream, not for unrelated parts of the entire pipeline. This allows the scheduler to execute independent branches in parallel and, when a node fails, precisely determine which downstream tasks to skip and which are unaffected. Compared to traditional stage-based pipelines, the DAG model more closely reflects the "partial dependency" patterns in real engineering, and is an abstraction adopted by tools like Airflow, Tekton, and GitHub Actions' needs keyword.

HCL as a Pipeline Language: The Choice and Its Cost

Using HCL to describe CI/CD isn't a mainstream choice — YAML still dominates the vast majority of CI configurations. Kestrix likely chose HCL for its expression capabilities and structural features: variables, functions, and modular patterns are better suited than YAML for expressing complex dependencies with conditions.

The cost is equally direct: HCL has a steeper learning curve than YAML, and team members who haven't worked with Terraform will need to adapt. This means Kestrix's early users are more likely to be engineers already comfortable with infrastructure-as-code rather than small teams looking for "out-of-the-box" simplicity. This is a product positioning trade-off, not a flaw, but it will limit its initial audience.

HCL (HashiCorp Configuration Language) was developed by HashiCorp, originally for Terraform, and is also used by products like Vault, Nomad, and Packer. It's a declarative configuration language with syntax close to JSON but supporting comments, variable interpolation, function calls, conditional expressions, and reusable module blocks — allowing it to express more complex logic than pure YAML without embedding scripts. Another characteristic of HCL is the distinction between "configuration blocks" and "expressions": blocks define resource structure, while expressions handle value computation — this separation makes configuration both readable and programmable. The cost is that it isn't a general-purpose programming language, debugging options are limited, and its ecosystem and editor support are far less widespread than YAML — which is precisely the real constraint Kestrix faces in choosing it.

Two Details on Observability and the Security Model

Kestrix offers clear design decisions in two easily overlooked areas.

First, log presentation. The original mentions "Live task logs in a React Flow UI." React Flow is a library for building node-based interactive interfaces, and using it for CI logs suggests that tasks and dependencies are displayed as a visual graph, with logs attached to nodes and updated in real time. For troubleshooting questions like "why didn't this task run?" or "which upstream dependency is it stuck on?", this is far more intuitive than digging through plain-text logs.

Second, the runner's network model. Kestrix's remote runners "only make outbound HTTPS requests." This means runners don't need to open inbound ports or punch holes in firewalls — the control plane dispatches tasks and collects results through outbound connections. For teams running CI in restricted network environments or private VPCs, this is a pragmatic security design that lowers the operational barrier to deployment.

React Flow is an open-source React library for building node-based interactive canvases, supporting drag-and-drop, zooming, custom node rendering, and edge animations. It's commonly used for workflow editors, data pipeline visualization, and LLM orchestration interfaces. Using it for CI log display means each task is a canvas node, edges between nodes represent dependencies in the DAG, and log content refreshes in real time on the corresponding nodes as execution status changes. This presentation combines "execution topology" and "runtime output" in a single view, making it easier to locate blocking points and understand why a run was skipped compared to plain-text logs appended in chronological order.

Who It's For, and What Needs Verification

Based on the available information, Kestrix is best suited for engineering teams with multiple repositories, clear dependency relationships, and sensitivity to CI resource overhead. Monorepo users will see limited benefit, since there's little room to optimize trigger granularity to begin with; the more cross-repository collaboration there is, the more obvious the value of DAG plus repository-level triggers becomes.

There are also reasons for caution. The Product Hunt page only provides product positioning and mechanism descriptions — no performance data, no list of supported code hosting platforms, and no specific boundaries for concurrency and self-hosting capabilities. 68 votes and 3 comments indicate it's still in an early exposure phase with very few community validation samples. For teams considering evaluating it, three things should be confirmed first: whether it can integrate with your existing code hosting and artifact systems, how much it will cost to migrate HCL configurations, and whether the outbound HTTPS model is actually feasible under your network policies.

What's noteworthy about Kestrix's approach isn't that it's "faster" than existing CI, but that it moves the question of "should this execute?" forward into the graph's structure. If this direction proves effective, it could influence more CI products to rethink their trigger logic design.

The outbound-only HTTPS model is a security pattern increasingly adopted by remote execution agents in recent years: the agent actively establishes a TLS connection to the control plane and maintains a long-polling or WebSocket channel, with both task instructions and results transmitted over this connection. This contrasts with the traditional model — where the control plane actively connects to the runner's listening port. The advantage of the outbound model is that runners can be placed behind NAT or in strictly isolated subnets, requiring no inbound firewall rules, public IPs, or certificate exposure, significantly reducing the attack surface. GitHub Actions' self-hosted runner and GitLab Runner's polling mode use similar approaches. The cost is that the control plane must maintain a large number of long connections, and runner liveness depends on heartbeat mechanisms rather than direct probing.

One-line Summary

Kestrix uses HCL to define DAG pipelines, ensuring tasks only run when their declared repositories change.

Paragraph Summary

Kestrix is a repo-agnostic CI control plane launched on Product Hunt, with a core idea of shifting CI efficiency from "running fast" to "running only when necessary." It declares pipelines in HCL and parses them into a DAG, with task dependencies determined by the graph's topology; trigger granularity is pushed down to the task level, executing only when the repositories a task declares have changed, thereby avoiding idle runs of irrelevant pipelines in cross-repository projects. The product also offers a React Flow-based visual log interface, and remote runners only make outbound HTTPS requests to lower the barrier for deployment in restricted networks. The article concludes it's best suited for teams with multiple repositories, clear dependencies, and sensitivity to CI overhead, but its code hosting compatibility, HCL migration cost, and self-hosting capabilities still need real-world testing.