Terraform Enterprise 2.1 moves VCS ingress into your agents. What to change before October 2027

Terraform Enterprise 2.1 switches off open sign-up and hands the job of pulling code from GitHub or GitLab to your agents. It also starts a clock: built-in Fluent BitdefinitionAn open-source tool that collects logs and forwards them somewhere else. Terraform Enterprise carries its own copy for this, and HashiCorp stops supporting it in October 2027. log forwarding and the old ingress fallback stop being supported in October 2027. Decide now whether you fix agent networking and log shipping before you upgrade, or use the fallback year to do it.

Nothing in 2.1 deletes workspaces or changes how a plan works. The risk sits at the edges of the platform: who can create an account, whether runs still find their code after the upgrade, and whether audit logs still reach your SIEM. Those are the spots where an upgrade fails quietly, and auditors care about the first and the last.

The October 2027 date sets the budget. If your agents can't reach your VCS servers today, someone has to change firewall rules, proxy settings or Kubernetes network policies before the fallback goes away. If logs leave through the built-in Fluent Bit, someone has to build log shipping on the platform side. Both jobs usually need people outside the Terraform team, which is why they slip.

HashiCorp's release notes describe this change twice, and the two entries read differently. The breaking-changes entry says your agents must be able to reach your VCS servers, and tells you to set TFE_VCS_INGRESS_SLUG_INGRESS_FALLBACK to true and restart if you need 2.0 behavior while you update network rules. The improvements entry says slug-ingressdefinitionThe service that used to clone repositories for Terraform Enterprise and pack them up for runs. In 2.1 it only steps in as a fallback, and support for that ends in October 2027. still runs as a fallback, so upgrading needs no configuration change. Plan for the stricter reading. Open the route from the agents to VCS before the upgrade, or set the variable on purpose and write down when it comes out.

There's a security reason to care where this work runs. HashiCorp's bulletin HCSEC-2026-17 covered a flaw in VCS ingestion of registry modules. Someone allowed to publish a module could pull files from outside the repository into it and download them, including configuration and secrets the ingestion process could read. 2.0.4 and 1.2.4 fixed it. Now that ingestion moves into agent jobs, check what an agent can read and which networks it can reach.

Sign-up is the change that bites first if nobody knew you relied on it. Instances on SAML see no difference. Without SAML, new engineers who used to create their own account from the sign-up page will find it stops working on upgrade day. A site admin can turn Enable public registration back on, but for a platform that can change production infrastructure, invitations or SSO are the safer default. Make turning it back on a decision someone signs off on.

The UBI move only matters if you built your own image. HashiCorp's notes are blunt: IBM doesn't support custom Terraform Enterprise images and wants you on the official, unmodified one. If you baked tools or settings into an image, move what you can into configuration, and talk to your IBM account team about whatever's left.

Fluent Bit is the slow one. Built-in forwarding still works in 2.1, so nothing is urgent. But HashiCorp's logging docs also warn that without forwarding, audit logs can be lost when logs rotate. If audit events reach your SIEM through Fluent Bit today, get the replacement running and checked before you remove the old config, or you'll have a hole in the audit trail.

One more item isn't in the 2.1 notes at all. HashiCorp's 2.0.0 notes said Redis 6.2 and 6.4 had reached end of life and that Redis 6.x support would be removed in 2.1.0. Check your Redis version before you upgrade. 2.1 lists Redis 8 and Valkey 9.0 as supported, and 2.1.1 fixes a bug where Terraform Enterprise still sent a Redis password with TFE_REDIS_USE_AUTH set to false.

# Check the path to VCS from where the agents run. If this hangs, ingress jobs will hang too
$ kubectl -n <agents-namespace> run vcs-check --rm -it --restart=Never --image=curlimages/curl -- curl -sI https://git.example.com
# Is public registration on? Needs a site admin token
$ curl -s -H "Authorization: Bearer $TFE_TOKEN" https://tfe.example.com/api/v2/admin/general-settings | jq '.data.attributes["enable-public-registration"]'
# Keep 2.0 ingress behavior while the network change waits (then restart)
TFE_VCS_INGRESS_SLUG_INGRESS_FALLBACK=true

For identity teams, most of 2.1 is good news. Certificate rotation used to be a two-certificate dance, one active and one temporary during the rotation window. Now Terraform Enterprise keeps a list and checks each SAML response against all of them. You can load the new certificate days ahead, run two identity providers side by side during a migration, or have each region sign with its own certificate.

Site AuditordefinitionA read-only Terraform Enterprise role that sees across all organizations for audit and security work, without access to sensitive data such as state files. access is the other gain. 2.0 added the read-only role for audit and security work. In 2.1 your identity provider can grant and remove it through a SAML attribute or role, or through a SCIM group when SCIM is on. Auditor access then follows the same joiner and leaver process as everything else, and nobody can hand it to a service account.

Tokens get attention too. People get emails 30 and 7 days before a user, team, audit or organization token expires, and site admins can see and revoke any user's API tokens. If your policy says no long-lived personal tokens, you now have somewhere to enforce it.

Machine identity gets better on Kubernetes. With workload identitydefinitionThe pod proves who it is with a short-lived token from the cloud platform, so nobody stores a password or key for it. 2.1 documents it for EKS, GKE and AKS. on EKS, GKE and AKS, Terraform Enterprise pods reach PostgreSQL, Redis and object storage without stored passwords or keys. That's one less set of secrets to rotate. On AKS, set the object storage variable yourself now that auto-detection is deprecated.

How Cohash helps: we plan and run Terraform Enterprise upgrades with your platform team, including the network, logging and SSO changes 2.1 brings, and we can weigh staying self-hosted against HCP Terraform or OpenTofu. Read how we work on our Terraform page, where you can also hire Terraform engineers, look at our DevSecOps practice, or book an assessment. For the licence and cost side, read what IBM ownership means for Terraform and Vault.