Skip to main content

Creating environments in the Modernisation Platform


In the Modernisation Platform, we define environments (AWS accounts) via a JSON file in the environments directory of the Modernisation Platform repository.

When we recieve your request we will create a new JSON file and submit a pull request to the Modernisation Platform repository. On merging the Modernisation Platform will automatically provision your environments. Each environment defined represents an AWS account, see the example below for more information.

Requesting an environment

To request a new environment, simply create an issue using the New Modernisation Platform Environment template.

This will ask you for the following information:

Application name

Please follow MoJ guidance for naming things The name must be in lowercase and a maximum of 30 characters. If you need to use a separater use -.

GitHub team slug

This is the name of your GitHub team that will be accessing the environment. Environments are accessed via single sign on (SSO), so to give people permissions to access your environment you just have to add them to your GitHub team.

Users who are not part of the MoJ GitHub organisation will need to be added as collaborators separately once the account has been created. Please contact the Modernisation Platform team to do this.

If you wish to add additional deployment reviewers from outside your GitHub team you can specfiy these per an environment in the application.json file (See: “additional_reviewers” in Another example for an example).


This is the level of access for the GitHub team to the Modernisation Platform. A full list of permissions for the different access levels can be found here The options are as follows:


  • Log into the console
  • See resources and basic metadata. You cannot see the content of resources such as logs or S3 buckets.


  • Log into the console
  • Comprehensive read-only visibility of the AWS environment. As this role provides access to contents of S3 and others, it is designed for users for whom view-only is insufficient.
  • Role makes use of AWS ReadOnly managed policy and is not at present configurable beyond that.



The sandbox access can only be used on a development environment account.

  • Log into the console
  • Same console read and write permissions as the pipelines have
  • This permission can only be attached to development accounts
  • Once a week the account will be cleared with AWS Nuke then rebuilt from Terraform

The idea of sandbox access is that it gives you freedom to experiment and modify things in the console to assist with creating your Terraform code.

Anything not in code will be lost at the end of the week.


The migration role is a temporary role, given to assist with AWS managed migration services

Once the migration is complete for an environment this role should be removed.


The instance-management role is a role given to assist database administrators.

  • Log into the console
  • Read only access to resources including things like logs and S3 buckets
  • Start, stop and reboot EC2 instances
  • Create and copy Snapshots
  • Connect to instances via SSM
  • Active Directory permissions


  • Log into the console
  • See resources and metadata useful to security operations teams and security audit teams
  • Makes use of AWS managed SecurityAudit policy


  • DMS Start, stop
  • SQL Workbench
  • Athena
  • Glue
  • Redshift


Created for data engineers to have developer permissions as well as glue and athena permissions all in one policy.

  • Log into the console.
  • Data engineering permissions.


  • Full admin access

This is a legacy role and will not be generally available.

Environment name

Which environments you wish to use, we provide core networking for up to 4 accounts as standard. Usually two environments per application will be enough, a production account and a development account.

  • development
  • test
  • preproduction
  • production

As these environments are identical, and controlled via code, we would recommend you try to use as few environments as possible. We can provide more environments if there is a genuine need for them.


These will be used to tag your AWS resources, for further guidance on tagging please see here

The is-production tag will be inferred if the environment is production.

tag value
application Find a solicitor
business-unit LAA

Valid business-unit values HQ,HMPPS,OPG,LAA,HMCTS,CICA,Platforms,CJSE

Additional features

In addition to the core networking provided, you can request bastion access, additional VPC endpoints and extended DNS zones.

See creating networking for more information on additional features.


You can view our architecture for Environments (AWS accounts) on the dedicated Environments (AWS accounts) architecture page, which also explains what you get by doing this.

Example JSON files

Here are some examples of the environments JSON file that the Modernisation Platform team will create.


  • account-type determines if this is a core modernisation platform account or a user member account
  • environments should be an array of objects for environments required. If the environment is production, retention periods, backup frequency, and similar will be different compared to non-production environments
  • the name key and access object are required, see: Another example
  • the nuke key is optional and is only read if the access.level is sandbox
  • tags should be an object of the mandatory tags defined in the MoJ Tagging Guidance. You can omit is-production as we infer this from the environment name

Blank example

filename: application-name.json

  "account-type": "",
  "environments": [
      "name": ""
      "access": [
          "github_slug": "",
          "level": "",
          "nuke": ""
  "tags": {
    "application": "",
    "business-unit": "",
    "owner": ""
  "github-oidc-team-repositories": [""],
  "go-live-date": ""

Another example

An JSON definition for an nonsensical application called glados, that needs two environments: development with sandbox permissions and production, and want to give the GitHub team glados-team access to each environment. If a develoment account with sandbox permissions has no nuke key defined, it will automatically be wiped on a weekly basis. The nuke value of rebuild indicates that the development account will be automatically rebuilt from code after it is nuked.

filename: glados.json

  "account-type": "member",
  "environments": [
      "name": "development",
      "access": [
        "github_slug": "glados-team",
        "level": "sandbox",
        "nuke": "rebuild"
      "additional_reviewers": ["GitHubUsername1" , "GitHubUsername2"]
      "name": "production",
      "access": [
          "github_slug": "glados-team",
          "level": "view-only"
      "additional_reviewers": ["GitHubUsername3" , "GitHubUsername4"]
  "tags": {
    "application": "GLaDOS",
    "business-unit": "Platforms",
    "owner": "GLaDOS (Genetic Lifeform and Disk Operating System):"
  "github-oidc-team-repositories": [""],
  "go-live-date": ""

This will provision two AWS accounts, which will be called: glados-development, and glados-production.

This page was last reviewed on 18 September 2023. It needs to be reviewed again on 18 March 2024 by the page owner #modernisation-platform .
This page was set to be reviewed before 18 March 2024 by the page owner #modernisation-platform. This might mean the content is out of date.