@James Humphries how long does it generally take to for the registry to update now that #3808 merged and CI ran?

noticed https://github.com/opentofu/registry/pull/3807

yeah, just trying to get this issue over the line

@johncblandii, you shouldn't ever have to do a manual PR to bump versions. I think someone is putting together a fix now 😄

Add a PR with the missing values https://github.com/opentofu/registry/pull/3806

We’re seeing OpenTofu not sync with the repo releases. I requested access to the CNCF slack (seems that requires a human review).

I confirmed the GitHub RSS feed shows v1.32.0 but https://search.opentofu.org/provider/cloudposse/utils/latest does not.

Any thoughts?

CC @James Humphries

Hey, is there anything against implementing import of secrets and rulesets in this component?
https://github.com/cloudposse-terraform-components/aws-github-repository

Hi
does anyone know is https://github.com/cloudposse/terraform-provider-context maintained or already deprecated?

Docs are mostly not existing and no activity for half year 🤔

I'm new to this channel.

Hi @everyone

Are folks here reliably able to use manifest rendering via the terraform helm provider? What version of the provider are you using?

We make heavy use of remote-state, generally v1.8.0. Recently we've encountered an issue with our eks component. We believe there is a piece of this on Spacelift’s end that is causing the issue but was curious if anyone else using remote-state might've observed this behavior.

All Spacelift UI outputs for each of our eks stacks (>20) recently started to display sandbox values. We don't have any corresponding runs that show these being set. The stacks are failing to apply due to a lineage mismatch.

Throughout the planning phase we have multiple remote-state calls reading cross account values and we observe the workspace changing by checking terraform workspace show. I assume this might be normal for the remote-state calls to actually lookup the state values.

It seems like the last remote-state call might be to sandbox, and Spacelift isn't reading .terraform/enviroment a final time after it switches back to workspace of the actual stack we are planning. This causes Spacelift to pull the sandbox state and attempt an apply which fails. While Spacelift UI outputs are incorrect, the state file for each of our eks components are intact and don't have erroneous sandbox values.

All that said our local atmos applies succeed. So I guess the question to the group is has anyone seen an issue with remote-state ever targeting the incorrect workspace at the end of a plan/apply?

terraform-provider-utils plugin error

Hi, I am new to atmos and I was wondering what is the difference between the module vpc-peering and the component vpc-peering?
I thought the component would be building on top of the module, but that doesn't seem to be the case.
Does that mean they are maintained parallelly with the same features available?
What should I consider using in my project, the component or the module?
https://github.com/cloudposse/terraform-aws-vpc-peering
https://github.com/cloudposse-terraform-components/aws-vpc-peering

I am trying to understand how I can use cloudposse/terraform-github-repository at v1.1.0 to create sample "projects" (e.g. dotnet, python, java, HCL) with an expected directory structure

@James Humphries any insights on what the OpenTofu provider rate limits are?

@Prasanna has joined the channel

@JS has joined the channel

@Salman Shaik has joined the channel

@Deep has joined the channel

Does anyone have a reusable tool or scripts handy for bulk-moving resources from one root module to another?

I could build one, but figured I'd ask before reinventing the wheel

👋 Hello, team!

very close to crossplane

Has this been shared here? Looks promising

https://github.com/padok-team/burrito

Heya do you guys use anything else with cloudposse yaml of datadog monitors? like Kustomize,yq etc?

is there any way to use templates in workflows? I tried using a !template yaml function to apply a sprig template but it doesn't seem to work

 The following command failed to execute:

 atmos terraform plan aws_federated_access -s !template entau-{{ env STAGE }}-{{ env BRAND }}-awsapse2

Happy Friday! Thought I'd share a little blog post on some of my favorite Terraform techniques that I've picked up from the Cloud Posse community over the years. It's nothing revolutionary, but some of these tricks aren't widely used from what I've seen in the wild:

https://rosesecurity.dev/2025/12/04/terraform-tips-and-tricks.html

Hi all, looking for feedback on this PR here 🙂

https://github.com/cloudposse/terraform-aws-msk-apache-kafka-cluster/pull/143

Hi guys, what is the future of account-map component? We've noticed a bit about it being deprecated?

Hey folks, I built a new Kubernetes Terraform provider that might be interesting to you.

It solves a long-standing Terraform limitation: you can't create a cluster and deploy to it in the same apply. Providers are configured at the root, before resources exist, so you can't use a cluster's endpoint as provider config.

Most people work around this with two separate applies, some use null_resource hacks, others split everything into multiple stacks. After being frustrated by this for many years, I realized the only solution was to build a provider that sidesteps the whole problem with inline connections.

