Déployer ChirpStack sur Hetzner pour agritech IoT : tutoriel 2026

📍 Article principal : Agritech IoT Afrique de l’Ouest 2026

Introduction

Une coopérative maraîchère de Niayes au Sénégal voulait équiper 30 hectares de capteurs sol et météo connectés en LoRaWAN. Le défi technique central : disposer d’un serveur LoRaWAN qui décode les paquets reçus de la gateway et expose les données aux applications métier. Le choix s’est porté sur ChirpStack, le standard open-source du secteur, déployé sur un VPS Hetzner CX22 à 5 euros par mois. Installation et configuration initiale en moins de 4 heures, fonctionnement stable depuis 18 mois sans intervention majeure. Ce tutoriel détaille le déploiement complet ChirpStack sur Hetzner adapté aux contraintes ouest-africaines : configuration Docker Compose, intégration d’une gateway physique Dragino, enregistrement des premiers appareils capteurs, configuration MQTT pour exposer les données aux applications, et patterns spécifiques au climat et à la connectivité régionaux.

Prérequis

• Compte Hetzner Cloud avec moyen de paiement opérationnel
• Domaine pour le serveur ChirpStack (par exemple lora.coop.sn)
• Gateway LoRaWAN compatible (Dragino LPS8N ou équivalent recommandé)
• Notions de base SSH et Docker Compose
• Niveau : intermédiaire — Temps : 4 heures

Étape 1 — Provisionner le VPS Hetzner

ChirpStack est relativement léger en ressources : un VPS CX22 (2 vCPU, 4 Go RAM, 40 Go SSD) à 4,49 euros HT par mois suffit pour gérer plusieurs centaines de capteurs avec confort. Pour les déploiements plus ambitieux dépassant le millier d’appareils, monter à CX32 (8 Go RAM) à 8,49 euros offre la marge nécessaire. Localisation Falkenstein (FSN1) ou Nuremberg (NBG1) — la latence depuis l’Afrique de l’Ouest est comparable.

Le serveur est commandé via la console Hetzner Cloud avec quelques clics. Choisir l’image Debian 13 ou Ubuntu 24.04 LTS pour stabilité long terme. Ajouter sa clé SSH publique dès la création pour accès direct sans mot de passe. Configurer le firewall Hetzner pour ouvrir uniquement les ports 22 (SSH), 80 (HTTP), 443 (HTTPS), et 1883 ou 8883 (MQTT TLS) selon la configuration MQTT choisie.

Une fois le serveur démarré, premier réflexe sécurité : créer un utilisateur non-root, désactiver l’auth root, et appliquer le hardening SSH de base. Ce travail de 30 minutes pose les fondations sécurité essentielles. Sans cette précaution, le VPS exposé directement subit en moyenne plusieurs centaines de tentatives de connexion automatisées par jour — pas critique pour ChirpStack en soi mais signale une posture de sécurité faible.

Étape 2 — Installer Docker et préparer ChirpStack

Docker simplifie radicalement le déploiement de ChirpStack en encapsulant toutes les dépendances dans des containers reproductibles. L’installation se fait via le script officiel Docker, suivi de la création du dossier projet ChirpStack avec sa structure standard. Cette préparation prend 15 minutes et conditionne tout le reste.

Le script ci-dessous installe Docker, crée l’utilisateur dédié, et clone le dépôt officiel ChirpStack qui contient le docker-compose.yml de référence avec toutes les configurations sensées. On adaptera ensuite quelques paramètres avant de lancer les services.

# Installation Docker
curl -fsSL https://get.docker.com | sh
usermod -aG docker votre_user

# Cloner ChirpStack docker
cd /srv
git clone https://github.com/chirpstack/chirpstack-docker.git
cd chirpstack-docker

# Le docker-compose.yml de référence est inclus
cat docker-compose.yml | head -30

Le dépôt cloné contient déjà la configuration de référence avec ChirpStack, PostgreSQL, Redis, et un Mosquitto MQTT broker. Cette stack est éprouvée par la communauté et constitue un bon point de départ. On conserve l’essentiel et on personnalise les ports exposés et les mots de passe pour notre environnement.

Étape 3 — Personnaliser la configuration

Avant de démarrer les services, deux personnalisations essentielles. Premièrement, modifier les mots de passe par défaut de PostgreSQL et Redis pour des valeurs robustes générées aléatoirement. Deuxièmement, ajuster la configuration ChirpStack pour activer les fonctionnalités souhaitées : intégration MQTT, format des payloads sortants, fréquences LoRaWAN selon la région.

