When teams need shared infrastructure modules, environment configurations, and a common place to inspect changes, a single repository keeps those pieces together. It suits smaller estates with tens of modules and a few environments, while exposing the whole infrastructure layout to every team. section 5.1.1 section 5.1.3
A single repository structure, also called a monorepo, stores all infrastructure-as-code configuration and modules for a team or function in one code repository. A common layout separates modules from environments, then separates development and production configurations within each team or environment. section 5.1.1
Apply the pattern with a deliberately visible structure:
- Create a top-level modules directory for reusable server, network, database, tagging, or tool-specific components. section 5.1.1
- Create environments directories for teams or deployment stages, separating development and production configurations. section 5.1.1
- Reference local modules by path, allowing configurations to compose infrastructure without publishing every module separately. section 5.1.1
- Compare environment files in one place to identify differences, while accepting that cost and resource constraints can justify some variation. section 5.1.3
- Add versioning, specialized build systems, and governance before unrestricted module changes or recursive CI checks become disruptive. section 5.1.3 section 5.5
Local modules for production infrastructure
A production configuration adds the modules directory to Python's path, imports database, server, and network factory modules, constructs them with a shared name and environment, and combines their outputs into one resource configuration. The same repository can organize team environments under environments and provider-specific implementations under modules. section 5.1.1
Figure 5.2 The Leafy Greens team’s production and development environments use the directories containing server, network, and database factory modules in a single repository structure.
Use the repository diagram to see how development and production environments consume server, network, and database factory modules. section 5.1.1
The pattern preserves composability, evolvability, and reproducibility, but shared visibility also increases blast radius: an ungoverned module change can break dependent configurations, and CI may struggle to process every directory. When scale or access-control needs exceed the build system, split modules or domains into multiple repositories and version released artifacts. section 5.1.3 section 5.5
