config-as-data

Store Kubernetes configuration as literal YAML in ConfigHub units via cub mutations.

2|2|Updated Apr 15, 2026
One-click install
npx skills add https://github.com/confighub/confighub-skills --skill config-as-data
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: config-as-data
Source: https://github.com/confighub/confighub-skills/tree/main/skills/config-as-data
Command: npx skills add https://github.com/confighub/confighub-skills --skill config-as-data

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Storing Kubernetes configuration in ConfigHub as fully materialized, literal YAML eliminates templating and value-file workflows, enabling deterministic mutation via cub and robust history/validation.

Core Features & Use Cases

  • Enforces configuration-as-data discipline where Units contain literal YAML and code mutates data, not templates.
  • Supports authoring new resources, migrating from Helm/Kustomize, and parameterizing configs across environments using one Space per app × environment and mutation functions.
  • Integrates with cub functions and change history to apply defaults and track revisions.

Quick Start

Create a new Unit with literal YAML for a resource and seed it from an example, then store it via cub unit create.

Frequently Asked Questions about config-as-data

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I store Kubernetes configuration as literal YAML without using templates?

You can migrate Kubernetes configurations from Helm or Kustomize by storing fully materialized, literal YAML in ConfigHub units, replacing templating workflows with deterministic cub mutations and robust history validation.

What is the best way to parameterize Kubernetes configs across multiple environments?

The best way to parameterize Kubernetes configs is using a one-space-per-app-per-env topology, applying deterministic cub mutations to literal YAML units instead of managing separate value files for each environment.

How do I create a new ConfigHub unit with literal YAML for a Kubernetes resource?

To create a new unit with literal YAML, seed your resource from an example and store it using the cub unit create command, ensuring the configuration is fully materialized for mutation-based workflows.

Does ConfigHub support migrating Kubernetes configs away from Helm and Kustomize?

Yes, ConfigHub supports migrating from Helm and Kustomize by enforcing configuration-as-data discipline, where units contain literal YAML and code mutates the data directly rather than rendering templates.

Why use cub mutations instead of Helm templates for Kubernetes configuration management?

Using cub mutations instead of Helm templates eliminates templating overhead, enabling deterministic data mutations, robust history tracking, and preflight validation gates on fully materialized literal YAML configurations.