Pour l’Afrique de l’Ouest, on configure ChirpStack avec le plan de fréquences EU868 qui est libre dans la plupart des pays UEMOA. Cette configuration se fait via l’interface web après le démarrage initial, mais on peut aussi la pré-configurer dans les fichiers YAML pour un déploiement reproductible. La configuration EU868 est aussi compatible avec la quasi-totalité des modules LoRa modernes.

# Editer docker-compose.yml pour les ports
nano docker-compose.yml

# Sections clés à vérifier :
# - ports ChirpStack web : 8080:8080
# - port Mosquitto MQTT : 1883:1883
# - volumes persistants pour PostgreSQL data

# Générer mots de passe sécurisés
openssl rand -base64 32 > /srv/chirpstack-docker/.env

Ces ajustements permettent une mise en production sans risquer les credentials par défaut qui sont publiquement connus. Pour un déploiement professionnel, on stocke ces secrets dans un gestionnaire (Hashicorp Vault, AWS Secrets Manager, ou simplement variables d’environnement chiffrées) plutôt qu’en clair dans le fichier .env.

Étape 4 — Démarrer les services

Avec la configuration en place, le démarrage se résume à une commande Docker Compose. Le premier démarrage prend 2-3 minutes pour télécharger les images, initialiser PostgreSQL avec le schéma ChirpStack, et démarrer tous les services. Suivre les logs permet de vérifier que tout démarre correctement et d’identifier rapidement tout problème.

Après démarrage, l’interface web ChirpStack devient accessible sur le port 8080. On se connecte avec les identifiants admin par défaut puis on les change immédiatement. Cette étape de sécurité élémentaire est trop souvent négligée et expose les serveurs à des prises de contrôle automatiques.

cd /srv/chirpstack-docker
docker compose up -d

# Vérifier que tout démarre
docker compose ps
docker compose logs -f chirpstack

# Au premier démarrage, accéder à http://VOTRE_IP:8080
# Identifiants par défaut : admin / admin
# CHANGER IMMÉDIATEMENT le mot de passe

Une fois la connexion validée, on configure d’abord le tenant (organisation), puis l’application (logique métier de notre déploiement), et enfin le device-profile qui définit les paramètres communs aux capteurs (régions, classe LoRaWAN, codec de payload). Cette hiérarchie permet de séparer proprement les configurations multi-organisations si besoin et d’organiser les déploiements à grande échelle.

Étape 5 — Reverse proxy Caddy avec HTTPS

Pour exposer ChirpStack proprement en production, on installe Caddy en frontal qui gère HTTPS automatiquement via Let’s Encrypt. Cette protection chiffre les communications administrateur et les API métier qui exposent les données capteurs. Sans HTTPS, les credentials transitent en clair — inacceptable pour un déploiement professionnel.

Avant la configuration Caddy, le DNS du domaine doit pointer vers l’IP du VPS via un enregistrement A. Une fois la propagation effectuée (5-30 minutes), Caddy obtient automatiquement le certificat Let’s Encrypt et démarre le reverse proxy. Toute la complexité TLS classique est gérée transparente.

apt install -y caddy

cat > /etc/caddy/Caddyfile <<EOF
lora.coop.sn {
    reverse_proxy localhost:8080
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
    }
}
EOF

systemctl reload caddy

Avec cette configuration, l’accès se fait désormais via https://lora.coop.sn avec certificat valide reconnu par tous les navigateurs. Pour les communications MQTT, on configure de manière similaire un endpoint TLS sur le port 8883 — Mosquitto inclus dans la stack ChirpStack supporte nativement TLS.

Étape 6 — Connecter une gateway physique

La gateway physique est le composant matériel qui reçoit les paquets LoRa des capteurs et les transmet via Internet à ChirpStack. Plusieurs modèles conviennent. Pour le contexte ouest-africain, la Dragino LPS8N à environ 200 euros offre un excellent rapport qualité-prix avec 8 canaux, antenne LoRa intégrée, et configuration simplifiée. Pour des déploiements plus ambitieux, la MikroTik wAP LR9 ou la Multitech Conduit AEP sont des options professionnelles.

Pour la connexion, deux étapes successives. D’abord enregistrer la gateway dans ChirpStack via l’interface web : aller dans Gateways, créer une nouvelle gateway avec son Gateway EUI (identifiant unique de 16 caractères hexadécimaux). Ensuite, configurer la gateway physique pour qu’elle pointe vers notre serveur ChirpStack via le protocole BasicStation ou Semtech UDP Packet Forwarder selon le modèle. Une fois la connexion établie, la gateway apparait « online » dans le tableau de bord ChirpStack et commence à transmettre les paquets reçus.

Étape 7 — Enregistrer les premiers capteurs

