Slow deployments: deploying a new project needed multiple people across different disciplines with conflicting priorities – it could take weeks, depending on who was available.
Single person dependency: product teams could not deploy their own services and had to queue for specialist help.
Drift and technical debt: environmental drift and accumulated technical debt led to significant delays.
Disparate infrastructure: services ran across a mix of physical, virtualised and cloud platforms in air-gapped, security-sensitive environments – difficult to manage and costly to scale.
- 1
Built a Rapid Delivery Environment: a homogenous Kubernetes-based hosting platform spanning on-premises and cloud infrastructure. - 2
Desired state configuration: Every environment defined as code, in version control (GitOps), so the platform guarantees each environment’s state and automatically reconciles any drift. - 3
Automated sequencing: the platform resolves the dependencies between the 25–30 services in a typical environment, bringing each one up in sequence as their dependencies resolve. - 4
Self-service onboarding: using a standard container build, a preconfigured deployment package(Helm chart) and a GitOps template tailored per environment. - 5
Secure by design, Secure by default: automated certificate issue and renewal providing encrypted service-to-service traffic, image scanning, role-based access and isolated tenancy for every project. - 6
We proved the platform with its first workload, a standardised, templated case management framework aligned to the Intelligence Community Design System.
A product team can go from nowhere to a live service in around a day and a half, and their next project in around half a day.
Deployments that used to take hours to days end to end now happen instantly on trigger.
A new environment that may consist of around 10 central platform services plus 10–15 project services can now be provisioned and fully configured in hours, when previously it took months, in one automated run without the need for manual sequencing.
Three workloads onboarded (the case management framework and two case management systems), with a fourth planned.
Everything handed over for teams to self-serve, including full design documentation and a how-to guide to help future project teams build an environment from nothing.
Their story
Every cluster and every service on it is defined in version control (GitOps). The platform continuously reconciles itself to that definition and automatically corrects any drift, so every environment is known to be consistently configured. Teams always know exactly what is deployed, where, and in what state.
Hydrating a secure environment means bringing up 25–30 interdependent services in exactly the right order - around 10 central platform services such as certificates, secrets and the service mesh, and 10 to 15 project-specific services that depend on them. Our platform handles the dependencies and sequencing itself, starting each service only when the services it depends on are healthy. A full environment can be built from nothing in one consistent, repeatable step without needing to remember or script what comes first, and every environment comes out the same.
Onboarding follows a repeatable pattern: a multi-stage container build, a tagged artefact in a central registry, a preconfigured Helm chart, and a GitOps template tailored per environment using overlays. Once tailored, the same configuration and process is used to provision local developer clusters as is used for integration and higher shared environments. This significantly improves the developer onboarding experience and compresses the time for new team members to become productive down from days and even weeks to less than a day.
Certificates are issued by an internal certificate authority and renewed automatically for each project (cert-manager with Vault), removing one of the most common causes of outages in secure environments.
Encrypted service-to-service traffic with service policy enforcement (Istio service mesh); isolated tenancy for each project (Kubernetes namespaces); role-based access control; container image scanning; backups by label, namespace or whole cluster; and three ways to route traffic into services (load-balanced services, ingress controllers and Kubernetes Gateway API).
It deployed in a few hours across cloud, on-premises and local developer environments limited only by the time taken to retrieve container images - and two case management systems followed.
The first workload was a standardised case management framework aligned to the Intelligence Community Design System. It deployed in a few hours across cloud, on-premises and local developer environments limited only by the time taken to retrieve container images - and two case management systems followed.
“We didn’t just build a hosting platform. Teams can go from code to deployed service in a day and a half, on any infrastructure, and every environment is guaranteed to be in exactly the state it’s meant to be: 25 to 30 services built from nothing in a single step. We left behind the documentation and the patterns for an experienced team to rebuild it from scratch and extend it with confidence.”
