Faster Terragrunt plans, fewer breaking upgrades

We’re rolling out a follow-up to the Platform Info file we introduced last year: customer Terragrunt application stacks are being migrated to read VPC, subnet, and EKS cluster details from k8s-clusters/<cluster>-platform-info.yaml instead of pulling them through Terragrunt dependency blocks against our private upstream networking-stack and kubernetes-stack repos. Once a customer is fully migrated, terragrunt plan and atlantis apply no longer need read access to those private repos to resolve inputs.

What changed

In your customer repo, application terragrunt.hcl files that previously had:

dependency "networking" {
  config_path = "../networking/base"
}

dependency "eks_cluster" {
  config_path = "../eks/${include.env.inputs._eks_provider_cluster_name}/cluster"
}

inputs = {
  vpc_id        = dependency.networking.outputs.vpc_id
  workers_sg_id = dependency.eks_cluster.outputs.workers_sg_id
}

now look like:

locals {
  platform_info = yamldecode(file("${get_repo_root()}/k8s-clusters/${include.env.inputs._eks_provider_cluster_name}-platform-info.yaml"))
}

inputs = {
  vpc_id        = local.platform_info.networking.vpcId
  workers_sg_id = local.platform_info.eksCluster.nodes.securityGroupId
}

The values resolved are identical and the platform-info.yaml files are kept in sync automatically when the underlying networking or EKS cluster state changes.

Why this matters

• Less breaking upgrades. This removes any hard dependency anymore, causing breaking changes when we change eg tofu versions and other internals.
• No upstream read-access required. Customer engineers (and the Atlantis runner) can plan/apply application stacks without dependencies on Skyscrapers’ private platform repos.
• Faster plans. Skipping the upstream terragrunt init/plan for resolving every dependency cuts time on every PR.
• One canonical source. All non-sensitive networking and EKS facts (VPC ID, CIDR, subnet IDs, NAT IPs, AZs, cluster name/FQDN, OIDC provider, worker SG) live in one YAML file you can cat or reference directly.

What you need to do

Nothing. Codebases are being upgraded by us. If you spot a stack that has issues, please let us know.

For details on reading from platform-info.yaml in your own stacks (full output map, when to use it vs. dependency blocks vs. terraform_remote_state), see the Terragrunt coding guidelines.