ConfigHub Examples

Learn what an application looks like in ConfigHub, make a useful configuration change, and understand how that change reaches your delivery system.

Start with your app

What you want to learn	Start here	What you get
What would my app look like?	First app	A frontend, backend and database; one local replica change; an optional, separately verified ConfigHub storage walkthrough. No cluster required for the local lesson.
How would I organise a smaller app?	Layered applications	Choose one component, an app with a database, or a three-component app. See how shared configuration becomes environment-specific configuration.
How does this fit my existing Argo CD or Flux repository?	GitOps examples	Repository shapes and controller-specific guides. Read the selected guide's prerequisites before running it.
Can I manage app settings without Kubernetes?	App-only configuration	Provider and channel settings with source provenance, maintained beside the generator. Local configuration output does not prove an update to the provider.
How can I build an app that uses ConfigHub's API?	SDK browser examples	A small developer example in the SDK's canonical home; authentication and setup are separate from the first-app lesson.

The collection contains both applications whose configuration you manage (such as the first app) and tools built on ConfigHub (such as ConfigBoard and the fleet managers below). Shared libraries and diagnostic fixtures are supporting material, not additional tutorials. Each guide states its own requirements and proof limits; inclusion here is not a claim that every example has been deployed.

Safe First Checks

These checks do not change ConfigHub or cluster resources. The repository verifier runs local tests and checks example contracts.

./scripts/verify.sh
cub context list --json
cub space list --json
cub target list --space "*" --json

If you are not logged in yet, run cub auth login before the cub commands.

Stable Paths

• catalog: search public example guides by user task, with machine-readable status, safe preview and evidence limits. Use node scripts/examples-catalog.mjs search 'existing Argo repository' --json.
• What an app looks like: follow a three-component sample from source manifests to planned ConfigHub Units and delivery boundaries.
• gitops: index of canonical Argo CD and Flux example repo shapes, by tool and skill level. Start here if you run Argo CD or Flux and want an example that looks like your repo.
• promotion-demo-data: quickest no-cluster demo data for learning ConfigHub's App-Deployment-Target model and promotion flow.
• initiatives-demo: 5 compliance initiatives backed by Kyverno CEL policies, with sample Kubernetes units to evaluate.
• custom-workers: worker extension examples, including bridge, function, and policy workers.
• pilot-example-addons-manager: standalone generated operational app with Variant-first GUI, CLI sibling, production ConfigHub browser OAuth registration, and live-binding proof gates.
• cost-management-app: generated operational app with a real cost engine: org-wide waste findings priced from config data, then a finding-owned dry run, short-lived exact review, explicit execution confirmation, revision-verified mutation, and receipt. The reduction plane beside cost-estimator's enforcement plane.
• configboard: BI-style dashboards over the configuration in your organization — what version of what is where, which guardrails are failing, how many resources you manage, how long changes take to land. Read-only and seeds nothing. Dashboards are AppConfig/YAML units, so they carry revision history and promote like any other config, and every panel prints its equivalent cub command. Includes a 3-minute silent demo video and transcript.

Recommended Starting Points

• If you want to explore Initiatives and compliance workflows, start with initiatives-demo.
• If you want the quickest no-cluster path, start with promotion-demo-data.
• If you want to understand Generators as functions on config data, start with spring-platform, then move to cub-gen/examples/springboot-paas for the product path, including the Spring ConfigHub Initiative GUI proof.
• If you want to deploy to a cluster, see the GitOps operators guide — configuration is published as an OCI Release that Argo CD or Flux pulls.
• If you want to see the state of an existing organization at a glance, start with configboard — it seeds nothing, and its demo video covers the six bundled dashboards in three minutes.
• If you want worker extensibility, start with custom-workers.

Note on contract standard: EXAMPLE_CONTRACT_STANDARD.md

Examples across repositories

The example landscape review maps the non-GitOps families, related examples maintained with their products, and the checks needed before moving an example here. It records source inspection, not fresh runtime qualification.

Companion Material

Some other examples

• Fleet guardrails that analyze config, record a verdict as data, and gate apply on it: sec-scanner (container CVEs), rbac-manager (RBAC hygiene), and cost-estimator (workload cloud cost); the cost reduction counterpart is cost-management-app.
• Agentic RBAC companion patterns: rbac-manager-for-agents, rbac-manager-over-redis, and redis-platform-with-rbac-guardrails
• Agent-driven fleet managers — each a cub-* CLI that manages one domain of Kubernetes config as data across a fleet of cluster-Spaces, siblings of rbac-manager-for-agents: workload-manager (workload security and reliability posture: security context, resources, probes, PDBs), namespace-manager (namespaces and their policy envelope: pod-security labels, default-deny NetworkPolicy, baseline RBAC), network-policy-manager (NetworkPolicy, reasoned about with the Namespaces, workloads, and Services it covers), scheduling-manager (workload placement: nodeSelector, tolerations, node affinity), autoscale-manager (autoscaling: HorizontalPodAutoscalers and KEDA ScaledObjects), observability-manager (observability posture: Prometheus ServiceMonitor coverage and telemetry sidecar injection), and eks-manager (AWS EKS clusters as Crossplane managed resources)
• Platform view builders — read the config data in a Space and project it into a different platform representation: k8s-to-score reads the Kubernetes resources in a Space and emits a Score workload spec per Deployment or StatefulSet (the inverse of score-k8s; read-only)
• Shared libraries the examples are built on, rather than examples themselves: webkit — the auth shell, fleet scope and snapshot, config-data access, and RBAC engine behind the web consoles (configboard, promoter, rbac-manager, sec-scanner, fleet-ql, and cost-estimator) — and managerkit, the guardrail policy pack the cub-* fleet managers share. What those managers used to share for reading a fleet and for the command line is now in the Go SDK itself — core/cubapi (SnapshotLoader, MemoizedClient) and cliutil (QueryFlags and the output helpers). The ConfigHub API client and auth flow themselves are not here: those are the published @confighub/api, @confighub/rtk-query, and @confighub/react-auth packages from confighub/js-sdk.
• Prompts you can run against your own repository with an AI tool, no account needed: prompts/README.md
• Layered recipes, from one component to an AICR-shaped GPU stack: global-app-layer
• App mutation and platform flow: spring-platform/springboot-platform-app-centric
• Standalone operational app shape: pilot-example-addons-manager

cub-scout remains useful as companion material and as a source of comparison fixtures:

• cub-scout examples index
• Apptique microservice examples