> For the complete documentation index, see [llms.txt](https://docs.openg2p.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openg2p.org/products/registry/national-social-registry/deployment/helm-chart.md).

# Helm chart

{% hint style="info" %}
**New home: GitLab.** **`national-social-registry`** is now developed at [gitlab.com/openg2p/registry/national-social-registry](https://gitlab.com/openg2p/registry/national-social-registry).
{% endhint %}

The National Social Registry is deployed by **`openg2p-nsr`** ([`helm/openg2p-nsr`](https://gitlab.com/openg2p/registry/national-social-registry/-/tree/develop/helm/openg2p-nsr)), published to the `openg2p/charts` GitLab Helm registry.

The chart declares the platform chart as a **pinned dependency** and supplies a values overlay. It owns **no service templates** — every API, worker, job and ingress comes from the subchart — but it does carry a few templates of its own for things the platform has no concept of (see [What this chart owns](#what-this-chart-owns)):

```yaml
# Chart.yaml
dependencies:
  - name: openg2p-registry
    alias: registry              # overlay nests under .Values.registry
    version: 0.0.0-develop.383   # HARDCODED — moved deliberately
    repository: https://gitlab.com/api/v4/projects/84460547/packages/helm/stable
```

Every service template, IAM/Keycloak wiring, db-seed mechanism and the sanity suite come from that subchart. See [Packaging & the reference registry](/products/registry/registry/deployment-and-extension/packaging-and-reference-registry.md) for what the platform chart contains.

{% hint style="info" %}
**This replaces the previous self-sufficient chart.** NSR used to own all \~40 templates and its own `questions.yaml`. Those now live once, in the platform chart.
{% endhint %}

## Two kinds of value

| Where        | What                                                                                            | Why                                                                                      |
| ------------ | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| `global.*`   | Shared settings — hostnames, DB hosts, Keycloak, CM/PM/AWE/Audit URLs, the enforcement switches | Helm propagates `global` into subcharts automatically, so these are set at the top level |
| `registry.*` | Everything else — images, component toggles, `dbSeed.*`, `sanity.*`, `idgenerator.*`            | These are the **subchart's** values, so they nest under the `registry` alias             |

A platform setting that was `dbSeed.loadSampleData` when installing the platform chart directly becomes `registry.dbSeed.loadSampleData` here.

## What it deploys

| Component              | Image                       | Built in this repo?                                                                                  |
| ---------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------- |
| Staff Portal API       | `openg2p-nsr-staff-api`     | Yes                                                                                                  |
| Partner API (DCI)      | `openg2p-nsr-partner-api`   | Yes                                                                                                  |
| Celery worker + beat   | `openg2p-nsr-celery`        | Yes (one image, role selected by `CELERY_APP`)                                                       |
| DB seed                | `openg2p-nsr-db-seed`       | Yes — see [Data seeding](/products/registry/national-social-registry/deployment/data-seeding.md)     |
| Staff Portal UI        | `openg2p-registry-staff-ui` | **No** — platform image, used as-is                                                                  |
| Beneficiary Portal API | `openg2p-registry-bene-api` | **No** — platform image, used as-is                                                                  |
| Sanity tests           | `openg2p-nsr-sanity-tests`  | Yes — see [Sanity testing](/products/registry/national-social-registry/deployment/sanity-testing.md) |

Each NSR backend image is a few lines: `FROM` the matching platform image, `pip install nsr-extension`, and set `REGISTRY_EXTENSION_MODULE=openg2p_registry_nsr_extension`. The platform code is never vendored — it is already in the base image.

## What the overlay actually sets

Deliberately small:

* **Images** — the five NSR-built repositories above.
* **`global.registryVariant: nsr`** and the ingress hostname.
* **`registry.dbSeed.load*`** — the loaders, which the platform defaults off.
* **`registry.iamRegister.applicationDescription`** — the name of this registry's tile in IAM. The roles/permissions catalog itself is registry-agnostic and comes from the subchart.
* **`registry.idgenerator...idTypes`** — the functional-ID pools, `individual` (12) and `household` (10).
* **`registry.sanity`** — the NSR sanity image and the seeded record's search text; the register id, tab and section are already correct as subchart defaults.

## What this chart owns

Beyond the values overlay, the wrapper carries templates for the **analytics and reporting layer** — capabilities the platform chart has no concept of, because they depend on this registry's own schema and dashboards:

| Template                                           | What it does                                                   |
| -------------------------------------------------- | -------------------------------------------------------------- |
| `analytics-jobs.yaml`                              | Bulk sample generation, reporting-view build, dashboard import |
| `reporting-views-refresh.yaml`                     | CronJob that refreshes the `nsr_rpt_*` views                   |
| `dashboard-bundle-configmap.yaml`                  | Ships the dashboard bundle from `files/`                       |
| `maps-content-configmap.yaml`, `_maps-content.tpl` | Map boundary content for drill-down                            |
| `superset-service-account-secret.yaml`             | Credentials the importer uses                                  |

These are driven by the chart's own `analytics.*` and `mapsContent.*` values. Background: [Reporting views](/platform/platform-services/reporting-and-analytics/reporting-views.md), [Dashboards](/platform/platform-services/reporting-and-analytics/dashboards.md), [Map drill-down](/platform/platform-services/reporting-and-analytics/map-drill-down.md).

## Configuration form (Rancher)

The chart ships **no `questions.yaml` of its own**. Rancher reads questions only from the root of the chart being installed and ignores a subchart's, so the file is **generated at packaging time** from the pinned `openg2p-registry` dependency: every non-`global.` variable is prefixed with `registry.`, and each question's default is resolved from this chart's overlay first, then the platform's. The NSR form therefore offers exactly the platform's settings and cannot drift from the pinned version.

Keys this chart owns and the platform does not — the `analytics.*` and `mapsContent.*` switches above — cannot be inherited, so questions for them live in **`questions.own.yaml`** and CI appends them verbatim to the generated file.

## Consent Manager and Partner Management

The **partner-api** is the policy-enforcement point for DCI requests and depends on two commons-services components: **Partner Management** (source of partner public keys, used to verify the DCI envelope signature) and **Consent Manager** (the decision point — the partner-api calls `/validate` and clamps the response to the consented scopes).

| Parameter                                  | Default                                  | Purpose                                                        |
| ------------------------------------------ | ---------------------------------------- | -------------------------------------------------------------- |
| `global.partnerSignatureValidationEnabled` | `true`                                   | Verify the DCI envelope signature against the partner's PM key |
| `global.consentEnforcementEnabled`         | `true`                                   | Call CM `/validate` and clamp fields to the consented scopes   |
| `global.partnerManagementApiUrl`           | `http://commons-services-pm-partner-api` | Partner key lookup                                             |
| `global.consentManagerUrl`                 | `http://commons-services-cm-partner-api` | The `/validate` endpoint                                       |

{% hint style="warning" %}
**Both switches default to `true` — the chart fails closed.** Turning either off opens real PII egress: with signature validation off the `signature` field is required but never inspected, and with consent enforcement off records are returned **unclamped**. Either bypass is stamped into the DCI response header meta (`signature_validation` / `consent_enforcement`), which is the only outward signal.
{% endhint %}

## Running more than one registry in a namespace

Names that would otherwise collide are scoped to the release, so an NSR and a [Farmer Registry](/products/registry/farmer-registry.md) can coexist: the Keycloak staff client, the MinIO buckets, the keymanager app-id and the AWE callback-secret id all derive from `{{ .Release.Name }}`.

## Versions and CI

The chart and all NSR images are built by the **OpenG2P central pipeline** at **one version per commit** — see [Helm & Docker Versioning Strategy and CI](https://docs.openg2p.org/operations/deployment/helm-docker-versioning-and-ci) for the authoritative rules. The repo carries a single thin stub, [`.gitlab-ci.yml`](https://gitlab.com/openg2p/registry/national-social-registry/-/blob/develop/.gitlab-ci.yml), calling `openg2p/packaging@v1`. This replaces the previous branch-derived chart versioning and the separate per-image workflows.

Two version lines meet in this chart, and they move independently:

* **The NSR version** — the chart and the five NSR images, locked together and stamped by CI on every commit.
* **The platform version** — `RP_VERSION` in the Dockerfiles and the `openg2p-registry` dependency in `Chart.yaml`. These are **hardcoded and changed deliberately**, always as a pair. Move both together with `./scripts/bump-rp-version.sh` (`-n` to preview the latest published version, `<version>` to pin a specific one); a CI check fails the build if the two ever drift.

Released versions and what changed in each: [**Versions**](/products/registry/national-social-registry/versions.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.openg2p.org/products/registry/national-social-registry/deployment/helm-chart.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.