#terraform - March 2026

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?

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

Hi @everyone

I'm new to this channel.

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 🤔

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

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

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

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

yeah, just trying to get this issue over the line

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

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

Lessons learned from scaling Infrastructure as Code from 5 to 1000+ workspaces https://www.ordisi.us/posts/2026_1_scaling/

Hello. Are there any good workarounds for depends_on in data resources and cases like https://github.com/hashicorp/terraform-provider-aws/issues/29421 ? In my setup, I am trying to create a terraform aws-sso module, which not only creates AWS PS and assigns to accounts, but also creates an AD group, triggers AWS SCIM sync, and then using data resource finds the corresponding AWS SSO group id via its name. The issue is that data resource needs to depend on the AD SCIM trigger resource, which results in constant "known after apply" AWS Permission Set account assignment resource recreation due to how data resources work. I know that I can use ignore_changes lifecycle, or even separate the module into two technically, but just curious if anyone faced something similar and has some other approaches.

What’s the reasoning behind having so many of components being pinned to < 6 for the aws provider? Lambdas need a provider version 6.21> to utilize python 3.14. We’re particularly hitting this issue with the aws-datadog-lambda-forwarder component also having a requirement on the aws-datadog-credentials component.

I understand I can pull the latter locally and reference that way, but would like to see the upstream be operational if it can support it.

Sharing for visibility: https://github.com/goreleaser/goreleaser/issues/6514. Newer go-releaser versions are breaking provider signing.