> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/national-learner-registry/deployment-and-system-integration.md). # Deployment and System Integration What deployment means in this context, environment separation, how external systems integrate with the registry, and the RKE2/Liquio configuration guide. {% embed url="" %} ## What Deployment Means in This Context After registries, workflows, roles, permissions, templates, and integrations have been configured, the solution must be made available for operational use. This requires moving the approved configuration to the environment where users will access and use the system. Deployment has two complementary parts. The first is deployment of the **platform itself** — core services, infrastructure components, and internal functionality required for the solution to operate. The second is deployment of **solution-specific configuration elements**: BPMN schemas, registry structures, form configurations, document templates, notification templates, roles, permissions, and other configuration artefacts. Deployment ensures that the target environment reflects the approved configuration and is ready to support real users, business processes, registry operations, integrations, reporting, and auditability. ## Configuration, Testing and Production Environments Digital solutions are usually developed and maintained across multiple environments. This separation helps ensure that changes can be configured, tested, and approved before they become available to end users. | Environment | Purpose | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Configuration / development** | Used to create and modify solution components — registries, internal directories, business processes, forms, permissions, templates, and integrations. | | **Testing** | Used to validate the configured solution — testing business processes, checking registry updates, verifying permissions, testing integrations, and identifying issues before release. | | **Production** | Used for day-to-day operations — contains the live services and data used by organisations and end users. | The typical flow is: configuration is prepared in a dedicated environment, then deployed to testing for validation, and only after approval deployed to production. This helps prevent unfinished or untested changes from affecting active services. ## Integration With External Systems Registry solutions rarely operate in isolation. Information often needs to be exchanged between multiple systems to support service delivery, verification, reporting, payments, notifications, digital identity, digital signing, or credential issuance. Integrations help reduce duplicate data collection by allowing information to be reused across systems instead of being repeatedly entered and maintained in separate places. Integrations are implemented through external service connectors and workflow actions. Business processes may invoke external services, send information to other systems, retrieve information required for a workflow, or receive responses that affect the next process step — for example, authenticating users through a digital ID provider, signing documents through a trust service provider, checking information in external registries, processing payments, sending notifications, issuing credentials, or providing data for reporting tools. {% hint style="warning" %} Integration design should define which systems are connected, what data is exchanged, when the exchange happens, which APIs are used, how authentication is handled, and how errors are processed. External systems should only access registry data according to the permissions, access rules, and data protection requirements defined for the solution. {% endhint %} ## RKE2 Cluster Deployment and Liquio Platform Configuration Guide Alongside the business-level view above, the Knowledge Product now includes a detailed, command-level guide for standing up the underlying infrastructure: provisioning a three-master RKE2 Kubernetes cluster with kube-vip and Cilium, optionally attaching Ceph storage, deploying manifests through Argo CD, and configuring the Liquio platform services (Vault, Config Manager, RabbitMQ) on top of it. {% content-ref url="/pages/jsS6zVTyLgqLFCJxmBF1" %} [RKE2 Cluster Deployment and Liquio Platform Configuration Guide](/experience-digital-transformation/national-learner-registry/deployment-and-system-integration/rke2-cluster-deployment-and-liquio-platform-configuration-guide.md) {% endcontent-ref %} --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/national-learner-registry/deployment-and-system-integration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.