Helm components

ZopDay ships with a curated Helm component catalogue you can install onto any registered Kubernetes deployment space in one click. Each component is tested, version-pinned, and configured with sensible defaults, so you can add monitoring or ingress to a fresh cluster without writing the YAML yourself. VM spaces have their own, separate catalogue of script-installed components (Docker, Caddy, scale to zero, and the observability agent); see Deploy to a VM.

Before you start

An active registered Kubernetes space. See Cluster registration or Provisioning clusters.
The service:* policies, which cover in-cluster Helm components. See RBAC.
For the API calls on this page, a Personal Access Token (see Authentication).

How it works

ZopDay serves the component catalogue itself. The catalogue lists what can be installed, not what is installed on a given cluster; each install and upgrade is recorded as its own action on the space.

What installs, and when

When ZopDay provisions a cluster, the components you pick in the Provision drawer’s Advanced settings → Components tab install once the provisioning job completes. Nothing installs at that point if you pick none.

Before the first service deploys to any Kubernetes space, whether ZopDay provisioned it or you registered it via Cluster registration, ZopDay installs whatever is missing from the baseline the service chart needs:

Component	Purpose
NGINX Ingress Controller (`ingress-nginx`)	Routes external traffic to cluster services through a cloud load balancer
Cert Manager (`cert-manager`)	Automated TLS certificates with Let’s Encrypt
Prometheus Stack (`prometheus`)	Monitoring, alerting, and Grafana dashboards
Cluster Autoscaler and EBS CSI Driver	AWS only

Everything else in the catalogue is opt-in.

How installs run

Each component install and each upgrade runs as its own logged, retryable action, not as a provisioning job. On a cluster ZopDay provisions, the components you picked install right after the provisioning job completes. ZopDay mints a short-lived kubeconfig for the install and holds no standing credentials on the cluster.

Install time varies by component and is typically 1–5 minutes. Components with admission webhooks are usually slower, because the install waits until the API server can reach the webhook.

Browse the catalogue

GET /orgs/{orgID}/components

This returns the full catalogue with the fields in Catalogue fields, including the current set and pinned versions.

Upgrading a component

Catalogue entries pin chart versions, and existing installs do not auto-upgrade when the catalogue changes. An automatic upgrade of every Prometheus install in every cluster after a catalogue bump could break things, so you upgrade each install explicitly:

POST /orgs/{orgID}/components/{component}/upgrade

Pass the space and the exact target chart version. The upgrade runs through the same path as an install (helm upgrade --install). ZopDay rejects the request up front, before anything is queued, when:

a parameter is missing, or the target version floats (latest or *)
the space isn’t active
the component isn’t in the catalogue
the component was never installed on that space (409). ZopDay checks its own install records, so a component installed outside ZopDay (for example with helm directly) counts as never installed.

If you repeat an upgrade that is already running, the request joins the running one. An install or upgrade that overlaps another on the same component is refused with 409, so two changes never race on the same Helm release.

Adding components to the catalogue

To add an internally vetted component to your organisation’s catalogue, contact support.

Reference

Catalogue fields

Field	What it is
`name`	Stable identifier, the value you pass to install or upgrade (e.g. `cert-manager`)
`displayName`	Display name
`description`	What the component does
`category`	Categorisation: `networking`, `security`, `scaling`, `storage`, or `observability`
`providers`	The clouds it can be installed on
`version`	Pinned chart version
`namespace`	The namespace it installs into
`builtInOn`	Clouds whose managed Kubernetes already includes it, where installing it again is redundant

Catalogue scope

The cluster catalogue currently includes:

Category	Components
Networking	NGINX Ingress Controller
Security	Cert Manager, External Secrets Operator (syncs secrets from AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault), Secrets Store CSI Driver
Scaling	Cluster Autoscaler, Metrics Server, KEDA (event-driven autoscaling with scale to zero)
Storage	EBS CSI Driver (AWS only)
Observability	Prometheus Stack (with Grafana), Loki, Fluent Bit, Reloader

Cluster Autoscaler and Metrics Server are already built into GKE and AKS, so install them there only if you have a reason to.

Custom values

Components install with the values the catalogue pins for them. Per-install value overrides are not available today.

Troubleshooting

A service deployed but its URL doesn't answer

A cluster with no ingress controller routes no external traffic. Check that ingress-nginx is installed and healthy on the cluster. ZopDay installs it before the first service deploy, and a failed install is recorded as a failed action on the space.

An install failed waiting on a webhook

Components with admission webhooks wait until the API server can reach the webhook. The install fails if the webhook never comes up, for example because of missing RBAC or a network restriction between the API server and the webhook service. The action records the failing step and error; fix the cause and retry.

An upgrade returns 409

Either the component was never installed on that space by ZopDay (an install done with helm directly doesn’t count), or another install or upgrade on the same component is still running. Install it through ZopDay first, or wait for the running change to finish.

An upgrade was rejected before it started

Check that you passed the space and an exact chart version (not latest or *), that the space is active, and that the component is in the catalogue.