ChirpStack vs The Things Stack

Timo WevelsiepTimo Wevelsiep

ChirpStack and The Things Stack can both support serious LoRaWAN projects. The difference is how much network control, hosting ownership and operational responsibility you want to keep in your own stack.

Table of Contents

Short answer

Use shared or managed public-network models when coverage and fast onboarding matter most. Use private ChirpStack when gateways, tenants, regions, integrations and data paths should be under your own operational control.

LoRaWAN stack comparison

Criterion The Things Stack / TTN Private ChirpStack
Network model Public community network, managed cloud or private deployment options depending on edition. Private network server operated on your infrastructure or a managed dedicated environment.
Gateway control Strong for shared coverage and established ecosystem workflows. Strong when all gateways belong to one project, campus, city or customer network.
Data path Depends on selected edition, routing and integration setup. Can be kept inside your chosen hosting, VPN and integration architecture.
Operations Some operational burden can be shifted to the service model. Operations are explicit: server, database, MQTT, backups, updates and monitoring.
Customization Best when project requirements fit the platform and ecosystem. Best when payload decoding, tenants, MQTT topics and integrations need full control.
Fit Fast starts, existing coverage and community or platform workflows. Private industrial, municipal, utility and customer-specific LoRaWAN networks.

When to choose private ChirpStack

Private ChirpStack fits when you own the gateways. If gateways are deployed for one customer, site, city or infrastructure project, private operations can simplify ownership.

It also fits when integrations need to be deterministic. Private MQTT, database, webhook and dashboard integrations are easier to reason about when the stack is under one operating model.

merkaio's private LoRaWAN model

We build private LoRaWAN infrastructure for projects that need ownership more than generic platform convenience:

  • private ChirpStack instance with Gateway Bridge, MQTT, Redis and PostgreSQL
  • gateway provisioning, region configuration and device onboarding
  • payload decoders, integrations and dashboard pipelines
  • monitoring, backup, update and incident process
  • optional edge deployment for site-local networks

The Things Stack, The Things Network and ChirpStack are trademarks of their respective owners. merkaio is independent and not affiliated with these providers.

Frequently asked questions

Is TTN wrong for production?▼
No. The right fit depends on edition, coverage, operating model and requirements. This page focuses on cases where private operational control is important.
Does private ChirpStack require own gateways?▼
Usually yes. A private LoRaWAN server makes most sense when the project controls gateways or deploys them for a defined area.
Can merkaio connect existing gateways?▼
Yes. We can review gateway models and packet forwarder options, then migrate or onboard them into a managed ChirpStack setup.
Can ChirpStack run on edge hardware?▼
Yes, for suitable project sizes. A local edge deployment can keep LoRaWAN and dashboards running close to the site.

That is a lot of manual work, and operating it comes on top.

Updates, backups, hardening, monitoring: a production LoRaWAN server needs not just setup but continuous operation. We take that off your plate, as Managed ChirpStack on European infrastructure or preinstalled and ready to run on the merkaio edge pro.

Managed ChirpStack hostingmerkaio edge pro
Timo Wevelsiep

Written by

Timo Wevelsiep

Founder, merkaio

Builds and operates LoRaWAN and IoT platforms, from ChirpStack to custom applications.

LinkedIn