[release] ChirpStack v4.7 test releases


Important note before you upgrade:

This release moves the device-session storage from Redis to PostgreSQL. After upgrading, you must execute the following command (adapted to your environment):

chirpstack -c /etc/chirpstack migrate-device-sessions-to-postgres

This command will iterate over the devices in the PostgreSQL database of which the device-session column is empty and will migrate the device-session from Redis if it exists. This will not overwrite existing device-sessions in PostgreSQL thus it is safe to re-execute this command in case needed.


MQTT shared subscription

This by defaults connects to the MQTT broker using a shared subscription name chirpstack. Using a shared subscription, the MQTT broker will send a received uplink only to one subscriber. In case ChirpStack is deployed as a cluster, this removes the overhead caused by all instances receiving the same uplink (which would be correctly handled by the deduplication logic).

In case you have multiple ChirpStack environments (e.g. production, staging and testing) connected to the same MQTT broker, then make sure that each environment has a correct share_name configured in the region_XXXXX.toml configuration.


Store device-sessions in PostgreSQL

This moves the device-session storage from Redis to PostgreSQL. In case of a high DevAddr re-usage (where multiple DevEUIs share the same DevAddr), the old architecture had a significant overhead, because it would perform a significant amount of Redis queries to retrieve all the potential device-sessions. It would retrieve the DevAddr → DevEUIs mapping, and then retrieve the device-session for each DevEUI. Because device-session data can be sharded (Redis Cluster), a separate query per device-session was required.

With this improvement, a device-session column has been added to the device table in the PostgreSQL database, which also contains a DevAddr column. The big advantage is that all device-sessions for a given DevAddr can be retrieved using a single query.

This improvements also means that:

  • Device-sessions will no longer expire after device inactivity
  • Device-sessions can be restored from a PostgreSQL backup

Replace OpenSSL with Rustls

This is an internal improvement and removes the OpenSSL dependency in favor of Rustls, which is a pure Rust TLS implementation. This makes the build process easier as it is no longer needed to build a (static) OpenSSL version to link against.

Use async PostgreSQL

This is an internal improvement, and migrates away from pq-sys in favor of tokio-postgres, which is a pure Rust client implementation which works with async. This removes all task::spawn_blocking(...) blocks around SQL queries. As well, we no longer need to static link against libpq (C library, with dependency on OpenSSL).

Important note: this also adds a new ca_cert option to the [postgresql] configuration section where you can configure the CA certificate which must be used for validating the PostgreSQL server certificate.

Use async Redis

This is an internal improvement and updates all Redis queries to use async / await and removes all task::spawn_blocking(...) blocks around Redis queries.

Paho MQTT > rumqttc client

This is an internal improvement and replaces paho-mqtt with rumqttc. The latter crate is a pure Rust client which uses rustls for TLS instead of OpenSSL.


  • Update dependencies.
  • Return Redis connection to the pool immediately after query completion.
  • Return PostgreSQL client to the pool immediately after query completion.



Use the testing channel instead of stable:

sudo echo "deb https://artifacts.chirpstack.io/packages/4.x/deb testing main" | sudo tee /etc/apt/sources.list.d/chirpstack.list


Use the chirpstack/chirpstack:4.7.0-test.4 image and tag.


Quite big changes, especially the device-sessions and MQTT shared subcription.
Thanks a lot for your effort.

  1. Do I need to reboot LoRaWAN devices to rejoin after upgrading to v4.7.0?
  2. If I upgrade from Chirpstack 4.3.0 to 4.7.0, could I upgrade straightly from 4.3.0 to 4.7.0 or I need to upgrade 4.3 to 4.4 then 4.5, 4.6 and 4.7?

Thanks a lot.

Must? Does this include when using public CA certs like AWS RDS endpoints?

1 Like

You are right, it is only required when the CA cert is not provided by the system:

Even if the ca_cert is not set, it will read the platform native certs. I will fix this in the changelog.


You should be good to upgrade in one go, but please read the changelog notes (sometimes there are a few config changes that you must make).