Table of contents

The GDS Way and its content is intended for internal use by the GDS community.

The GDS Way

The GDS Way documents the specific technology, tools and processes that GDS teams use to build and operate the services GDS is responsible for, you can find out about them in the Service toolkit.

We’re sharing it openly because we hope it’s useful for people to see how we do things. But it’s not intended as guidance for anyone working outside GDS - you’ll find that in the Service Manual.

About The GDS Way

In the early years of the Government Digital Service, development teams chose how to build their services, picking the most suitable tools and approaches for their projects. Now we’re at the point where having some agreed ways of working for new teams is helpful. Some of the things we’re hoping to achieve with these agreed ways of working are:

  • use of similar tools across GDS
  • procurement once centrally for GDS
  • costs savings because new teams will be cheaper to spin up

The phrase we use for these agreed ways of working is The GDS Way. This guidance will make it easier for projects to get started while still giving teams flexibility to do something different if their project needs it.

The GDS Way includes:

  • consistent terminology
  • consistent ways of working
  • consistent technology and tools
  • consistent measures

This site documents some of the decisions agreed by the Tech Ops Forum about products we operate. The decisions are made in alignment with Service Manual which covers service design more broadly.

Products at GDS in discovery or alpha development phases must follow instructions set out in the Service Manual and also have the option to follow the standards in this repository.

Products in beta and live phases must follow both the instructions set out in the Service Manual and the standards in this repository.


Standards are based on formal decisions made by the tech forum. The standards have an expiry date to ensure we review our decisions and assess whether they are still working for GDS as an organisation.

Building software

The following standards will help you name your service, choose an appropriate programming language and where to store your code:

Operating services

These standards will enable us to maintain a consistent operating environment across our services:


Manuals are informative guides, not necessarily based on any formal decision or standard:

Adding new guidance

We’d like to thank all contributors for their suggestions as we continue to develop this repository, so we can seek the best way to build and operate our services enabling us to deliver at scale.

If you think you can contribute a change to this repository which reflects current practice at GDS, make a pull request in GitHub and we’ll discuss it at the Tech Ops Forum meeting and in the #gds-way Slack channel.

Alternatively contact us by email.

When you create a new Markdown file please ensure it follows this pattern and make a pull request:

title: Thing you're writing a standard about
expires: yyyy-mm-dd (6 months from now)

# <%= %>

<%= partial :expires %>

Introduction of a couple of paragraphs to explain why the thing you're
writing a standard about is important.

## User needs

Why do we do this thing? Who is it helping?

## Principles

What broad approaches do we follow when we do this thing?

## Tools

What specific bits of software (commercial or open source) do
we use to help us do this thing?

The service manual has some useful information on learning about and writing user needs.