> 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/ai-wallet-use-case/chapter-05-cloud-deployment.md). # Chapter 05: Cloud Deployment AI-Enabled GovBuild Education Wallet Building Block This chapter describes how everything built in Chapters 3 and 4 is deployed and operated in the cloud: the reference architecture, the containerised deployment with Docker and Kubernetes, the Helm-based installation, the security and observability controls, and the sandbox deployment through which ITU evaluators access the running system. The deployment approach deliberately supports the non-functional requirement that the solution can run on local hosting, sovereign cloud, or hybrid models: every component ships as a container image that can be installed on any conformant Kubernetes cluster. ## 5.1 Reference Cloud Architecture #### 5.1.1 What is deployed The running system consists of three deployment units with different operational owners:
Deployment unitContentsOperated by
Giga Skills Marketplace platformThe web application (public catalogue, showcase, and role-based consoles) and the marketplace service (catalogue API), backed by PostgreSQL.Deployed from this project's repository to the sandbox; installable by any operator from the Helm chart.
Education use-case demonstration websiteThe prototype of Chapter 4: learner and institution portals demonstrating the four service journeys, built with the assistant and the marketplace skills, and listed in the marketplace showcase.Deployed alongside the marketplace in the sandbox.
Wallet servicesThe chosen provider's issuer, verifier, and holder services, consumed through their published sandbox APIs (in the prototype, EU Business Wallet and Wallet).Operated by the wallet provider; self-hostable from the provider's published Helm charts where a country requires it (reference: docs.igrant.io for the prototype's provider).
This split mirrors the responsibility boundary of Chapter 3 (Section 3.2.3): the marketplace holds no runtime, API keys, or learner data for any application built with it. The demonstration website talks to the wallet provider's APIs directly through its own backend. Figure 5.1. Reference cloud deployment: the Helm-provisioned Kubernetes stack, the CI/CD pipeline, and the wallet provider's sandbox APIs. #### 5.1.2 Separation of environments Three environments are separated end-to-end: development (a laptop or CI runner running the full stack with Docker Compose), test (ephemeral stacks for the end-to-end and capacity suites), and the ITU sandbox (the shared, public evaluation environment). Wallet interactions in every environment target the wallet provider's sandbox base URL with API-key authentication, so no live national systems or real learner data are ever involved; the mock services of Chapter 2 (Section 2.3) stand in for national DPI systems. #### 5.1.3 Containerised deployment with Docker Each deployable builds to its own container image (giga-web, giga-marketplace) from Dockerfiles in the repository, and PostgreSQL always runs in a container - there is no host database install to manage. The full stack runs locally with a single command (make up), bringing up PostgreSQL, the marketplace service on port 4830, and the web application on port 4820; the database schema bootstraps and demo data seeds on the first request. A Makefile wraps the common routines, including a hot-reload development mode with Postgres in Docker and the two applications on the host. #### 5.1.4 Kubernetes and Helm Production-shaped deployment uses the Helm chart shipped in the repository (deploy/helm/giga). One helm upgrade, install provisions: * giga-web - the Next.js marketplace and dashboards (Service on port 80 to 4820), two replicas with CPU-based horizontal autoscaling from two to six; * giga-marketplace - the catalogue API (Service on port 4830), two replicas autoscaling from two to four; * giga-postgres - PostgreSQL 16 with a PersistentVolumeClaim; * Ingress - ingress-nginx with cert-manager TLS for the configured domain. Cluster prerequisites are ingress-nginx, cert-manager with a ClusterIssuer, the two images in a registry the operator controls, and DNS pointed at the ingress load balancer. Everything else has defaults in values.yaml; the operator overrides domain, image registry and tag, ingress class, and cluster issuer per environment. Pod disruption budgets retain at least one replica of each deployable during voluntary disruptions, and per-pod database pools are capped so maximum autoscale cannot exhaust PostgreSQL connections. The bundled PostgreSQL pod is a single-node convenience for demonstrations. For a production deployment, the chart disables it in favour of a managed PostgreSQL service with backups, monitoring, and connection capacity for the application pool - configured with a single externalDatabaseUrl value. The same pattern applies to a country deployment on sovereign infrastructure: any managed or self-hosted PostgreSQL 16 works. #### 5.1.5 Network segmentation and security controls The security posture follows a small number of hard rules: * Secrets never live in git: The chart ships with secrets blank by design; the internal service token and database password are supplied at deploy time from a local, gitignored values file or the CI secret store. * Wallet API keys stay server-side: As established in Chapter 4 (Section 4.6.3), the organisation API key lives in the backend configuration of the application that owns it and never reaches a browser. * Service-to-service calls are authenticated: The web application talks to the marketplace service with a shared internal token; only the ingress exposes public endpoints, and all external traffic terminates TLS at the ingress with cert-manager-issued certificates. * Identifiers are non-enumerable: Every database row is keyed by a UUID, so catalogue, account, and audit identifiers cannot be guessed or walked. #### 5.1.6 Observability: logging, monitoring, and audit Each service exposes a health endpoint used by Kubernetes probes and external monitoring. Application logs stream to the container runtime for collection by the cluster's log stack, and the audit log of Chapter 3 (Section 3.3) - every review decision, publication, and role change - lives in PostgreSQL as queryable evidence rather than in transient logs. Capacity is verified, not assumed: the repository's load gate sends 10,000 catalogue requests at 100 concurrent clients against a running stack and fails on any error or a p95 latency above 500 ms, a baseline representing roughly 10,000 registered accounts under a catalogue-heavy workload. ## 5.2 Sandbox Deployment #### 5.2.1 Deployment in the ITU sandbox The marketplace and the demonstration website are deployed with the Helm chart described above and staged for evaluation at [https://giga-marketplace.assembly.govstack.global](https://giga-marketplace.assembly.govstack.global/), with wallet traffic running against the wallet provider's sandbox APIs. Public read access lets ITU evaluators browse the catalogue, the published skills and usecases, and each item's public review trail without an account; the seeded role accounts (Annex E) let evaluators exercise the provider, reviewer, and super-admin consoles. The exact target environment inside the ITU sandbox, including access credentials and which DPI building blocks are live rather than mocked, follows the open item agreed at inception and is finalised with ITU. #### 5.2.2 The demonstration website The demonstration website is the evaluator-facing proof of the whole approach: a scenario walkthrough of the National Learner Registry usecase in which each of the four journeys of Chapter 1 can be exercised against real wallet software - registering a learner, issuing a diploma to the Data Wallet, and verifying a selectively disclosed presentation as a relying party. It is itself an artefact of the method it demonstrates: built by installing the marketplace skills into an AI integration assistant as described in Chapter 3, following the integration path recommended in Chapter 4 (Section 4.6), and listed in the marketplace showcase with the skills and usecases it was built from, so an evaluator can trace the running site back to the exact published capabilities that produced it. #### 5.2.3 CI/CD pipeline On every push to the main branch, the GitHub Actions workflow builds both container images and runs the same helm upgrade against the sandbox cluster, authenticating to the cloud provider with Workload Identity Federation - no long-lived keys exist in the repository or its secrets. Because deployment is the same Helm command in CI and by hand, the pipeline is reproducible by any operator with cluster access, and a country adopter can reuse the workflow file with their own registry and cluster coordinates. #### 5.2.4 Runbooks and access documentation Operational documentation ships with the repository rather than separately: the deployment README covers prerequisites, secret configuration, install and upgrade commands, and the managed-database switch; the Makefile documents every local routine (make help); and the end-to-end suite doubles as an executable runbook for verifying a fresh deployment - catalogue rendering, provider-scoped URLs, the full submit-review-publish cycle, both bundle download formats, authentication, and role handling. Evaluator access details - URLs, seeded accounts, and demonstration scripts for each journey - are listed in Annex E and handed over with the sandbox. Chapter 6 covers how this deployment and the approach it entails are replicated and sustained in a country context. --- # 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/ai-wallet-use-case/chapter-05-cloud-deployment.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.