Find a starting configuration

1. What do you need?

Read the result before choosing an example

An example may answer only one or two questions. Later stages remain blocked or not run until their required input exists.

Choose the closest job. Each link opens a tested starting point or the shortest current path to one.

Missing the component or use case you need? Tell us what you are trying to run.

Six worked examples

Choose the question closest to yours. Each example links the result to the files and evidence that support it.

2. Try a simple example: Redis

See what Redis installs, before you install it

Turn the published Redis package into the exact Kubernetes files it produces. You need no account, no login, and no cluster.

$ cub installer setup \
    --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:25.5.3@sha256:a216ce212424e05b341ef5000f1798e6014b72b8bc3dce9f315285871037af2a \
    --base reuse-existing-secret \
    --work-dir ./redis \
    --non-interactive \
    --namespace redis

Base: reuse-existing-secret; components: []
Namespace: redis
Rendered 14 manifest(s) to ./redis/out/manifests
Rendered 0 secret(s)

Read the 14 files in ./redis/out/manifests. The package holds no password. You supply the Secret redis/redis-existing-secret yourself.

These 14 files were checked against Helm's own output and matched. See the detailed Redis walkthrough for the recorded parity, upgrade, and rollback evidence.

To keep an edit to the files as well, the same objects go into ConfigHub. There you change a value, move it from development to staging, and roll it back. Keep the result in ConfigHub.

If you do not want Redis, choose the input you have below. Every path ends with exact files and a checked result.

Each example includes the source files and the evidence behind its result.

Get inference running

Choose the row that answers your immediate question. The first path runs a model on ordinary ARM64 hardware. The later paths explain larger AI platforms without claiming that their GPU workloads have run here.

Review an AI agent fleet before it runs

An agent service has settings for its model, runtime images, budget, concurrency, credentials, storage, and access. The c3agent example turns those choices into ten exact Kubernetes objects without storing a credential or starting the service.

The recorded test kept one base configuration. It changed only the fleet settings for staging and production. The accepted result was promoted, published as OCI, and reconciled by Argo CD on Kubernetes. Both Deployments stayed at zero replicas. This proves the configuration and delivery path, not the private c3agent runtime or an agent task.

Read the c3agent walkthrough · Open the source files · Check the live proof

Bring your own Helm chart and values

Render your own chart with cub helm template, check the exact objects on Check my config, then keep the result as files, as OCI, or in ConfigHub with cub helm install. See the four paths for a chart the catalog does not have, and where each setting belongs. The worked NGINX review starts with AI-written values, keeps the requested replica count, and corrects six settings before deployment.

3. Choose how to run a starting example

Local or CI — available now

Use public tools and packages without ConfigHub Server or an account. Public catalog packages also need no Google registry login.

Hosted without sign-in — available for rendered YAML

Check my config can inventory and compare rendered Kubernetes YAML in your browser. The files are not uploaded. It does not render a chart, pull OCI, contact Kubernetes, or run live tests.

ConfigHub — available now

Save the reviewed objects and work with a team. An account is required. Follow the official tutorial.

These three choices apply to starting examples. The examples below use ConfigHub Server because their job is to manage saved configuration.

4. Continue in ConfigHub

ConfigHub keeps reviewed Kubernetes configuration as shared data. Teams can change it, approve it, promote it, and publish releases for deployment.

5. Build or roll out a platform

Build a small Kubara platform from tested Catalog components. Choose services, record optional digest-pinned runtime images, and review the native Kubara config before generation. The advanced examples below continue into ConfigHub and a fleet.

A platform team runs the same components on many clusters. Tools like Kubara and Sveltos build these platforms. Sveltos installs one component across a group of clusters. Kubara describes a whole platform at once and generates its files.

ConfigHub does the same job for both. It stores the result, checks it, and moves a change from one environment to the next. You cannot run a whole fleet in a web page, so each row links a walkthrough and the recorded evidence.

An internal developer platform with apps on it

ConfigHub simplifies Kubara without making it fundamentally different. Kubara's catalogs, config.yaml, values overlays, generated components, and hub-and-spoke model remain recognizable. ConfigHub adds exact component retention, semantic review, approvals, promotion, rollback, a component-by-cluster matrix with explicit live or unknown state, and visible wiring. Argo CD still reconciles.

The current Kubara source selects seven platform roles across one hub and three spokes. The Kubara page holds the architecture, the exact observation boundaries, and what the receipts do and do not prove.

Start with the Kubara buyer journey · Follow the six-step tutorial · Open the matrix and wiring evidence.

6. Use saved configuration for a repeated job

Each row has a working example. The final column says what is still needed before the same result can be offered more generally.

Read how Apps use saved configuration.