bitnami/nginx

What this page gives you

Every chart page follows the same order. Choose a configuration, inspect its objects and setup work, then read the tests that have run. Open the worked examples.

What To Use

http-clusterip configuration: 5 rendered objects · 1 image · 0 target prerequisites · 0 hook or setup routes · 5/5 checks passing. These counts come from the linked test records.

Use the public catalog entry, then check the exact configuration and its tests before making a production claim.

Four Separate Questions

Inspecting a source, producing objects, checking a destination, and checking a live result are different jobs. A Catalog match is useful for comparison but is not required. A missing destination or deployment is shown as not run or blocked, not as a failed configuration.

Open the complete assessment, source, lifecycle, and evidence record.

Where This Chart's Settings Come From

Upgrade rule: if a new Helm render and a ConfigHub revision both change the same field, review the overlap before promotion. The values profile shows the Helm side; Unit revision history shows the ConfigHub side.

Read the full values-versus-ConfigHub rule. For the staging commands behind each prerequisite, open the prerequisite action packets.

What This Chart Contains

Shipping a chart as plain rendered YAML is faster and simpler, and it silently drops anything Helm was going to do afterwards. This section reports what a scan of the packaged chart found, across 47 files.

A flattening-safety verdict has decided this version: default:unsafe-to-flatten; existing-tls-ingress:unsafe-to-flatten; http-clusterip:unsafe-to-flatten. The verdict records one disposition per construct and names any companion artifact a flattened bundle must ship.

A construct being present does not make a chart unflattenable. Most are switched on or off by values, and a verdict records which ones the base you choose actually reaches. Read the catalog-wide evidence for how common each one is.

What The Starting Configuration Records

A base variant is a starting configuration we have already rendered and checked. Pick the one whose trade-off you want; the table below shows what each one changes. How the values for each are chosen.

The http-clusterip base-variant record connects those Helm inputs to the Kubernetes objects, remaining requirements, hooks, CRDs, checks, and OCI status. Open it when you need the complete starting record rather than only the rendered YAML.

Open the full rendered YAML to read the actual manifest output. The render record and setup section explain the inputs, tests, CRDs, hooks, and other work around it.

If new Helm values create a useful starting configuration, record another base variant with its own inputs and checks. If one environment changes a field after rendering, record that change in a ConfigHub variant.

How render intents work · All generated render intents · All base variant records

Try This Chart

Start with http-clusterip. If a card says review or preparation is needed, treat that as a real limit rather than a ready install.

cub installer inspect oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-nginx:24.0.2@sha256:7cf08c0348a32d577ffa0e16069ec6c2510ce773b372008d25b938f9546c5f67 --json

cub installer pull 'oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-nginx:24.0.2@sha256:7cf08c0348a32d577ffa0e16069ec6c2510ce773b372008d25b938f9546c5f67' --work-dir ./package-review
less ./package-review/package/records/README.md

cosign verify --certificate-identity helm-expt-package-signer@nth-fort-499605-q5.iam.gserviceaccount.com --certificate-oidc-issuer https://accounts.google.com --annotations confighub.com/package-path=packages/bitnami/nginx/24.0.2 --annotations confighub.com/package-sha256=9905c5ba5f0b0187f5d22b7f4113856635476bb081d584b36251f5513b010414 europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-nginx:24.0.2@sha256:7cf08c0348a32d577ffa0e16069ec6c2510ce773b372008d25b938f9546c5f67

cub installer setup ...
rendered manifests written under <work-dir>
use the chart option cards below to check pass, watch, blocked, and prerequisites

After You Render It

The first command writes files and does not apply them. Read the objects and setup requirements, then choose the next job.

Bring Your Own Values

This worked example starts with a NGINX values file supplied by a person or coding agent. The requested change is three replicas. The same file also embeds an API key, removes the checked image digest, exposes a public LoadBalancer, and weakens three container security settings.