Example:

resource "k8sconnect_object" "app" {
  cluster = {
    host  = aws_eks_cluster.main.endpoint
    token = data.aws_eks_cluster_auth.main.token
  }
  yaml_body = file("app.yaml")
}

Create cluster → deploy workloads → single apply. No provider configuration needed.

Building with Server-Side Apply from the ground up (rather than bolting it on) opened doors to fix other persistent community issues with existing providers.

• Accurate diffs - Server-side apply dry-run projections show actual changes, not client-side guesses
• YAML + validation - K8s strict schema validation catches typos at plan time
• CRD+CR same apply - Auto-retry handles eventual consistency (no more time_sleep)
• Patch resources - Modify EKS/GKE defaults without taking ownership
• Non-destructive waits - Timeouts don't force resource recreation
300+ tests, runnable examples for everything.

GitHub: https://github.com/jmorris0x0/terraform-provider-k8sconnect
Registry: https://registry.terraform.io/providers/jmorris0x0/k8sconnect/latest

Would love feedback if you've hit this pain point.

anyone know how to go about destroying a specific resource deep in the modules without making a mess...?

in this case i would like to destroy module.service_b.module.ec2 ...

module "service_a" {
   source = "../modules/stuff"
...
}

module "service_b" {
   source = "../modules/stuff"
...
}

...

# modules/stuff

module "ec2" {
   source = "../modules/ec2"
}
...
... some more stuff

i thought this was pretty trivial until i step thru the tf plan, but i dont think this is doable by messing with hcl itself, instead...

terraform destroy --target module.service_b.module.ec2
terraform state rm module.service_b.module.ec2

any other suggestions...?

Hello team! 👋

I'm hitting a perpetual diff on various resources originating from the GitHub Provider, used in the aws-argocd-github-repo component. Specifically, the etag property is constantly changing on the GitHub's API side, creating ever-changing plans. Those plans are failing to apply via gitops with plan files have differences.

I found our that recently, this PR was merged, which directly addresses handling of etags on the GH provider. Is my understanding correct that the issue should resolve on its own once the change gets released (currently it is not)? Are you aware of any other workaround here? (fyi. ignore_changes on etag does not work)

I'm trying to build a tool which require, terraform core's connectivity, using RPC
!!not building a plugin, its like a standalone software that imports terraform core and compares files,
but didn't found any content on youtube, i really do even know how to initiate this project.

i am an intern BTW!

👋 I'm trying to figure out what I am doing incorrectly when using the default_security_group_deny_all variable with the terraform-aws-vpc module.

I have several VPCs already created from this module and am working towards removing the default VPC security group default egress & ingress rules. I thought I would be able to do this by simply adding the default_security_group_deny_all variable to my existing Terraform with a value of true and just redeploying my Terraform, however when I make a PR with those changes, my Terraform plan shows 0 changes to be made.

