nxs-universal-chart: one Helm chart for whatever you are deploying

The chart renders the workload, and the subcharts render the ecosystem

nxs-universal-chart is described as a Helm chart you can use to install any of your applications into Kubernetes or OpenShift, and more generally into orchestrators compatible with the native Kubernetes API. The chart renders through a shared nuc-common library chart, with Chart.yaml pointing at the published dependency, and local workflows resolving it with make deps or the helm-deps script. The resource list the chart can render covers the ordinary workload set: Deployment, StatefulSet, Service, Ingress, ConfigMap, Secret, SealedSecret, PersistentVolumeClaim, ServiceAccount, Role, RoleBinding and ClusterRoleBinding, Job, CronJob, HorizontalPodAutoscaler and PodDisruptionBudget, plus raw resources through the extraDeploy feature. The feature list names Ingress Nginx, Traefik and Istio as supported controllers, and the compatibility statement covers Kubernetes 1.23 or newer, the listed OpenShift versions, and Helm 2, 3 and 4.

Installing from an OCI registry, and the local hooks

The quick start is a single helm install against an OCI registry URL.

helm install nxs-universal-chart oci://registry.nixys.ru/nuc/nxs-universal-chart \
  --namespace app-system \
  --create-namespace

The namespace flag and the create-namespace flag are the standard way to place the release. For local work the README points at the additional features document, and there are two hook commands to install the local README generator.

pre-commit install
pre-commit install-hooks

The chart is also published to Artifact Hub under the nixys repository, and the README says it is for development and for DevOps engineers, which tells you the audience plainly.

Sixteen subcharts, each with its own version and switch

The dependency table is the heart of the project. nuc-common is always loaded as the shared helper library, and it carries the shared Helm library helpers for capability detection, pod and workload rendering, labels, templating, configmaps, secrets, ingress, volumes and deprecation notices. The remaining nuc-* dependencies are enabled through their matching .Values.<name>.enabled flags, and each has its own version, its own source chart repository and its own list of resources. nuc-traefik at 1.0.5 brings the Traefik CRDs including IngressRoute, Middleware, TLSOption and ServersTransport. nuc-certificates at 1.0.4 brings cert-manager resources. nuc-istio at 1.0.5 brings Gateway, VirtualService and DestinationRule. nuc-fluxcd at 1.0.4 brings the Flux CD sources. The rest cover Knative, KServe, the Prometheus operator stack, Gateway API, Envoy Gateway, VictoriaMetrics, the Vault secret operator, Argo CD, KEDA and CloudNativePG.

The one exception is spelled out in the README. nuc-envoy-gateway is enabled through global.nuc-envoy-gateway.enabled rather than through its own key, because its subchart schema does not accept an enabled key under nuc-envoy-gateway. That is a small inconsistency, and it is the kind of detail that costs an afternoon if you are generating values files by hand.

The test targets tell you what the project considers done

The Makefile is the best description of the project's engineering practice. The default goal is help, and the help target lists the local targets with their descriptions. deps ensures the chart dependencies from Chart.yaml are available locally by running the helm-deps script, and lint depends on it and runs helm lint against the example values file. There are several test targets, and their names say what each covers. test runs the unit tests and the fast smoke checks. test-unit runs helm-unittest suites from the tests/units directory. test-compat runs backward compatibility checks against previous tags, which is the target that matters most for a chart other people depend on. test-smoke runs the smoke scenarios, and test-smoke-fast runs them except the ones that depend on kubeconform validation. test-e2e runs local kind-based end to end tests.

The fast smoke target enumerates its own scenarios, and the list doubles as a specification of the chart's contract: default-empty, schema-invalid-list-contract, rendering-contract, null-workload-entries, hook-annotations, samples-render and example-render. A rendering contract test and a null-workload-entries test are exactly what you want in a chart that many teams will reconfigure.

Samples as documentation, and a values schema that constrains the input

The samples directory is where the chart's real documentation lives. It holds around two dozen example configurations, and their names are a map of what the chart is for: ai-inference-gateway-api, ai-inference-mesh, basic-stateless-app, batch-processing, cert-manager-issuance, clickhouse-analytics, cloudnativepg-postgres, eck-elk-stack, envoy-gateway-policies, external-secrets-sync, fluxcd-gitops-delivery, gateway-api-routing, istio-egress, istio-traffic-routing, istio-zero-trust, keda-event-autoscaling, knative-serverless-service, kserve-custom-runtime, kserve-inference-graph, kserve-inference-service, kserve-localmodel-cache, ml-platform, percona-mongodb-replica-set, percona-mysql-ha and platform-baseline-app. Reading a handful of those is faster than reading the values reference, because they show which values combinations are meant to be used together. Alongside the samples the repository has a values.schema.json, which is the mechanism that turns the values model into something a user can get wrong in a way that is caught early.

Documentation generated from a template, and an active release line

The docs target regenerates README.md from a template file through helm-docs, using a script in the scripts directory, so the readme's values table cannot drift from the values file. The repository layout is the usual chart shape with the extras this project needs: the templates directory, a tests directory with units, smokes and an e2e script, the samples directory, the scripts directory, a docs directory, a Chart.lock alongside Chart.yaml, a values.yaml and a values.yaml.example, a .helmignore, a pre-commit configuration, a CHANGELOG and a LICENSE. The licence is Apache-2.0, the repository is not archived, and the last push was on 2026-09-22 with the release tag v3.2.2 on the same day, following v3.2.1 in August and v3.2.0 earlier that month, so the project ships on a steady monthly cadence. The main language of the repository is recorded as Go Template, which is what a Helm chart is made of.

Editorial conclusion

nxs-universal-chart fits a platform team that deploys many different applications and wants one set of conventions, one values file shape and one place to add a custom resource. It does not fit someone who wants a small chart with three templates they can read in an afternoon, since this is a framework rather than a chart. Verify first which subcharts you actually need and pin those versions, because the ecosystem pieces are versioned separately from the main chart, and run the samples rendering check before you rely on a values change, since the repository ships that as a fast local test.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nixys/nxs-universal-chart on GitHub
4. README
5. Releases