The review keeps the three replicas, restores the checked settings, and changes the Deployment to use an existing Secret. The proof freshly renders the locked chart, matches the catalog baseline, reports the six intended findings, packages the five reviewed objects as OCI, pulls them anonymously, and imports the same object set into ConfigHub. A live run then deploys that result through Argo CD. Development changes to four replicas, ConfigHub promotes the change to staging, and a second live run reaches 4/4 ready replicas.

Repeat the local proof with HELM_EXPT_ALLOW_BYO_HELM_VALUES_PROOF=1 npm run byo-helm-values:run.

Available Configurations

Each card is one available way to use this chart in the catalog. Some cards are runnable base variants. Others are candidate paths, derived variants, or review notes that explain what still has to be prepared.

Checks: Each card names what was checked and says whether it passed, needs review, was blocked, was not run, or was not needed.

5 matrix rows for bitnami/nginx@24.0.2 · open the full matrix

Local Configuration Checks

We ran cub check v0.7.3 against the exact rendered objects for every configuration below. The result is advisory: read each finding and decide whether it matters for your target.

What this does not check: hook execution, CRD readiness, target Secrets and cloud services, admission behavior, workload health, or rollback. The linked Catalog review covers chart-specific source and operating questions. ConfigHub validation and approval are separate managed controls.

Read all shared check results and the mapping to Catalog rules.

From a finding to a retained decision

A worked configuration for this chart starts with AI-written values. It records what each local finding meant, the fixes that were accepted, and one remaining emptyDir finding that is allowed only for an exact development and staging test.

The reviewed objects, decision, ConfigHub validation, approval, promotion, and Argo CD results remain separate records. That makes it clear which checks were local advice, which controls ConfigHub evaluated, and which targets actually ran.

Read the complete worked decision · Open the decision schema

Images This Chart Pulls

Every reference below comes from the reviewed rendered output. What you see is what the cluster pulls. These references are data: you can change a registry or pin a digest with a recorded edit, and prove the change landed in every environment.

First-Run Caveats

Some chart paths need a small preparation step before the cub path feels as smooth as Helm. We show those steps here so the first run does not surprise you.

Open the all-chart adoption caveats · Helm to cub migration · cub deployment path

Advice And Current Status

Use this section to see which chart-specific guides apply, what you must provide, and what work remains.

The source data lives in chart skills and chart evidence router.

What Has Been Tested

Choose the question you care about. Not checked means this catalog has no version-specific result; it is not a pass.

How much is proven, and what more testing would add: Fully proven: Render parity, ConfigHub proof, Local live, GitOps/OCI live, Live Helm-vs-ConfigHub. Not yet tested: Two-cluster kind - a fresh cluster run would prove these.

What We Tested On A Cluster

This is the result of a real run for one base variant on one recorded target setup. It does not silently extend the result to other bases or clusters.

What You Must Provide

exact rendered objects with render parity and receipts; generated Secrets separated out of the published artifact; optional chart inputs handled by reviewed base configurations; install-vs-upgrade render divergence captured per revision; cluster lookups lifted into declared target facts

Hooks, CRDs, And Setup Work

Some Helm charts need work before, during, or after apply: CRDs, hooks, setup jobs, webhook certificates, migrations, generated Secrets, or checks. For each chart, the catalog should make the choice clear: include it in the base variant, split it into a separate base variant, run a setup step, use a GitOps action where evidence exists, require an existing target resource, or block it when there is no safe default.

What each base needs before apply

These requirements come from the same base definition as the rendered objects. The render intent keeps the chart inputs, required Secrets or CRDs, lifecycle routes, and evidence together.

If no route is shown, that does not prove the upstream chart has no hooks. It means the public catalog has no chart-specific action to show yet; check the matrix or send a problem chart if hook behavior should be modeled. Direct apply, Argo CD, Flux, and upgrade implementations are tracked separately. One passing implementation does not prove the others.

Before Production

A green render or local live result is not a production support claim. Production support is target-scoped and uses the support-decision artifact when present.

Source And Evidence Files