NGINX delivered from one ConfigHub release OCI

A repository document, rendered for the site. View source markdown.

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

UNOFFICIAL/EXPERIMENTAL. Generated from the committed live receipt. Regenerate this page with npm run catalog-oci:proof:generate; rerun the cluster test with npm run catalog-oci:proof.

This test used the real bitnami/nginx@24.0.2 http-clusterip catalog base. cub installer pulled the public package, selected that base, and reproduced the committed Kubernetes objects. ConfigHub then published those objects once as a release OCI.

Argo CD, Flux, and direct apply consumed that release in sequence on one throwaway cluster. All three reported the same OCI digest and reached a ready NGINX Deployment and ClusterIP Service.

Delivery methodSourceOCI digestNGINX replicasServiceResult
Argo CDOCI Applicationsha256:26d97438d5b52dcacf140d2ef4c57a97bacd0c63e22d5cfa19076a0723b730491/1ClusterIPpass
FluxOCIRepository and Kustomizationsha256:26d97438d5b52dcacf140d2ef4c57a97bacd0c63e22d5cfa19076a0723b730491/1ClusterIPpass
Direct applyoras pull and kubectl applysha256:26d97438d5b52dcacf140d2ef4c57a97bacd0c63e22d5cfa19076a0723b730491/1ClusterIPpass

Overall: pass. Rendered objects: 6. Published Units: 6. Cleanup: namespace pass, ConfigHub Space pass, rig pass.

This proves one catalog configuration on the recorded target. It does not prove another chart, base, Kubernetes version, or production cluster. The scratch organization did not run the helm-catalog apply-policy Triggers, so policy and delivery remain separate claims.