2026-07-27 SigNoz Upgrade Path Blocked on Foundry Migration

What I set out to do

Started with a nix flake update --flake nix failure, drifted into “are our pinned versions current”, and ended up scoping the SigNoz upgrade.

What I actually did

Flake update failure. nix flake update --flake nix resolved nix as the registry alias flake:nix, which the global registry maps to github:NixOS/nix, not the local directory, so it tried and failed to write a lock file into a read-only store path. Fix is a path-shaped flakeref: nix flake update --flake ./nix, or just cd nix && nix flake update. --no-write-lock-file is not a flag on nix flake update.

prek is stuck at 0.4.4 for a reason. Upstream is at 0.4.11. The bump to 0.4.10 (nixpkgs#543647) merged 2026-07-20 with base branch staging, not master. staging and staging-next both carry 0.4.10; master, nixpkgs-unstable and nixos-unstable all still say 0.4.4. So no amount of nix flake update surfaces it until the staging-next → master merge and the subsequent Hydra channel bump. 0.4.11 has no nixpkgs PR at all.

SigNoz version reality check. Running signoz/signoz:v0.129.0, signoz-otel-collector:v0.144.5, clickhouse-server:25.5.6, zookeeper:3.7.1. That v0.129.0 is the compose default (image: signoz/signoz:${VERSION:-v0.129.0}) baked into the pinned signoz-src commit 4147c5c; signoz.nix never sets VERSION. Latest OSS release is v0.134.0. There is no v0.135.0 yet: only git tags v0.135.0-cloud.1/.2 (Cloud rollout tags, no GitHub release, no Docker image). Docker Hub’s latest was re-pushed today but is digest-identical to v0.134.0.

Scanned 0.130 → 0.134 release notes for what breaks:

• 0.130.0/0.130.1 formally deprecate install.sh and the bundled deploy/ Compose. Foundry is the only supported install. Everything past 0.130.1 is untested against our topology.
• 0.131.0 publishes a ClickHouse 25.12.5 upgrade guide. Read closely it is forward-looking, not a hard gate today: a future signoz-otel-collector release moves trace attributes to a JSON column whose migration needs 25.12.5-only settings. We are on 25.5.6.
• 0.134.0 ships a migration that crash-loops SigNoz, but PostgreSQL metastores only (#12293). We are unaffected: the pinned compose sets SIGNOZ_SQLSTORE_SQLITE_PATH on a signoz-sqlite volume.

What was striking

Both version questions had the same shape, and it was the leading zero both times: prek 0.4.11 read as “4.11”, SigNoz 0.135.0 read as “1.35”. Worth remembering that neither project has shipped a 1.x.

The more useful finding is that the cheap option evaporated on inspection. Bumping VERSION=v0.134.0 on the pinned compose looked like a five-minute win, but it buys five minors of fixes and leaves the same migration outstanding, on a deployment shape upstream has stopped testing. The ClickHouse 25.12.5 jump and the Foundry migration are converging into one piece of work, and SigNoz’s own guide orders them: move to Foundry first (it reattaches volumes), then upgrade ClickHouse.

The CH jump is not free here either. 25.5 → 25.12 with ZooKeeper-backed replication is exactly where this host has burned before, twice: see 2026-07-05 SigNoz ClickHouse Replication Queue Root Cause and Graceful-Stop Fix and 2026-06-04 SigNoz ClickHouse Replication Queue CPU Burn.

Decision

Wait for v0.135.0 (release cadence has been weekly: 0.132.2 on 07-10, 0.133.0 on 07-15, 0.134.0 on 07-22, so it is likely a day or two out) and do it as one piece of work: Foundry migration + ClickHouse 25.12.5 + server bump. No stopgap 0.134 bump.

Top 3 next

1. Watch for the v0.135.0 release and its Docker image.
2. Scope the Foundry migration against deploy/MIGRATION.md: what signoz.nix stops owning once foundryctl owns the compose.
3. Back up the signoz-sqlite and ClickHouse volumes before any of it. Boot-time schema migrations are one-way.

Related

Homelab Services Architecture, Dotfiles Host Profiles via Private Flake, 2026-07-13 ClickHouse Replication Alert Was Atlas Sleeping