Les capteurs LoRaWAN sont identifiés par leur DevEUI (similaire à une adresse MAC). Pour les enregistrer dans ChirpStack, on récupère ces identifiants depuis la documentation du fabricant ou via les étiquettes sur les capteurs eux-mêmes. Pour chaque capteur, on enregistre dans ChirpStack le DevEUI, l’AppKey de chiffrement, et on assigne le device-profile préalablement créé.

Une fois enregistrés, les capteurs effectuent une procédure d’OTAA (Over-The-Air Activation) lors de leur premier réveil. Cette procédure échange les clés de session chiffrées et permet ensuite la transmission sécurisée des mesures. La première activation peut prendre quelques minutes selon la qualité de la liaison radio. Une fois activés, les capteurs apparaissent dans le tableau de bord ChirpStack avec leurs mesures progressives.

Étape 8 — Exposer les données via MQTT

ChirpStack publie automatiquement chaque paquet reçu sur des topics MQTT structurés. Cela permet aux applications métier de consommer les données en temps réel sans interroger l’API ChirpStack. Cette architecture pub-sub découple ChirpStack des applications consommatrices et facilite l’ajout de nouveaux services (dashboard, alertes, ML) sans toucher à ChirpStack.

Pour tester la consommation MQTT, on utilise un client simple comme mosquitto_sub qui écoute le topic des mesures décodées. Chaque paquet apparait avec son contenu JSON contenant les valeurs décodées des capteurs (humidité, température, batterie, etc.). C’est ce flux MQTT que les applications dashboards, alertes, et stockage TimescaleDB consomment ensuite.

# Test consommation MQTT
mosquitto_sub -h lora.coop.sn -p 1883 -t "application/+/device/+/event/up" -v

# Pour TLS sur port 8883
mosquitto_sub -h lora.coop.sn -p 8883 -t "..." --cafile /etc/ssl/certs/ca-certificates.crt

Avec ce flux MQTT exposé, les applications métier peuvent désormais consommer les mesures en temps réel. C’est sur cette fondation qu’on bâtit ensuite le pipeline complet : ingestion vers TimescaleDB pour stockage, dashboard Grafana ou SvelteKit pour visualisation, règles d’alertes pour notifications SMS aux agriculteurs.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Trois aspects pratiques. Premièrement, pour les coopératives en zone rurale, la connectivité Internet de la gateway peut être instable. ChirpStack tolère bien les coupures grâce à son architecture pub-sub asynchrone, mais il faut s’assurer que la gateway dispose d’un buffer local pour stocker les paquets pendant les coupures. Les modèles modernes intègrent ce buffer nativement. Deuxièmement, pour la sécurité, ne jamais exposer ChirpStack directement sur Internet sans HTTPS et authentification forte. Le tableau de bord contient des informations sensibles (positions des capteurs, mesures économiquement valorisables). Troisièmement, prévoir des sauvegardes nocturnes de la base PostgreSQL ChirpStack vers Hetzner Object Storage avec rétention 30 jours minimum. Voir notre tutoriel sauvegardes rclone pour le pattern complet.

Pour les coûts d’opération, ChirpStack sur CX22 plus stockage représente moins de 10 euros mensuels, parfait pour une coopérative qui démarre. Pour les structures qui se développent au-delà de 1 000 capteurs, monter en CX32 reste économique. Cette frugalité change la trajectoire économique des projets agritech qui peuvent atteindre la rentabilité sans charges d’infrastructure prohibitives.

Tutoriels frères

• Construire des capteurs LoRaWAN
• Dashboard Grafana et SvelteKit
• ML prédiction irrigation

Pour aller plus loin

• 🔝 Pilier : Agritech IoT Afrique 2026
• Articles : Hetzner Cloud Afrique
• Doc : ChirpStack documentation

FAQ

Combien de capteurs un CX22 supporte-t-il avec ChirpStack ?
Plusieurs centaines confortablement, jusqu’à environ 1 000 avec une charge raisonnable. Au-delà, monter à CX32 ou optimiser PostgreSQL.

Faut-il payer la gateway ou peut-on en utiliser une partagée ?
Pour une coopérative qui veut maîtriser sa stack, dédier sa propre gateway est préférable. Pour un projet pilote ultra-léger, les réseaux partagés type The Things Network existent mais sont peu déployés en Afrique de l’Ouest en 2026.

ChirpStack ou The Things Stack ?
Les deux sont open-source crédibles. ChirpStack a l’avantage de la simplicité de déploiement et de la communauté plus active sur les use cases agricoles. The Things Stack est plus riche fonctionnellement mais plus complexe à opérer.

Comment migrer vers une gateway plus puissante plus tard ?
Trivialement : enregistrer la nouvelle gateway dans ChirpStack avec son EUI, désactiver l’ancienne, et changer la configuration physique. Aucune perte de données capteurs.