{"slug": "upgrade-signoz-to-v0-143-0-with-otel-collector-v0-144-11", "title": "Upgrade SigNoz to v0.143.0 with OTel Collector v0.144.11", "summary": "SigNoz released v0.143.0, which requires self-hosted users to run signoz-otel-collector v0.144.11 with two new processors added to the traces pipeline for AI observability, and moves login sessions to opaque tokens so every user must sign in again. Users who override the collector config or pin the collector image below v0.144.11 must add the processors or stay on SigNoz v0.142.x, and those setting SIGNOZ_TOKENIZER_JWT_SECRET or SIGNOZ_JWT_SECRET must add SIGNOZ_TOKENIZER_PROVIDER=jwt before upgrading to keep JWT sessions. The upgrade requires backing up the SigNoz Metastore (SQLite or Postgres) first, and Swarm users must run docker stack rm before foundryctl cast because Swarm configs are immutable.", "body_md": "SigNoz v0.143.0 prepares the OTel collector for AI observability and moves login sessions to opaque tokens. Two things follow for self-hosted upgrades: the collector must run signoz-otel-collector v0.144.11 with two new processors in its traces pipeline, and every user signs in again once.\n\n## Who needs to act\n\n| If you | Then | \n|---|---|\n| Run the default collector config | Nothing beyond the upgrade. Sign in again afterwards | \n| Override the collector config or its traces pipeline | [Add the two processors](#add-the-ai-observability-processors-to-a-custom-collector-config) before or with the upgrade | \n| Pin the collector image below v0.144.11 | Move it to v0.144.11, or stay on SigNoz v0.142.x until you can | \n| Set `SIGNOZ_TOKENIZER_JWT_SECRET` or`SIGNOZ_JWT_SECRET` today | Your sessions move to opaque and the secret is ignored. To stay on JWT, add `SIGNOZ_TOKENIZER_PROVIDER=jwt` before you upgrade. See[Keep the JWT session provider](#keep-the-jwt-session-provider) | \n\n## Upgrade self-hosted SigNoz\n\n### Step 1: Back up your data\n\nPricing rules and attribute mappings live in the SigNoz Metastore (SQLite or Postgres) alongside dashboards and alerts. Back up the Metastore before you start. If you are more than one release behind, check the [Upgrade Path Tool](https://signoz.io/upgrade-path/) for required stops before you move to v0.143.0.\n\n### Step 2: Upgrade SigNoz and the collector\n\nUpgrade both together. SigNoz v0.143.0 requires signoz-otel-collector v0.144.11.\n\nUpgrade [foundryctl](https://github.com/SigNoz/foundry/blob/main/docs/getting-started.md) to pick up the v0.143.0 collector config, then re-apply your existing `casting.yaml`.\n\n```\ncurl -fsSL https://signoz.io/foundry.sh | bash\nfoundryctl cast -f casting.yaml\n```\n\n`cast` regenerates the collector config with the two processors when the ingester image is `latest` or a version that ships them, and keeps the previous config for an older pin. If your [casting.yaml](https://github.com/SigNoz/foundry/blob/main/docs/reference/casting-file.md) pins image versions, bump SigNoz to v0.143.0 and the collector to v0.144.11 yourself; `cast` refuses SigNoz v0.143.0 paired with a collector that cannot load the processors and tells you to move to v0.144.11.\n\nIf your casting sets `spec.config` on the ingester with its own traces `processors` list, that list replaces the generated one. [Add the two processors](#add-the-ai-observability-processors-to-a-custom-collector-config) to it.\n\nSwarm configs are immutable. `cast` cannot update the changed collector config in place, so `docker stack deploy` fails on the existing stack. Remove the stack first, then cast:\n\n```\ncurl -fsSL https://signoz.io/foundry.sh | bash\ndocker stack rm <stack-name>\nfoundryctl cast -f casting.yaml\n```\n\nThe stack is named after `metadata.name` in your `casting.yaml`, which is `signoz` in the shipped example.\n\nAll services are down between `docker stack rm` and `foundryctl cast`. `docker stack rm` removes the services and the networks, so data on named volumes is kept.\n\nUpdate the [chart](https://github.com/SigNoz/charts) and upgrade. Replace `<namespace>` and `<release-name>` with your own values:\n\n```\nhelm repo update\nhelm -n <namespace> upgrade <release-name> signoz/signoz -f <your-values.yaml>\n```\n\n`helm upgrade` takes the newest chart; add `--version 0.143.0` to pin the v0.143.0 chart. The chart's default `otelCollector.config` carries both processors. Helm replaces lists instead of merging them, so if your values file sets `otelCollector.config.service.pipelines.traces.processors`, [add the two processors](#add-the-ai-observability-processors-to-a-custom-collector-config) to your list.\n\n### Step 3: Verify the upgrade\n\n1. SigNoz and the collector are healthy (`kubectl get pods -n <namespace>` ,`docker compose ps` ,`docker stack ps <stack-name>` , or`systemctl status 'signoz-*'` ).\n2. SigNoz reports v0.143.0 under **Settings** .\n3. The collector log shows no `unknown type` error for`signozspanmapper` or`signozllmpricing` .\n\n## Add the AI observability processors to a custom collector config\n\nAdd both processors under `processors`, exactly as below. SigNoz fills `groups` and `default_pricing.rules` over OpAMP, so leave them empty here.\n\n```\nprocessors:\n  signozspanmapper:\n    groups: []\n  signozllmpricing:\n    attrs:\n      model: gen_ai.request.model\n      in: gen_ai.usage.input_tokens\n      out: gen_ai.usage.output_tokens\n      cache_read: gen_ai.usage.cache_read.input_tokens\n      cache_write: gen_ai.usage.cache_creation.input_tokens\n    default_pricing:\n      rules: []\n    output_attrs:\n      in: signoz.gen_ai.usage.input_tokens.cost\n      out: signoz.gen_ai.usage.output_tokens.cost\n      cache_read: signoz.gen_ai.usage.cache_read.input_tokens.cost\n      cache_write: signoz.gen_ai.usage.cache_write.input_tokens.cost\n      total: signoz.gen_ai.usage.tokens.cost\n```\n\nThen add both to the traces pipeline, after `signozspanmetrics/delta` and before `batch`:\n\n```\nservice:\n  pipelines:\n    traces:\n      receivers: [otlp]\n      processors: [signozspanmetrics/delta, signozspanmapper, signozllmpricing, batch]\n      exporters: [clickhousetraces, metadataexporter, signozmeter]\n```\n\nA collector with the processors defined but missing from the pipeline starts fine; token costs and attribute mapping stay off until the pipeline entries are in place.\n\n## Keep the JWT session provider\n\nSigNoz v0.143.0 issues opaque session tokens by default. Before v0.143.0 JWT was the default, so a secret alone was enough. To stay on JWT, set both before you upgrade:\n\n```\nSIGNOZ_TOKENIZER_PROVIDER=jwt\nSIGNOZ_TOKENIZER_JWT_SECRET=<your existing secret>\n```\n\nWith the `jwt` provider and no secret, SigNoz refuses to start:\n\n```\njwt::secret must be set when provider is jwt, without a JWT secret, user sessions are vulnerable to tampering and unauthorized access\n```\n\nIf you still use `SIGNOZ_JWT_SECRET`, rename it to `SIGNOZ_TOKENIZER_JWT_SECRET`. See [Configure the JWT Secret](https://signoz.io/docs/manage/administrator-guide/configuration/jwt-secret/) for details.", "url": "https://wpnews.pro/news/upgrade-signoz-to-v0-143-0-with-otel-collector-v0-144-11", "canonical_source": "https://signoz.io/docs/operate/migration/upgrade-0-143", "published_at": "2026-09-21 00:00:00+00:00", "updated_at": "2026-09-22 10:26:43.283433+00:00", "lang": "en", "topics": ["ai-infrastructure", "developer-tools", "mlops"], "entities": ["SigNoz", "signoz-otel-collector", "foundryctl", "SigNoz Metastore", "SIGNOZ_TOKENIZER_JWT_SECRET", "SIGNOZ_JWT_SECRET", "SIGNOZ_TOKENIZER_PROVIDER", "Helm"], "alternates": {"html": "https://wpnews.pro/news/upgrade-signoz-to-v0-143-0-with-otel-collector-v0-144-11", "markdown": "https://wpnews.pro/news/upgrade-signoz-to-v0-143-0-with-otel-collector-v0-144-11.md", "text": "https://wpnews.pro/news/upgrade-signoz-to-v0-143-0-with-otel-collector-v0-144-11.txt", "jsonld": "https://wpnews.pro/news/upgrade-signoz-to-v0-143-0-with-otel-collector-v0-144-11.jsonld"}}