Availability
This release is no longer available to download.
The files for this release are gone and cannot be rebuilt, so we can no longer honestly offer it.
Upgrade to 1.76.2 or a later release; those remain available.
Withdrawn on . What it changed is kept below, so you can still read your way forward from a version you are running.
Breaking changes
This release contains breaking changes. Read the upgrade notes below before upgrading.
Read the marker, not the version number. Version numbers do not carry a semver major warning: a breaking change can ship in a minor release. Rely on the breaking-change marker, not on the version number.
The agent refuses to download a self-update binary over plain HTTP. Only HTTPS is accepted, plus loopback HTTP for local test harnesses.
Written by us
Before you upgrade
WHO IS AFFECTED. You are affected only if your LinkMesh server hands the agent a self-update download URL that is not HTTPS — which in practice means an on-premises or air-gapped installation serving agent binaries from an internal host over plain HTTP. If your server is reached over HTTPS, as a hosted or ingress-terminated installation is, this changes nothing.
WHAT CHANGED. The self-update binary download URL arrives over the OpAMP control channel. The agent now validates the scheme before downloading and refuses anything that is not HTTPS. Loopback HTTP remains allowed, so local test harnesses are unaffected.
UPGRADE STEPS.
- Before upgrading, check the scheme of the URL your server hands out for agent binaries. If it is
http://and not a loopback address, self-update will stop working after this upgrade. - Put the binaries behind HTTPS. A certificate from an internal certificate authority is fine; the check is on the scheme, not on who signed the certificate.
- Upgrade the agents, then trigger one self-update and confirm it completes. This is the only way to know the path still works end to end.
WHAT HAPPENS IF YOU SKIP THIS. Self-update stops. Nothing else does: the agent keeps running, keeps reporting, and keeps managing its collector. The failure is quiet and it compounds — agents simply stay on the version they are on, and you find out when you notice the fleet has not moved.
WHY THIS CHANGED. Defence in depth. It is rated low severity because exploiting it requires compromising the OpAMP control channel first — but if that happens, the difference between HTTPS and cleartext is the difference between an attacker who has to compromise your server and one who only has to sit on the network path while a binary is fetched and executed as root.
Shipped in v1.59.0, 2026-06-25.
The agent refuses to upgrade a supervised OpenTelemetry Collector. upgrade returns a refusal for one, and upgrade_all silently skips every supervised collector in the batch.
Written by us
Before you upgrade
WHO IS AFFECTED. Anyone running OpenTelemetry Collector (otelcol / otelcol-contrib) collectors under opampsupervisor in managed mode, and using the agent's upgrade commands on them. Managed Alloy collectors on remotecfg, and genuinely unmanaged runtimes, stay eligible and are unaffected.
WHAT CHANGED. The agent's upgrade and upgrade_all handlers now check whether the target is a supervised otelcol before swapping its binary.
upgradeon a supervised otelcol is refused.upgrade_allfilters supervised collectors out of the batch, and refuses outright if that leaves nothing to do.
Supervised otelcol upgrades go from the server to the supervisor over OpAMP packages instead. That path is the supported one and is unchanged by this.
UPGRADE STEPS.
- Before upgrading, check whether anything you run calls the agent's upgrade commands against otelcol collectors. If you only ever upgrade Alloy collectors, you have nothing to do.
- After upgrading, be aware that
upgrade_allnow reports a smaller number than you may expect. This is the part to watch. The supervised collectors are filtered out rather than reported individually, so a batch that used to say it upgraded twelve collectors may now say it upgraded four, with no line naming the eight it skipped. If you track fleet versions, reconcile against the collector list rather than against what the batch reported. - Upgrade supervised otelcol collectors through the server instead, which dispatches over OpAMP to the supervisor.
WHAT HAPPENS IF YOU SKIP THIS. Two different things, depending on which command you use. A single upgrade fails loudly and tells you. upgrade_all succeeds quietly and does less than it used to, which is the one that will catch you out: your supervised collectors simply stay on their old version while the command reports success.
WHY THIS CHANGED. This closed a latent crashloop. The equivalent ownership check already existed on the restart command but was missing from the upgrade handlers, so the agent could swap an OpAMP-supervised otelcol binary out from under its own supervisor. The result is worse than a version skew — and a version skew already crashloops.
Shipped in v1.71.x, 2026-07-12.
The published Kubernetes DaemonSet manifest changed its image tag from :latest to :edge, so applying it unchanged puts your agents on the internal build channel rather than the promoted release.
Written by us
Before you upgrade
WHO IS AFFECTED. Anyone who deploys the agent on Kubernetes using the DaemonSet manifest we publish at packaging/k8s/linkmesh-agent-daemonset.yaml, rather than a manifest of their own with a pinned image tag.
WHAT CHANGED. The manifest's image tag moved from :latest to :edge.
READ THE NEXT PARAGRAPH BEFORE ACTING ON THIS ONE. The change was correct when it was made and is questionable now. In July 2026 :latest was frozen on a build from 2026-06-23 — the public promotion mechanism had never successfully run — so a manifest tracking :latest deployed a stale agent, and :edge was the only tag that moved. That freeze has since been fixed and :latest now tracks the promoted release. So the manifest as published today points Kubernetes deployments at the newest internal build rather than at the release we stand behind.
UPGRADE STEPS.
- If you apply our manifest unchanged, decide which channel you actually want. For a production cluster that is almost certainly the promoted release, not the internal build stream.
- Pin the image explicitly. Replace the tag with the exact version you intend to run — for the agent that is
1.74.1— rather than either floating tag. A DaemonSet that follows a floating tag will roll your whole fleet onto a new build the next time a pod restarts, at a time you did not choose. - If you prefer a floating tag, use
:latest, which now means the promoted release, and be aware that it moves when a promotion happens.
WHAT HAPPENS IF YOU SKIP THIS. Your Kubernetes agents track internal builds. Those builds are tested and are not junk, but they have not been through a promotion, they have no changelog entry, and nobody has assessed them for breaking changes. You will be running versions this changelog says nothing about.
Which tag the published manifest should carry is under review. Until that is settled, pin the version yourself rather than relying on either floating tag.
Shipped in v1.74.x, 2026-07-23.
Security updates
No security updates in this release.
Fixes
- S-3099The shipped Kubernetes DaemonSet manifest no longer installs a stale agent image that could not report Kubernetes inventory, which had left Kubernetes onboarding empty.
Features and improvements
- S-2952The agent reports the ports listening on its host, so onboarding can offer them for one-click observation as a TCP Port Check source.