DEV Community: Bogdan “Bodo” Dumitrescu

Managing Kubernetes Manifests as Pure Data with Hull

Bogdan “Bodo” Dumitrescu — Wed, 08 Jul 2026 14:17:39 +0000

If you’ve spent enough time managing Kubernetes deployments, you’ve likely hit the configuration wall. You start with standard YAML, realize you need different values for dev and prod, and reach for Kustomize or Helm.

Fast forward six months, and you are trapped in one of two nightmares: either you are maintaining a sprawling directory tree of overlays/ just to patch a single image tag in Kustomize, or you are deeply nested in Helm template spaghetti, debugging a malformed manifest because a Go-template {{ if }} block missed a single whitespace indentation.

Kubernetes manifests are structured data. Yet, our standard industry tools either treat them as raw text strings to be chopped up (Helm) or as rigid objects requiring layers of external patch files (Kustomize).

Hull is an open-source Kubernetes package manager that takes a completely different approach: it treats YAML as a native AST (Abstract Syntax Tree), utilizes clean inline expression templating, and centralizes environment configuration to eliminate both Kustomize overlays and Helm text templating.

Here is a hands-on look at how to build a multi-environment deployment without the traditional boilerplate.

1. Getting Started

Hull is a single Go binary. You can install it directly via:

go install github.com/ebogdum/hull/cmd/hull@latest

Let's scaffold a new package to see how the architecture compares:

hull create my-api && cd my-api

This generates three core components:

hull.yaml: The orchestrator (defines environments, inheritance, and dependencies).
values.yaml: Your default configuration schema.
templates/: The actual Kubernetes manifests.

2. Centralizing Environments (Killing Kustomize Overlays)

In Kustomize, setting up dev and prod requires building out a directory tree with a base/ directory, an overlays/dev/ directory, and an overlays/prod/ directory—each containing its own kustomization.yaml and distinct patch files.

In Hull, this environment topology lives entirely within a single orchestrator file: hull.yaml.

apiVersion: hull/v1
name: my-api
version: 1.0.0

environments:
  dev:
    namespace: api-dev
    values:
      replicas: 1
      image:
        tag: "latest"

  prod:
    # Inheriting dev pulls in its configuration as a baseline.
    inherits: dev
    namespace: api-prod
    values:
      replicas: 3
      image:
        tag: "v1.4.2"

Because prod explicitly inherits from dev, you only define the keys that actually change. When you target an environment, Hull resolves these blocks deterministically as data before rendering anything.

3. Inline Variables (Killing Helm Template Spaghetti)

Helm forces you to wrap text strings in Go-template syntax, which easily breaks indentation or fails silently if an object isn't completely defined. Hull evaluates expressions directly against the parsed YAML tree using ${...} syntax.

Open templates/deployment.yaml to see how clean the context injection looks:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ${name}
spec:
  replicas: ${replicas}
  selector:
    matchLabels:
      app: ${name}
  template:
    metadata:
      labels:
        app: ${name}
    spec:
      containers:
        - name: app
          image: ${image.repository}:${image.tag}
          ports:
            - containerPort: 8080

          # Control flow is handled natively as actual YAML keys
          $if: ${features.cacheEnabled}
          env:
            - name: REDIS_HOST
              value: redis-cache

Because $if is a native YAML key and the ${...} expressions are evaluated safely against the parsed tree, your output is structurally guaranteed to be valid YAML. You completely avoid the risk of emitting broken whitespace or malformed text blocks.

4. Debugging the Configuration Spaghetti

One of the hardest parts of layered configuration in both Helm and Kustomize is figuring out where a final value actually originated. Did replicas get set by the base chart defaults, an inherited value file, a specific environment override, or a runtime CLI flag?

Hull includes a trace command built specifically to map out this resolution path:

hull values . --env prod --trace

The output points directly to the exact file or structural block that won the evaluation:

replicas: 3                     # source: environments.prod.values (hull.yaml)
image:
  repository: myorg/webapp      # source: values.yaml (package default)
  tag: v1.4.2                   # source: environments.prod.values (hull.yaml)

5. Native State Tracking and Drift Detection

Kustomize relies entirely on piping raw text output to kubectl apply, meaning it has no concept of what is actually happening inside your cluster over time. Helm tracks state using internal Secrets, but doesn't natively reconcile changes made out-of-band.

Hull acts as a full deployment engine that actively tracks cluster state. Install your package directly with:

hull install my-api . --env prod --create-namespace

Hull stamps resources with strict ownership metadata (managedBy=hull) and stores the exact rendered manifest. If a developer later bypasses GitOps or CI/CD and manually modifies the cluster—such as running kubectl scale deploy my-api --replicas=10—you can catch it instantly:

hull drift my-api

Hull evaluates the live cluster state against the stored release and reports the precise structural diff. To bring the cluster back to your declared state, a single command handles it:

hull reconcile my-api

The Takeaway

If you are tired of maintaining complex, deep directory structures in Kustomize or fighting whitespace bugs in Helm, Hull offers a clean, data-driven architecture. By replacing text-replacement and patch-files with native YAML AST handling and deterministic environment inheritance, it drastically simplifies how multi-environment Kubernetes setups are managed.

The project is fully open-source under the MIT license. Explore the documentation, OCI distribution features, and GitOps workflows over on GitHub: ebogdum/hull.

Zephyr Events – A 2KB TypeScript event emitter that's race-condition safe

Bogdan “Bodo” Dumitrescu — Tue, 07 Apr 2026 22:37:14 +0000

I built a tiny event emitter that fixes a bug most people don't know they have: if a handler calls off() on itself during emit, the next handler gets skipped. EventEmitter3, Node's built-in EventEmitter, and mitt all have this problem.

