DEV Community: Jake C

Cabure: Why did I create my own gitops tool?

Jake C — Wed, 16 Sep 2026 11:59:08 +0000

This blog will cover the decisions that lead to creating my own gitops tool and why I didn't just use ArgoCD or FluxCD.

And maybe why you should start creating your own custom tools

What is a gitops tool?

Before we start, what is a gitops tool?

A GitOps tool is software that helps you manage infrastructure and application deployments using Git as the source of truth.

The basic idea is that you store the desired configuration of your system in a Git repository. The GitOps tool continuously compares what is running with what Git says should be running. When Git changes, the tool applies those changes to the environment.

Why not using the existing tools?

Tools like ArgoCD and FluxCD are good, and you should use them in production environments - I am by no means recommending you use Cabure for production (though you can at your own risk!)

The issue I had was that it took way to long to set each up, and when you just want the gitops feel within Minikube or a homelab cluster deploying either of these is a quite a process.

They both have dozens of features, of which you probably are going to only use at most 6 (even that is being generous.) I needed something simpler, something more specific, something that fits how I want to work.

Out of this came Cabure: https://github.com/GreedyKomodoDragon/cabure

So what is Cabure?

From the README:

Cabure is a minimal GitOps operator for a single Kubernetes cluster. It watches GitApplication resources, checks out a Git repository, renders plain YAML or a local Helm chart, applies the result with Kubernetes Server-Side Apply, and prunes objects removed from Git using a stored inventory.

It does just that, no more, no less. I have no plans to do:

A web UI or public API
No MCPs
Multi-cluster management.
Kustomize, Jsonnet, CUE, or plugin-based rendering
Remote Helm values files or OCI chart sources for user applications
Cross-namespace secret access

By removing all of these features we can very easily deploy and debug the gitops process.

Its a single binary, you don't even need a PVC if you don't want to use cache.

Creating your own tools

Creating a tool that fits your exact needs almost always make it simpler to manage e.g you don't need to wrangle how ArgoCD reconciles in specific cases, you can just extend your own tool.

Drop features you don't care about anymore, open source and popular tools have to often provide backward compatibility. In your own tools you can do whatever you want.

With AI now this has become even easier, the first version of cabure was largely scoped out by AI agents and only once I understood what I wanted I took more control over it.

The real reason: Learn by making

Fundamentally I have a desire to learn how all of these tools I use everyday work. You could get an AI agent to read all of the code in that repo and get a very shallow understanding, you'd never remember what it said & likely just have wasted the tokens.

By building a vertical slice of the existing tool gives you a better understand of why tools like ArgoCD work they do. This allows you to better use those tools as well.

Even if you use AI you can still get a lot of these learnings, as long as you look at the code and review it. Which is not that different from getting code you didn't make from a colleague.

Kontroler: "DogFood" Testing

Jake C — Sun, 19 Jan 2025 22:07:23 +0000

Kontroler my latest project that’s all about workflows and now self-testing! At its core, it’s a workflow orchestration tool, but what sets it apart is how with some additional components we can being to "dogfood" the tool. In plain terms, it uses its own features to test its functionality, proving it works while continually improving itself. Pretty neat, right?

Why aim for Self-Testing the tool?

I’ve always loved automation. It’s the secret sauce behind smooth CI pipelines, quick deployments, and less developer frustration. But when I set out to build Kontroler, I didn’t just want another tool that runs workflows. I wanted something that could prove it works — without relying on third-party testing tools.

That’s where self-testing came in. It’s like giving the tool a built-in stress test. If it can handle its own workflows without breaking, you know it has some foundation we can build upon. Watching it tackle quality control all on its own is both practical and kind of satisfying.

How Kontroler Tests Itself

To get Kontroler to self-test it required building some additional components. Two new services:

A GitHub webhook listener to handling the incoming webhooks, read the infra directory and create both the Dag & DagRun.
A Kontroler webhook listener to handling outgoing events from kontroler. Kontroler can provide webhooks to listen for when a task ends, providing information such as the status and the task it links to.

