How does this differ from a central infrastructure repository?

A central repo often creates organizational bottlenecks because a platform team must approve every change; service-owned infrastructure allows teams to deploy independently using shared modules as guardrails.

Does this mean service teams manage their own VPCs or networking?

No. Core networking like VPCs, subnets, and clusters remain 'Shared' resources owned by a platform team, while service teams consume these as read-only outputs via remote state.

What is service-owned infrastructure?

It is an architectural pattern where infrastructure definitions (IaC) live in the same repository as the application code, allowing the same team to manage and deploy both simultaneously.

Why version infrastructure and application code together?

Versioning them together ensures that atomic changes—such as adding a new environment variable to a container and the corresponding secret in a vault—are reviewed and deployed in a single commit.

Service-Owned Infrastructure

Name: Service-Owned Infrastructure
Author: oborchers

byoborchers

•

Infraestructura en la Nube

Empowers development teams to own their infrastructure by placing IaC definitions alongside application code for faster, independent deployments.

This skill provides Claude with the architectural guidance to implement a "Build it, Own it" model for cloud infrastructure. It helps developers structure service repositories with local Terraform directories, define the boundary between shared platform resources (like VPCs) and service-specific ones (like load balancer rules), and eliminate central deployment bottlenecks. By leveraging shared modules and remote state consumption patterns, it ensures that application and infrastructure code are versioned, reviewed, and deployed together without compromising organizational standards or security guardrails.

Características Principales

01Standardizes service repository structures with integrated infrastructure directories

02Defines clear boundaries between shared platform resources and service-owned components

039 GitHub stars

04Provides guidance on using versioned shared modules to enforce organizational guardrails

05Implements secure remote state consumption patterns using Terraform data sources

06Facilitates independent service deployments to eliminate central team bottlenecks

Casos de Uso

01Structuring a new microservice repository with its own Terraform configuration

02Migrating infrastructure code from a monolithic central repo to individual service repos

03Designing the interface between a platform team's shared resources and a service team's specific needs

Características Principales

01Standardizes service repository structures with integrated infrastructure directories

02Defines clear boundaries between shared platform resources and service-owned components

039 GitHub stars

04Provides guidance on using versioned shared modules to enforce organizational guardrails

05Implements secure remote state consumption patterns using Terraform data sources

06Facilitates independent service deployments to eliminate central team bottlenecks

Casos de Uso

01Structuring a new microservice repository with its own Terraform configuration

02Migrating infrastructure code from a monolithic central repo to individual service repos

03Designing the interface between a platform team's shared resources and a service team's specific needs