Zephyr Events uses snapshot-based iteration so handlers can subscribe, unsubscribe, or clear listeners mid-emit without side effects. If you don't need that safety, there's a zephyrEventsFast mode that's up to 82% faster.

1.9KB, zero dependencies, tree-shakeable
Full TypeScript generics with strict handler signatures
Wildcard listeners, shared handler maps, unsubscribe functions
ESM, CommonJS, and UMD builds

import zephyrEvents from 'zephyr-events';

type Events = {
  'user:login': { id: number; name: string }
  'error': Error
}

const emitter = zephyrEvents<Events>();
const unsub = emitter.on('user:login', (user) => {
  console.log(`Welcome, ${user.name}`);
});
emitter.emit('user:login', { id: 1, name: 'Alice' });
unsub();

https://www.npmjs.com/package/zephyr-events
Would love feedback, especially on the API design and whether the safe/fast split makes sense as a default.

Stop Wrestling with Config Files: A DevOps Guide to Sanity with Konfigo

Bogdan “Bodo” Dumitrescu — Mon, 30 Jun 2025 07:53:57 +0000

As a DevOps engineer, you've probably felt the pain of managing configuration files. You've got JSON, YAML, TOML, .env files, and maybe even some custom formats you'd rather not talk about. You're juggling configs for different environments (dev, staging, prod), and trying to keep everything in sync is a nightmare. What if I told you there's a better way?

Enter Konfigo, a powerful command-line tool that's about to become your new best friend.

What is Konfigo? 🤔

Konfigo is a versatile configuration management tool that helps you streamline your entire configuration workflow. It reads various configuration file formats, merges them intelligently, and processes the combined data against a user-defined schema for validation, transformation, and even batch output generation.

Think of it as a Swiss Army knife for your configuration files. 🇨🇭

Here are some of the key features that make Konfigo a game-changer for DevOps:

Multi-Format Support: JSON, YAML, TOML, and .env files are all supported. No more converting files by hand!
Flexible Merging: Intelligently merges multiple configuration sources, respecting order and immutability rules.
Powerful Schema Processing:
- Variable Substitution: Inject dynamic values from environment variables, dedicated variable files, or schema defaults.
- Data Generation: Create new configuration values (e.g., concat, timestamp, random, id).
- Data Transformation: Modify keys and values (e.g., renameKey, changeCase, addKeyPrefix, addKeySuffix, deleteKey, trim, replaceKey, setValue).
- Data Validation: Enforce rules (required, type, min, max, minLength, enum, regex).
Batch Processing: Use the konfigo_forEach directive in a variables file to generate multiple tailored configuration outputs from a single schema and run.
Environment Variable Integration: Override any configuration value directly using environment variables.

Why Should a DevOps Person Care? 🤷‍♀️

Okay, so Konfigo has a lot of features. But how does it actually make your life easier?

Tame the Multi-Headed Hydra of Configuration Formats

Let's say you have a base configuration in YAML, but your production environment requires some overrides from a .env file. With Konfigo, you can merge them with a single command:

konfigo -s base.yaml,prod.env -oy

No more writing custom scripts to parse and merge different formats. Konfigo handles it all for you.

Automate Your Configuration Workflow

You can integrate Konfigo into your CI/CD pipelines to generate environment-specific configurations on the fly. For example, you can have a base configuration and then apply environment-specific overrides from different files.

Here's a conceptual example of how you might use Konfigo in a CI/CD pipeline:

- name: Generate production config
  run: konfigo -s config.yaml,overrides/production.yaml -of generated/config.production.json
- name: Deploy to production
  run: ./deploy.sh generated/config.production.json

Prevent Configuration Drift

Configuration drift is a major source of headaches in any infrastructure. With Konfigo's schema validation, you can enforce a consistent structure and set of rules for your configurations.

For example, you can create a schema that requires a specific key to be present, or that a value must be a number within a certain range. If a configuration doesn't match the schema, Konfigo will throw an error, and you can catch the problem before it ever reaches production.

Dynamic Configurations are Your Friend

Stop hardcoding values in your configuration files! With Konfigo, you can use variables and data generation to create dynamic configurations.

For example, you can use an environment variable to set the database host, or you can use the timestamp generator to add a build timestamp to your configuration.

konfigo -s config.json -S schema.yml -V staging-vars.yml -of staging_config.json

Simplify Complex Setups

If you're managing configurations for a microservices architecture or a multi-tenant application, you know how complex it can get. Konfigo's batch processing feature can help you simplify this.

You can create a template configuration and then use a variables file to generate multiple tailored configurations for each service or tenant.

A Simple Example

Let's look at a simple example of how Konfigo can be used to validate and transform a configuration file.

Input (config.json):

{
  "database": {
    "host": "localhost",
    "port": 5432
  },
  "feature_flags": {
    "new_dashboard": true
  }
}

Schema (schema.yaml):

schema:
  properties:
    database:
      properties:
        host:
          type: string
        port:
          type: integer
          validation:
            - type: min
              value: 1024
    feature_flags:
      properties:
        new_dashboard:
          type: boolean
  transformations:
    - type: addKeyPrefix
      path: database
      value: db_
  required:
    - database

Command:

konfigo -s config.json -S schema.yaml -oj

Output:

{
  "db_database": {
    "host": "localhost",
    "port": 5432
  },
  "feature_flags": {
    "new_dashboard": true
  }
}

In this example, Konfigo does two things:

Validates the input to ensure that database.port is at least 1024.
Transforms the input by adding the prefix db_ to the database key.

Ready to Give it a Try? 🚀

I've only scratched the surface of what Konfigo can do. If you're tired of wrestling with configuration files, I highly recommend giving it a try.

Download Konfigo
Read the Docs

Let me know what you think in the comments below! 👇