# Upgrade SigNoz to v0.143.0 with OTel Collector v0.144.11 > Source: > Published: 2026-09-21 00:00:00+00:00 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. ## Who needs to act | If you | Then | |---|---| | Run the default collector config | Nothing beyond the upgrade. Sign in again afterwards | | 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 | | Pin the collector image below v0.144.11 | Move it to v0.144.11, or stay on SigNoz v0.142.x until you can | | 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) | ## Upgrade self-hosted SigNoz ### Step 1: Back up your data Pricing 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. ### Step 2: Upgrade SigNoz and the collector Upgrade both together. SigNoz v0.143.0 requires signoz-otel-collector v0.144.11. Upgrade [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`. ``` curl -fsSL https://signoz.io/foundry.sh | bash foundryctl cast -f casting.yaml ``` `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. If 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. Swarm 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: ``` curl -fsSL https://signoz.io/foundry.sh | bash docker stack rm foundryctl cast -f casting.yaml ``` The stack is named after `metadata.name` in your `casting.yaml`, which is `signoz` in the shipped example. All 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. Update the [chart](https://github.com/SigNoz/charts) and upgrade. Replace `` and `` with your own values: ``` helm repo update helm -n upgrade signoz/signoz -f ``` `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. ### Step 3: Verify the upgrade 1. SigNoz and the collector are healthy (`kubectl get pods -n ` ,`docker compose ps` ,`docker stack ps ` , or`systemctl status 'signoz-*'` ). 2. SigNoz reports v0.143.0 under **Settings** . 3. The collector log shows no `unknown type` error for`signozspanmapper` or`signozllmpricing` . ## Add the AI observability processors to a custom collector config Add both processors under `processors`, exactly as below. SigNoz fills `groups` and `default_pricing.rules` over OpAMP, so leave them empty here. ``` processors: signozspanmapper: groups: [] signozllmpricing: attrs: model: gen_ai.request.model in: gen_ai.usage.input_tokens out: gen_ai.usage.output_tokens cache_read: gen_ai.usage.cache_read.input_tokens cache_write: gen_ai.usage.cache_creation.input_tokens default_pricing: rules: [] output_attrs: in: signoz.gen_ai.usage.input_tokens.cost out: signoz.gen_ai.usage.output_tokens.cost cache_read: signoz.gen_ai.usage.cache_read.input_tokens.cost cache_write: signoz.gen_ai.usage.cache_write.input_tokens.cost total: signoz.gen_ai.usage.tokens.cost ``` Then add both to the traces pipeline, after `signozspanmetrics/delta` and before `batch`: ``` service: pipelines: traces: receivers: [otlp] processors: [signozspanmetrics/delta, signozspanmapper, signozllmpricing, batch] exporters: [clickhousetraces, metadataexporter, signozmeter] ``` A 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. ## Keep the JWT session provider SigNoz 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: ``` SIGNOZ_TOKENIZER_PROVIDER=jwt SIGNOZ_TOKENIZER_JWT_SECRET= ``` With the `jwt` provider and no secret, SigNoz refuses to start: ``` jwt::secret must be set when provider is jwt, without a JWT secret, user sessions are vulnerable to tampering and unauthorized access ``` If 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.