OpenTofu v1.11.11 - OTEL Dependency Fix

OpenTofu v1.11.11 was published on June 23, 2026, as a narrow patch release for the OpenTofu CLI and runtime. The documented fix completes an OTEL dependency upgrade that was incomplete in the previous patch release, with the change tracked in #4303. It is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

The release notes list one bug fix: an incomplete OTEL dependency upgrade from the previous patch release. That is not a feature item, and the notes do not describe a new command, provider protocol change, state format change, or migration path. It is still worth treating as an operator visible fix because OpenTofu often runs inside CI jobs where dependency behavior is part of the execution contract.

The practical concern is consistency in the telemetry dependency set. When an upgrade is only partly applied, one package can be compiled against a newer expectation while another package still reflects the older dependency graph. The release notes do not name the exact package mismatch, so the safe reading is narrow: v1.11.11 is meant to finish the OTEL upgrade work, not change the way plans, applies, or state operations are modeled.

For data platform teams, this matters around the edges of automation. OpenTofu commonly provisions buckets, warehouses, queues, IAM roles, runner hosts, and orchestration services that sit under ETL and ELT systems. If the CLI is wrapped by observability tooling in CI, a telemetry dependency mismatch can turn into noise during build, test, or apply jobs. This patch is aimed at that kind of lower layer cleanup.

The release does not claim new OTEL features. It also does not claim a change in trace shape, span names, exporter setup, or any OpenTofu configuration key. The better operational read is that v1.11.11 reduces the risk left behind by an incomplete dependency upgrade in the prior patch.

That distinction matters for rollout planning. A release that changes telemetry semantics can require dashboard review, alert tuning, or pipeline changes. This release gives no such signal. The only linked change is #4303, and the release summary frames it as a bug fix in the dependency upgrade process.

For teams that pin OpenTofu in a container image, CI base image, or tool cache, the main action is version alignment. Move the pinned version from the affected patch line to v1.11.11, then run the same plan and apply checks already used for routine patch updates. If OTEL output is collected in the pipeline, compare job logs and telemetry ingestion for regressions, but do not expect a new user facing workflow from the notes.

This is a small release by design. The release notes do not list fixes for providers, module loading, backend behavior, state encryption, test framework behavior, or HCL parsing. They also do not mention a security advisory. That keeps the scope tight, but it also means there is little reason to read extra behavior into the tag.

The most useful upgrade question is whether the previous patch release is already deployed in an automated path that depends on OTEL libraries. If yes, v1.11.11 is the obvious follow up. If not, the release can still be folded into the next normal OpenTofu patch window, with the usual checks around plan output, backend access, and CI job behavior.

The GitHub release page also links to the full changelog from v1.11.10 to v1.11.11. That comparison is useful mainly to confirm how small the patch is. There is no sign in the published notes that operators need to prepare a state migration or a workflow change.