Balena deployment of the ChirpStack Gateway OS components — tested on 5 hardware platforms, rolled out fleet-wide

Viewed 1

Hi all,

I'd like to share a project I recently completed: a multi-container Balena application that replicates the ChirpStack Gateway OS "base" functionality using the official upstream components — Concentratord (SX1301/SX1302/2G4), MQTT Forwarder, UDP Forwarder, and Gateway Mesh — each in its own container, fully configured through fleet/device environment variables (version-pinned release artifacts, no forks or patches).

Repository: https://github.com/pe1mew/Balena-ChirpStack-Gateway-OS

Hardware validated:

  • MNTD. Blackspot / Goldspot (RAK Hotspot Miner V2 — Pi 4 + RAK2287)
  • Seeed SenseCAP M1 (Pi 4 + WM1302)
  • Raspberry Pi 3B+ with RAK831
  • Raspberry Pi 3B+ with IMST iC880A

Cross-stack mesh interoperability was also verified: a Balena border gateway working with a relay running ChirpStack Gateway OS (RAK7269v2).

Issues found along the way and reported upstream:

  • chirpstack-concentratord#286 — on the RAK Hotspot Miner V2 the SX1302 reset is on GPIO25, not the rak_2287 profile default; without it the chip starts from stale state and mimics a defective module.
  • chirpstack-gateway-mesh#130 — the border-gateway proxy answers GetGatewayId with an all-zero ID before (or after a failed) backend fetch.
  • chirpstack-mqtt-forwarder#73 — the forwarder accepts that all-zero gateway ID and keeps it for the process lifetime, publishing on .../gateway/0000000000000000/... topics.

The last two combine into a boot race in multi-service deployments; the repo documents a startup-ordering mitigation that has been reliable in production.

The stack has been rolled out to all gateways of the TTN Apeldoorn community network, migrating them from a 9-year-old resin.io-era setup while preserving all gateway identities. The repo includes a design document, deployment guide with hardware-validated troubleshooting, and a complete environment-variable reference.

Feedback welcome!

0 Answers