The Ministry of Justice Modernisation Platform and why it exists beside the Cloud Platform

A platform team exists because the shared Cloud Platform does not fit every app

The Modernisation Platform team is described in the README as a platform engineering product team that provides a hosting platform for Ministry of Justice applications which cannot be hosted on the Cloud Platform. That single clause carries the entire justification.

The Cloud Platform is the organisation's default hosting route, and the Modernisation Platform is the exception path for applications that fall outside it. The README does not enumerate which applications those are, and it does not need to. The important structural point is that this is a second platform with its own conventions, and applications land on it because the first one did not fit.

For an outside engineer, the interesting part is that the platform is public. The architecture decisions, the environment definitions, the infrastructure as code and the source of the user guide site all sit in this repository, and the user guide is published at user-guide.modernisation-platform.service.justice.gov.uk. A government platform that publishes how it is built is unusual enough to be worth reading on its own terms, whatever your sector.

The repository description states the two things it is: a place for the core work of the Modernisation Platform, and a repository defined and managed in Terraform.

Four things live here, and the application code lives somewhere else

The README lists what the repository holds, and the list is short enough to quote in full.

The Architecture Decision Record is in the `architecture-decision-record` directory. Environment definitions are in `environments`. Infrastructure as code is in `terraform`. The source code for the user guide site is in `source`. That is the whole inventory of the core repository.

The separation matters, because the README also names the sibling repositories and their roles. The `modernisation-platform-environments` repository holds user application infrastructure as code and deployment workflows, which is the opposite responsibility to the `terraform` directory here. `modernisation-platform-ami-builds` holds the pipelines that build AMIs for use on the platform. `modernisation-platform-configuration-management` holds configuration management code used on the platform. `modernisation-platform-terraform-module-template` is the template repository used for creating other Terraform module repositories.

So the core repository owns the platform, and the environment repository owns what runs on it. If you are looking for how a particular application is deployed, this is the wrong repository, and the README's table is the fastest way to find the right one.

Member account modules cover the unglamorous parts of running AWS

The README describes a set of Terraform modules intended for use by member accounts, designed to comply with best practices and to work with the platform, with the stated goal of making infrastructure quicker, easier and more secure to create. The modules are published as separate repositories.

The list covers the standard set of things a team needs. There is a Linux bastion server module, an ECS cluster module, and an S3 bucket module that comes with sensible defaults such as replication and encryption. There is an EC2 instance module and an EC2 autoscaling group module. There is a Lambda function module. The load balancer module creates an application load balancer in AWS with logging enabled, an S3 bucket to store the logs and an Athena database to query them.

Three of them are less common and show what the platform team has had to solve. The virtual machine import module creates the S3 buckets and roles needed to import VM images from a virtualisation environment to Amazon EC2 as AMIs, which is a common need when migrating off on-premises hosting. The PagerDuty integration associates an SNS topic with a PagerDuty service. The SSM patching module automates patching of EC2 instances, creating an S3 bucket for log storage along with maintenance windows, tasks, resource groups and patch baselines.

The pattern to notice is that these modules are opinionated about the things a platform team standardises, and silent about everything else. The logging and query path for a load balancer, for instance, is baked in rather than left to the consuming team.

The ADR directory is the part most outsiders will read

The `architecture-decision-record` directory is the first item in the repository contents list, and the repository topics include `architecture-decisions`. That ordering is a signal about what this project considers its most valuable output.

An ADR records a decision, the context behind it and the consequences, and keeping them in the same repository as the infrastructure means the reasoning and the code change together. For anyone outside the Ministry of Justice, this is the part with the longest shelf life. A Terraform module for an S3 bucket is a commodity, while the record of why the platform is shaped a particular way is specific and hard to reconstruct later.

The repository root also holds `cidr-allocation.md`, which is a separate document for a specific reason. IP address allocation is a shared, cross-environment resource, and on a platform hosting many applications it cannot be left to each team to decide. Keeping the allocation plan at the top level of the core repository, rather than inside one environment, reflects that it is a platform-wide concern.

The `policies/` directory and the `environments-networks/` directory point the same way. The network design of the platform and the policies applied to it are centrally owned here, which is how a platform team keeps many teams from making incompatible choices.

The repository layout shows a platform, not a service

Beyond the four directories the README highlights, the root of the repository contains a set of files that describe how the platform is operated. There is a `makefile` and a `scripts/` directory, a `config/` directory, a `docs/` directory, a `.devcontainer/` directory for local development environments, a `.trivyignore.yaml` file, and a `test.json`.

The Trivy ignore file is a small detail with a large meaning. Trivy is a vulnerability scanner, and an ignore file for it means the repository carries a deliberate list of findings that are accepted rather than fixed. On a platform that scans container images for the whole department, the decision to accept a finding is a decision someone has to make and record, and a file at the root of the core repository is where that record lives.

The `.devcontainer/` directory indicates that a developer can open the repository in a preconfigured container, which for an infrastructure repository means the tool versions, the provider credentials and the layout of the working copy are all defined in version control rather than on someone's laptop.

The `test.json` file at the root is a small artefact whose purpose the README does not describe, and the `docs/` directory is separate from the `source` directory that builds the public user guide site, which suggests internal documentation and the published site are maintained differently.

MIT licensed, pushed daily, and released through tags rather than releases

The licence is MIT, with the text in the LICENSE file at the root, which means the code, the ADRs and the documentation can be reused with attribution and no copyleft obligation. For a government platform built in the open, that choice is deliberate, and it is what makes the pattern usable outside the department.

The repository is not archived, and the last push was on 2026-10-20, so the platform is being worked on continuously. There are no GitHub releases, so there is no versioned artefact to depend on. The platform is consumed as code from branches and modules rather than as a packaged release, and the module repositories are versioned separately with their own release history.

The homepage points to the user guide rather than to the repository, and the repository has a `CONTRIBUTING.md` file, both of which suggest the project is set up to receive outside contributions.

What this repository does not give you is a way to run the platform as a product. There is no packaged distribution, no documented install command in the README, and no configuration surface for pointing it at your own AWS organisation. The practical route to understanding it is the published user guide and the ADRs; the practical route to using it is to treat the Terraform modules as the interface and supply your own account structure.

Editorial conclusion

This repository suits teams that need to understand how a government hosting platform is actually built and governed, and organisations that want to copy the pattern of a platform team owning the environment layer while product teams own their applications. It is the wrong place to look for application infrastructure code, which lives in the separate modernisation-platform-environments repository, and the wrong place to look for the platform's user documentation, which is built from the `source` directory. Verify first that the ADRs in `architecture-decision-record/` describe the constraints you are designing against, and read `cidr-allocation.md` and the `policies/` directory before assuming you can reuse the network design unchanged.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. ministryofjustice/modernisation-platform on GitHub
4. Project website
5. README