If I set the value to false I see the default security group being removed (I imagine by setting this to false I'll need to make a moved block indicating that I am now managing this security group as part a different Terraform resource), but that's not what i want to do.

Why does setting this value to true not seem to do anything for already created default VPC security groups?

Hi CloudPosse team - Any chance we can get an issue to update Terraform awsutils - https://github.com/cloudposse/terraform-provider-awsutils

Updated such that the corresponding awsutils resources support a region parameter? Basically, similar to the AWS 6.0 Terraform provider?

---

Use Case: We now pass in ~15 awsutils providers each with separate regions to delete VPCs for all these regions. It would be amazing to loop over with a region parameter.

Good morning, I've been a longtime fan of the CloudPosse architecture as we used it at one of my former roles. While I was overseeing our architecture at the time, I was not the person that actually set up the original accounts a few year ago. As a result, I'm taking some time to go through the process myself so I can set things up in the future. I'm making really solid progress but seem to have run into a wall and could really use some help.

I've been working through the foundation documents on my own. I'm currently in the Deploy Accounts (https://docs.cloudposse.com/layers/accounts/deploy-accounts/) stage. I've run everything through Step 6 deploying the accounts and account map.

I'm now trying to apply the account-settings module and its failing with two instances of the The given key does not identify an element in this collection value. error. The docs mention that this is usually due to a mismatch of the root_account_aws_name in the account-map. I've confirmed that multiple times and have it set to root. For this troubleshooting, let's assume we are trying to apply the account-settings for the audit account which is called core-audit. The account-settings module appears to be looking for the audit index instead of core-audit.

I've tried setting audit_account_account_name to both core-audit and audit, neither of which are working. I believe the value should be core-audit. Where else could I be going wrong?

FWIW, I've confirmed I'm using the latest versions of all the modules.

Thanks for any suggestions!

I imagine I could create a x-account trust policy like this:

data "aws_iam_policy_document" "xaccount_trust_policy" {
  provider = aws.destination
  statement {
    actions = [
      "sts:AssumeRole",
      "sts:TagSession",
      "sts:SetSourceIdentity"
    ]
    principals {
      type        = "AWS"
      identifiers = ["arn:aws:iam::${data.aws_caller_identity.source.account_id}:root"]
    }
  }
}

but I don't think you can apply it to the permissionset that is being created on the AWS destination account side

👋 I am using the https://github.com/cloudposse/terraform-aws-sso/ module to create permission_sets and assign them to AWS accounts, pretty standard stuff.

I would like to try and customize the trust policy associated with a permissionset to allow for assuming the role in one AWS account, from another AWS account within the same Org, but I'm not finding much to go on as far as examples go in this repo.

I am trying to setup something that would allow users that have been assigned a role in AWS permissions to copy items from an S3 bucket in Account A to an S3 bucket in Account B, within the same region, similar to what's goin gon here: https://stackoverflow.com/questions/73639007/allow-user-to-assume-an-iam-role-with-sso-login

the problem I am running into is I am finding nowhere to actually configure the contents of thePermissionSet Trust Policy, is that just something that is outside of the scope of the terraform-aws-sso module?

Would it be interesting if Cloud Posse offered something like a commercial "Bug Fix Insurance" across our module ecosystem?

Hi! Is there an open source SQS module from cloudposse out there? I was checking the sqs-queue one but it's not listed in their modules library and I couldn't use it directly in tf

Hey guys, what is the procedure to add or update components in https://github.com/cloudposse-terraform-components ?

For example, if we want to add some features to a component, or we have a completely new component - do we need to ask and discuss somewhere first? Or just send PRs? or..?

Hi, I'm using the ECR aws module (https://registry.terraform.io/modules/cloudposse/ecr/aws/latest). I would like some clarification on the max_image_count and protected_tags_keep_count parameters.
1. Does the max_image_count exclude the images with protected tags?
2. Is the protected_tags_keep_count per unique tag?
We've had some issues with deployed tags being cleaned up and I want to make sure I fully understand these 2 settings. Thanks.

Office Hours ran long (always worthwhile, thank you to CloudPosse and everyone who contributes!), so I didn't get to ask this question…

What Terraform version adoption statistics have people found? I want to balance compatibility and modernity when distributing open-source modules. Would I be shooting myself in the foot with minima of v1.10 of Terraform from November, 2024 (S3 state without DynamoDB) and v6.0 of the AWS provider from June, 2025 (multi-region without repetition), because typical users are slow to upgrade?

At work, in multiple, fairly large shops, I'm ecstatic 🥲 when I see Terraform v1.x and AWS provider v5.

Thanks for any advice!

Has anyone found a way to destroy/terminate namespaces created by the Terraform resource kubernetes_namespace when they get stuck in the Terminating state?
Right now, the only thing that seems to work is manually clearing the finalizers, like this:
kubectl get ns "$ns" -o json | jq 'del(.spec.finalizers)' | kubectl replace --raw "/api/v1/namespaces/$ns/finalize" -f -

Just wondering if anyone's found a cleaner or automated way to handle this by terraform ?

Hey Guys, haven't updated my terraform for a few years, whats the best practice for this:
using terragrunt, trying to get clean tflint output etc.
directories are like:
domains/domain1.com/main.tf
domains/terraform.tfvars
production/productionapp1/main.tf
production/terraform.tfvars
modules/

I am currently using domains/terraform.tfvars to define various security rules/whitelist IPs, that are used in some domains, but not all, So if I don't define/use them in each domain folder, terraform or tflint show a warning about it.

Should I just disable the linting rules for that? or else I'm considering a modules/shared_variables and then domain1/main.tf can use shareD_variables.whitelist_ips if it needs to, and it shouldn't throw warnings about unused outputs.

Hey guys, looking to get some help with this terraform module

https://github.com/cloudposse/terraform-aws-codebuild/tree/main

I am creating codebuild projects using atmos and the above module
it's creating the env vars by default which i have not defined and i'm unable to exempt them. any ideas??
the env vars that it currently adds

AWS_REGION
us-east-1
PLAINTEXT

AWS_ACCOUNT_ID
11111111
PLAINTEXT

IMAGE_REPO_NAME
UNSET
PLAINTEXT

IMAGE_TAG
latest
PLAINTEXT

I want to exempt IMAGE_REPO_NAME and IMAGE_TAG variables

If anyone able to provide any guidance?