As mentioned, a new directory was added to the repo called .kontrolerci that contains some yaml files that determine how the Dag/CI pipeline will work. Here is an example of how to create a simple go builder:

build-server:
  image: golang:1.23.5-bullseye
  script: |
    echo "Navigating to server directory"
    cd server
    go mod tidy
    echo "Building server application"
    go build -o main cmd/main.go

If you want to see the full directory go to the repo at: https://github.com/GreedyKomodoDragon/Kontroler

What does it test?

Currently the pipeline covers:

Installing Packages (npm, Go)
Linting (Go)
Unit testing

These tests help provide confidence in the system, and the fact the CI pipeline ran also provides a end to end test to show Kontroler is correctly allocating tasks and outputing the webhooks when required.

This is what it looks like within Github's UI:

The Fun (and Frustration) of Dogfooding

The first time it managed to get the whole way through the pipeline was a magically moment, seeing all those green ticks was more satisfying than I imagined it would be. Kontroler was really being used, even if it was just myself using it.

But, let’s be real, building something that tests itself isn’t sunshine and rainbows. There were so many issues and bugs I came across. Like trying to understanding why my client was no longer authenticating to kontroler, or why if I put something into the tmp folder the pods started exiting with errors.

But by dogfooding the tool I can now see the flaws in the tool and begin to fix them!

What’s Next for Kontroler?

There are so many things to fix & add thanks to dogfooding the tool, we are aiming to:

Allow podTemplate to be overidden at runtime, adds more flexibility to the tool which a workflow like a CI pipeline needs
Provide functionality to create PVCs within the DagRun CRD

We will continue to "dogfood" the tool and use it to further productionize the tool!

Introducing Kontroler: A Kubernetes Scheduling Engine for DAGs

Jake C — Thu, 21 Nov 2024 16:14:32 +0000

What is Kontroler?

Kontroler is an open-source Kubernetes scheduling engine designed to simplify the management of Directed Acyclic Graphs (DAGs). With Kontroler, you can define workflows in YAML, run tasks as containerized jobs, and even visualize them through an optional web-based UI. Whether you need to execute workflows on a schedule or respond to real-time events, Kontroler offers a flexible, Kubernetes-native solution.

That said, I must caveat that Kontroler is currently in its alpha state. It is ideal for experimentation and prototyping but may not yet be ready for production use. As a side project, Kontroler does not come with support, so use it in production at your own risk!

If you'd like to check out the GitHub repository, here it is: https://github.com/GreedyKomodoDragon/Kontroler

Why use Kontroler?

Managing workflows on Kubernetes can be challenging. While Kubernetes offers powerful primitives like CronJobs and Jobs, coordinating complex workflows with dependencies, retries, and dynamic triggers often requires custom scripts or external tools. Kontroler simplifies this process by providing a Kubernetes-native solution to define, schedule, and manage workflows as Directed Acyclic Graphs (DAGs).

Here’s what makes Kontroler stand out:

1. Gitops DAG Management with YAML

Kontroler enables you to define your entire workflow—including tasks, dependencies, retry logic, and conditional execution—using straightforward YAML files. This approach keeps your workflows declarative, version-controlled, and easy to share across teams.

Wrap them in a Helm chart and use an automated deployment system such as ArgoCD or FluxCD, and you’ve got your DAGs managed within a GitOps workflow.

2. Supports Event-Driven and Scheduled Workflows

Whether you need workflows to run on a regular schedule (like CronJobs) or react to real-time triggers (such as a message from a queue), Kontroler has you covered. It seamlessly integrates both scheduling paradigms, making it versatile for a wide range of use cases.

Kontroler operates using DagRuns (a Custom Resource Definition, or CRD, that Kontroler can monitor). To execute a DAG run, you simply create a DagRun, and Kontroler manages the execution. By exposing this functionality outside the controller, Kontroler allows seamless integration with external systems. See an example of a DagRun below:

