thoughtbot/flightdeck: a consultancy's Terraform modules, split by platform

These are the modules they run for clients

The positioning statement is short and worth reading as a positioning statement. The modules are provided by thoughtbot, and they are described as the modules the company uses when following SRE practices for its clients, with the claimed benefits being the ability to scale an application, improve stability, and increase the rate of defect-free deployments. There is a link to the company's site reliability service page rather than to independent documentation. So the repository is a consultancy publishing the configuration it applies in production work, which is a different proposition from a community module with a maintainer rota: the audience is teams who want the same shape of cluster, and the implicit support path is the consultancy relationship rather than an issue tracker.

Pick aws/ or platform/ before you read anything else

The deployment section is three lines long and consists of two links, which tells you the whole structure of the repository. Detailed install instructions live in the AWS Platform Guide on the company's website, and the repository itself splits into two trees: an `aws` directory with its own README, and a `platform` directory with its own README, labelled as the option for other platforms. There is no combined entry point, no quickstart in the top-level README, and no module index. In practice you choose a tree first and then work from that tree's documentation, with the hosted guide as the shared reference underneath both.

The footer is injected from a template file

The bottom of the README is delimited by HTML comments reading START and END around a path to a footer template, which means the block about the company is generated rather than maintained by hand. Inside it the repository states that it is maintained and funded by the company, that its names and logos are trademarks, and that the company is available for hire, with links to other projects and to the hiring page carrying campaign parameters. This is worth noting for two reasons. First, it is the clearest statement of maintenance in the whole file, and it sits in generated content rather than in prose someone chose to write about the modules. Second, it tells you the README is assembled from parts, so the visible top-level text is not the full extent of what the repository maintains.

Linting and module documentation are configured in the repo

Two configuration files at the top level tell you how the modules are kept honest. A TFLint configuration in HCL is present, which is the linter for Terraform code, so style and provider rules are enforced by tooling rather than by review comments. A terraform-docs configuration is also present, which is the generator that produces module documentation from the module code itself. The consequence is that the READMEs inside the module trees are most likely generated rather than written, so if you are looking for design rationale you may find it in the module code and its inputs rather than in prose, while if you are looking for the parameter list it will be complete and up to date.

The makefile is a file plus a directory of includes

There is a lowercase makefile at the root and a `makefiles` directory beside it, which is the usual shape for a repository where the developer targets have outgrown one file and been split into fragments that the top-level make includes. A `bin` directory sits alongside them for the scripts those targets call. None of this is documented in the README, which only points at CONTRIBUTING.md for development and at TESTING.md for the testing details, so the practical route for contributors is to read the makefile to discover the targets rather than to expect a list of them. The convention of lowercase filenames is worth internalising early if you plan to contribute, since every file at the root follows it.

Charts, tests and documentation each have an entry

Three more root entries describe how the modules reach a cluster. A `charts.json` file sits at the top level, which points to Helm charts being part of the picture rather than Terraform being the only artifact, and a `docs` directory holds generated documentation. A `tests` directory exists alongside a separate TESTING.md that the README links to for details on how the project is tested, so the testing approach is documented in its own file rather than in the module docs. And a `.tool-versions` file is checked in, which is the convention for pinning the toolchain version used by version managers, meaning contributors are expected to use the same versions rather than whatever their own machine defaults to.

Copyright names two authors and there are no releases

The licensing statement is more specific than the MIT identifier in the repository metadata. The project is copyright 2022 Joe Ferris and thoughtbot, described as free software that may be redistributed under the terms in the LICENSE file. The governance surface is correspondingly complete for an infrastructure repository: CODEOWNERS, a code of conduct, a security policy and a contributing guide are all present, along with a GitHub directory. What is missing is versioning. The repository publishes no GitHub releases, so consumers cannot ask for a module version and there is no upgrade path to follow. The last push to main is dated 2026-09-23, which tells you the modules are being changed, but pinning to a commit is the only way to hold a cluster configuration still.

Editorial conclusion

Use Flightdeck if you are standing up Kubernetes on AWS with Terraform and want the module layout a consultancy has already standardised on, and read the AWS tree's own README rather than the top-level one, which contains almost no instructions. Two things to check before you commit. Nothing is versioned by release, since the repository publishes none, so you would pin a commit rather than a tag. And the testing story lives in a separate document, so confirm what TESTING.md covers before assuming the modules are exercised the way your own infrastructure is.

Frequently asked questions

Official sources

1. Official README
2. Project repository