Terraform Modules at Super

Nov 1, 2025

Engineering

Like most startups, we use Terraform to manage and deploy our infrastructure. This post covers how we use Terraform modules at Super to adhere to the DRY principle.

Early in our Terraform refactor, we aimed to invest in modules. Our goal was to promote high reusability while minimising code.

At the time of writing, Super has around 70 Terraform modules in use across 10 providers. Some of the modules are small (e.g. IAM Role) and some are larger (e.g. EKS Cluster).

Template Module & Code Style 📝

In order to keep module creation in line with a style guide we have a template module. Some of the rules below are best practice and some are specific to Super.

We don't include provider configurations
We don't include any backend configuration
data.tf file is used for all data resources
outputs.tf file is used for all output resources
variables.tf file is used for all variables
versions.tf file is used for required_providers and required_version

Why no provider?! 😱

The primary reason we avoid including a provider in our modules is to facilitate nesting modules. Nesting modules can be beneficial to keep resources used in a standardised format across modules.

When using a module inside of a module Terraform deems it incompatible with count, for_each, and depends_on if the module in question has its own local provider configuration.

We started out only removing the providers of modules nested, but decided that we can make use of Terragrunt's generate and include to remove providers from all modules.

Let's take the following directory structure for AWS as an example. We have a folder for the AWS region (eu-west-2) and we also have a few hcl files.

The aws.hcl file uses a Terragrunt generate block to arbitrarily generate a file in the terragrunt working directory (where terraform is called).

generate "aws" {
  path      = "aws.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider "aws" {
  region = "eu-west-2"
  default_tags {
    tags = {
      environment = "staging",
    }
  }

When using a module with Terragrunt you can then use the include block with the find_in_parent_folders function.

include "aws" {
  path   = find_in_parent_folders("aws.hcl")
}

terraform {
  source = "git@github.com:organisation/terraform-example-module.git?ref=v1.0.0"
}

Remote State

We use S3 as our state store along with DynamoDB for locking all encrypted with KMS.

The terragrunt.hcl at the root of the directory includes three things. The terragrunt remote_state block, iam_role and some default inputs.

remote_state {
  backend = "s3"

  generate = {
    path      = "backend.tf"
    if_exists = "overwrite"
  }

  config = {
    bucket                = "super-staging-eu-west-2-example-bucket"
    key                   = "${path_relative_to_include()}/terraform.tfstate"
    region                = "eu-west-2"
    encrypt               = true
    dynamodb_table        = "super-staging-eu-west-2-example-table"
    kms_key_id            = "alias/s3-super-staging-eu-west-2-example-kms"
    disable_bucket_update = true
  }
}

iam_role = "arn:aws:iam::<snip>:role/example-role"

inputs = {
  environment    = "staging"
  aws_account_id = "<snip>"
  service_owner  = "devops"
}

We then add the include like we do with the AWS provider. By default find_in_parent_folders will search for the first terragrunt.hcl file.

include "root" {
  path   = find_in_parent_folders()
  expose = true
}

Versioning 🔢

Our Platform team are enthusiasts of semantic versioning and we also use conventional commits.

We have a simple Github Action job on each module repository that uses the semantic-release-action. We use the @semantic-release/commit-analyzer plugin with the conventionalcommits preset.

      - name: Release
        uses: cycjimmy/semantic-release-action@v4
        with:
          semantic_version: 23.0.2
          extra_plugins: |
            @semantic-release/changelog@6.0.3
            @semantic-release/git@10.0.1
            conventional-changelog-conventionalcommits@7.0.2
        env:
          GITHUB_TOKEN

Luke Livingstone, Engineering

Read

Improve DBT Incremental Performance on Snowflake using Custom Incremental Strategy

March 3, 2026

Data

Read

Setting Up a Robust Local DevX for Snowflake Python Development

February 2, 2026

Data

Read

The Impact of AI on Organizations

January 5, 2026

Engineering

Read

The Future of Payments in the UK

October 13, 2025

Case Study

Read

What's the Best Payment provider in the UK?

September 5, 2025

Super Thinking

Read

PayPal Alternatives for 2025: What’s Better for UK Businesses?

April 30, 2025

Super Thinking

Read

What 2% Fees Actually Cost Your Business Over Time

May 30, 2025

Super Thinking

person using laptop computer holding card

Read

Cheapest Payment Processors for Ecommerce Stores in the UK

July 30, 2025

Super Thinking

Read

Buy Now Pay Later Without the 5% Fee: How Super Credit Gives UK Businesses a Competitive Edge

June 30, 2025

Super Thinking

Super Payments Limited is a private limited company with company number 13903817. Open banking payments are powered by Yapily Connect Limited and Modulr FS Limited. Yapily Connect Limited is authorised and regulated by the UK Financial Conduct Authority under the Payment Services Regulations 2017 (Firm Reference 827001). Super Payments Limited is a distributor of Modulr FS Limited, a company registered in England and Wales with company number 09897919, which is authorised and regulated by the Financial Conduct Authority as an Electronic Money Institution (Firm Reference Number: 900573) for the issuance of electronic money and payment services. Your business account and related payment services are provided by Modulr FS Limited. Super Payments Information Security Policy is available on request. Whilst Electronic Money products are not covered by the Financial Services Compensation Scheme (FSCS), business funds will be held in one or more segregated accounts and safeguarded in line with the Electronic Money Regulations 2011 - more information. Card payments and business accounts are powered by Stripe Payments UK Limited. Stripe UK Payments Ltd is authorised and regulated by the Financial Conduct Authority (Firm Reference: 900461) as an Electronic Money Institution (Firm Reference Number: 900573) for the issuance of electronic money and payment services.

Super Credit is provided by Abound (see below) and is subject to status. Super is not a lender. Terms apply. Fintern Ltd, trading as Abound, is registered in England & Wales No. 12472034 and is authorised and regulated by the Financial Conduct Authority, FRN 929244. Fintern Ltd, 3rd Floor, 86-90 Paul Street, London, EC2A 4NE. Super Payments Limited, trading as Super and Super Payments, is an Introducer Appointed Representative (FRN 1034245) of Abound and may receive commission for introductions. Missed payments may affect your credit score.

Business address at 123 Buckingham Palace Road, London, SW1W 9SH.