ChirpStack Installation

We set up the ChirpStack LoRaWAN Network Server including typical core dependencies: ChirpStack, PostgreSQL (persistence), Redis (cache/queue), and in many setups an MQTT broker (e.g., Mosquitto) and the ChirpStack Gateway Bridge component for gateway connectivity.

Both: We install ChirpStack on-prem, in your cloud, or on dedicated hardware. We often also build a private network (VPN/Private Link) between gateways/locations and the ChirpStack environment.

This depends heavily on gateway count, device count, uplink frequency, and payload size. As a rule of thumb: For an initial production setup, we plan separate resources for database (IO/storage), MQTT, and ChirpStack services.

Primarily persistent are: PostgreSQL (configuration, devices, events, metadata), MQTT depending on configuration, and ChirpStack configuration (config files, secrets). We ensure clean persistence via volumes/managed disks.

In practice: yes, almost always, because MQTT in the ChirpStack ecosystem is the central messaging layer between components/Gateway Bridge and server (and is also used for integrations).

All three variants are possible: With you (on-prem / in your cloud), with us (managed hosting), or as managed MQTT. What matters is: access control, TLS, credential handling, and clear data flow documentation.

Yes. In the reference setup, 'EU868' is preconfigured, other regions can be cleanly switched. Important here is the region/topic configuration (e.g., topic prefix per region).

ChirpStack typically separates traffic via region prefixes (e.g., eu868, us915_0…). If gateways/forwarders use the wrong prefix, traffic ends up in the wrong context or isn't processed correctly.

Yes – this is often the clean enterprise approach: Gateways/locations send via VPN/Private Network to the ChirpStack infrastructure. This reduces attack surface and provides controllable data flows.

Typical baseline: TLS at external endpoints (reverse proxy/LB), strict firewalling, secret management (no secrets in repo), role/admin concept, separate admin access, logging/monitoring with defined scope.

In quickstart, the UI is locally accessible at http://localhost:8080; in production environments, there's typically a reverse proxy / load balancer with TLS and access controls in front.

Typical variants: Semtech UDP Packet Forwarder on UDP port 1700 (very common) or Semtech Basics Station by default on port 3001. Which variant you use depends on the gateway (vendor/firmware).

Both are possible: Gateways send via UDP/Basics Station to a Gateway Bridge instance. Alternatively, some setups use MQTT-based forwarders that publish to your MQTT broker (e.g., port 1883).

Yes. We support gateway onboarding end-to-end: provisioning, forwarder variant setup (UDP/Basics Station), connection tests, and documentation of parameters for your operations.

Almost always: PostgreSQL (I/O, backups, restore times), Redis (performance/queueing), MQTT broker (availability/throughput). We design the infrastructure so these components have robust defaults.

At minimum: regular PostgreSQL backups (point-in-time/incremental), defined retention + offsite/second location, regular restore tests. Optional: config backups/secrets and long-term event storage.

We define an update process with: staging/test (if available), maintenance window + communication, rollback options (snapshots/backups). This keeps operations plannable and low-risk.

Yes – but 'HA' here usually means: redundant services, robust DB setup, and clean failover concept. Which HA level makes sense depends on the use case and budget.

Scaling typically happens through: separate resources for DB/MQTT/services, horizontal scaling of stateless components, clean network and storage performance (DB IOPS!).

We offer: installation & secure baseline, operations/monitoring/incident handling, backups/restore tests, updates/maintenance, support for gateways, sensor onboarding, MQTT and data pipeline. In short: We handle infrastructure & operations, you use the IoT data.