Deployment and Extension

How the OpenG2P Registry is packaged, deployed and extended. The platform is now a complete, installable registry in its own right — with a reference registry, Helm chart, Docker images, seeding and t

New home: GitLab. registry-platform is now developed at github.com/OpenG2P/registry-platform.

This section explains how the OpenG2P Registry is packaged, published, deployed and extended under the current model. It is self-contained: read it to understand how the images and Helm chart are produced, how the platform runs out of the box, and how you turn it into a domain-specific registry.

The model, and how it changed

This is the reverse of the previous avatar. Earlier, registry-platform was a library repo, and each domain registry (Farmer Registry, National Social Registry, …) included it and owned all the Dockerfiles, the full Helm chart, the build/publish CI and the seeding. That duplicated the chart and build logic across every registry and let them drift.

Now the direction is inverted: registry-platform is a complete, runnable registry that publishes the Docker images and the Helm chart. A domain registry is a thin extension that builds on top of those artifacts. It no longer re-assembles the platform.

The platform ships everything a registry needs, in-built and complete:

In-built	What it means
Reference registry	A minimal but real registry (Individual + Household) that runs as-is — used for demos, CI and as the canonical example to copy.
Helm chart	One chart, openg2p-registry, that deploys any registry. No per-registry chart copy.
Docker images	The full set of runtime images, published and versioned together.
Seeding	A db-seed image + machinery; the reference registry's seed ships with it.
Tests	A sanity/e2e suite (sanity-tests image) that verifies a running registry end to end.

A domain registry (social registry, farmer registry, disability registry, …) is created by extending this — supplying only its domain model, seed data, tests and a small deploy overlay. See Extending into a new registry.

Where the artifacts live

Artifact	Location
Platform + reference registry source	openg2p/registry/registry-platform
Dockerfiles	registry-platform/docker/* (+ ui/staff-ui/Dockerfile)
Helm chart	registry-platform/helm/openg2p-registry, published to the OpenG2P Helm repository — openg2p.github.io/openg2p-helm
Docker images	Docker Hub, the openg2p/openg2p-registry-* repositories
Reference extension (example)	registry-platform/reference-extension
Version catalogue / changelog	openg2p.github.io/openg2p-packaging/registry-platform/CHANGELOG

Versioning & CI

All Docker images and the Helm chart are built by a single CI workflow and carry one version per commit — images and chart never drift. The versioning scheme, derivation rules and lockstep tagging are documented once, org-wide, here:

Helm & Docker versioning and CI — the authoritative reference (not repeated here).

In this section

• Packaging & the reference registry — the images, the single chart, the reference registry, and how the domain model is selected at runtime.

• Extending into a new registry — what a domain registry owns versus inherits, why extension rather than a fork, and how one image serves several registries.

• Country data & seeding — country packs, code lists, the seeding switches, and what an empty production install looks like.

• Testing & the sanity suite — the two-part test model (extension-independent vs field-specific) and how to extend the tests for your registry.

Looking for step-by-step instructions? This section explains how the model works. To actually build and deploy a registry, follow Building a Registry — three phases from an empty repository to production.