apiVersion: kontroler.greedykomodo/v1alpha1
kind: DagRun
metadata:
  labels:
    app.kubernetes.io/name: dagrun
    app.kubernetes.io/instance: dagrun-sample
  name: dagrun-sample
spec:
  dagName: dag-sample
  parameters:
    - name: first
      fromSecret: secret-name-new
    - name: second
      value: value_new

You simply provide the name of the DAG, optionally including any parameters. Parameters will use their default values if none are specified.

3. Integrates Seamlessly with Containers

As a Kubernetes-native application, Kontroler leverages the platform’s advantages. From simple scripts to complex applications, Kontroler’s container-first design ensures that any workload can be easily integrated into a DAG.

To further reduce duplication of effort, we are adding support for Tasks as CRDs.

4. Offers Optional UI for Better Visibility

While YAML is excellent for infrastructure as code, visualizing workflows and tracking their execution can significantly simplify debugging and optimization. Kontroler offers an optional web-based UI for creating and monitoring DAGs, providing teams with an intuitive way to manage workflows.

In the screenshot above it shows you the:

Connections between tasks
In a DagRun it will show the status
Pod Outcomes if you click on the network

Under the hood, this functionality is powered by vis-network, an open-source project for creating graphs. You can find their GitHub repository here. Initially, we developed our own graphing tool but found it difficult to scale and challenging to make complex graphs readable. As a result, we adopted this open-source solution.

5. Flexible Pod Templates for Advanced Configurations

Kontroler’s pod templates let you customize your tasks with advanced Kubernetes features like secrets, PVCs, node affinity, security contexts, and more. This gives you fine-grained control over how tasks are executed, ensuring compatibility with your cluster's specific requirements.

Flexibility of Datastores

One of the key challenges in managing workflows is ensuring that the underlying infrastructure can scale with your needs. Kontroler offers flexible database support and logging capabilities to make it easier for teams to manage DAGs and capture detailed execution logs. Whether you're working with a lightweight setup or a more robust production environment, Kontroler has options that can fit your needs.

SQLite (Default + Small Scale)

For smaller setups or during development, SQLite is the default database used by Kontroler. It’s simple, lightweight, and doesn’t require much configuration. If you’re just getting started or running Kontroler for testing purposes, SQLite is a convenient choice as it works "out-of-the-box" with no additional database setup.

If you prefer to use SQLite, you don’t need to make any additional changes to the deployment. Just follow the installation instructions, and Kontroler will handle the rest.

PostgreSQL (For Production/Large Scale)

For larger, production-grade deployments, PostgreSQL is the recommended database for storing DAGs and DagRuns. Kontroler uses PostgreSQL to provide higher performance, scalability, and reliability needed for handling large volumes of workflow data. Kontroler is compatible with PostgreSQL 16 and above

Log Collection

For many Kubernetes users, centralized log storage is a crucial requirement for observability and troubleshooting. Kontroler integrates seamlessly with Amazon S3 for log storage, making it easy to collect, store, and analyze logs from DAG executions. This integration ensures that you can capture detailed logs, keep them long-term for auditing, and use them for post-mortem analysis when something goes wrong.

We are testing with MinIO to avoid costs, but under the hood, it uses the AWS S3 API and should be able to detect your IAM attributes to grant access to your S3 buckets.

Final Remarks

We hope you’ll check out Kontroler! You can find it here: https://github.com/GreedyKomodoDragon/Kontroler.

Although still in alpha, Kontroler has significant potential for teams looking to streamline their Kubernetes operations. As it evolves, Kontroler aims to become a powerful tool for orchestrating workflows in Kubernetes, delivering the reliability and scalability teams need to automate complex processes with ease.

Kontroler is constantly improving, so keep an eye out for future updates! If you’d like to contribute to the project, we welcome all forms of contributions.