Déployer Redpanda en production sur Coolify avec TLS et Grafana — tutoriel 2026

📍 Article principal : Redpanda vs NATS vs RabbitMQ pour PME 2026. Ce tutoriel guide pas à pas le déploiement Redpanda en production sur un VPS Coolify avec sécurité TLS, supervision Grafana et premier producteur Python.

Redpanda est devenu en 2026 la solution streaming de choix pour les équipes qui veulent la puissance Kafka sans la douleur opérationnelle ZooKeeper/JVM. Sa version 25 stable utilise le moteur Raft natif (KRaft compatible Kafka), démarre en deux secondes sur un VPS modeste, expose une console web complète, et tient une charge de 200 000 messages/seconde sur un seul nœud. Ce tutoriel installe Redpanda sur Coolify, configure la sécurité TLS et SASL, met en place la supervision Prometheus + Grafana, et termine par un premier producteur Python qui publie des événements Wave.

Prérequis

• VPS Linux avec Coolify déjà installé (Hetzner CCX13 minimum : 4 vCPU, 16 Go RAM, 80 Go SSD)
• Sous-domaine redpanda.masociete.sn avec DNS A déjà configuré
• Accès root via SSH durci (clé Ed25519 obligatoire)
• Notions de Docker Compose et de YAML
• Niveau : avancé
• Temps estimé : 3 à 4 heures

Étape 1 — Préparer le compose Redpanda

Coolify accepte le déploiement par fichier docker-compose. Créer un nouveau projet masociete-streaming et ajouter un service custom avec le compose suivant. Cette configuration démarre Redpanda en mode single-node de production avec persistance des données dans un volume nommé.

services:
  redpanda:
    image: redpandadata/redpanda:v25.1.1
    container_name: redpanda
    command:
      - redpanda start
      - --smp 2
      - --memory 4G
      - --reserve-memory 0M
      - --overprovisioned
      - --node-id 0
      - --check=false
      - --kafka-addr internal://0.0.0.0:9092,external://0.0.0.0:19092
      - --advertise-kafka-addr internal://redpanda:9092,external://redpanda.masociete.sn:19092
      - --pandaproxy-addr internal://0.0.0.0:8082,external://0.0.0.0:18082
      - --advertise-pandaproxy-addr internal://redpanda:8082,external://redpanda.masociete.sn:18082
      - --schema-registry-addr internal://0.0.0.0:8081,external://0.0.0.0:18081
      - --rpc-addr redpanda:33145
      - --advertise-rpc-addr redpanda:33145
    volumes:
      - redpanda_data:/var/lib/redpanda/data
    ports:
      - "9092:9092"
      - "19092:19092"
      - "8081:8081"
      - "8082:8082"
      - "9644:9644"
  console:
    image: docker.redpanda.com/redpandadata/console:v3.0.0
    container_name: redpanda-console
    environment:
      KAFKA_BROKERS: redpanda:9092
    ports:
      - "8080:8080"
volumes:
  redpanda_data:

L’option --smp 2 alloue deux threads CPU dédiés au broker (sur un VPS 4 vCPU, en garder deux pour le système et les autres services). --memory 4G alloue 4 Go au broker (sur un VPS 16 Go, c’est confortable pour 50 000 messages/seconde soutenus). Le second service console expose une UI complète accessible via Caddy.

Déployer le projet via Coolify, qui se charge de Caddy et du certificat Let’s Encrypt sur console.redpanda.masociete.sn. Au bout de trois à cinq minutes, l’interface console est accessible et affiche un cluster sain avec un nœud unique. Vérifier dans les logs Coolify l’absence d’erreur de démarrage.

Étape 2 — Activer SASL et TLS

En production, le broker ne doit jamais être accessible sans authentification. Redpanda supporte SASL/SCRAM-SHA-256 et SASL/SCRAM-SHA-512 pour l’authentification, ainsi que mTLS pour le chiffrement et l’authentification mutuelle. La configuration se fait via la commande rpk qui dialogue avec l’API admin du broker.

docker exec -it redpanda rpk cluster config set superusers '["admin"]'
docker exec -it redpanda rpk cluster config set kafka_enable_authorization true
docker exec -it redpanda rpk cluster config set enable_sasl true
docker exec -it redpanda rpk acl user create admin -p <mot-de-passe-fort> --mechanism SCRAM-SHA-512

# Tester l'authentification
docker exec -it redpanda rpk topic create test \
  -X user=admin -X pass=<mdp> -X sasl.mechanism=SCRAM-SHA-512

Redémarrer le conteneur après la modification pour que la configuration prenne effet. Tous les futurs accès devront passer par un compte SASL valide. Créer ensuite un compte par application qui consomme ou produit des événements : commerce-app, logistics-worker, billing-sync. Cette segmentation par compte facilite la révocation en cas de fuite de credentials et trace dans les logs qui produit ou consomme quoi.

Pour TLS, déposer le certificat Let’s Encrypt généré par Coolify dans le volume Redpanda et configurer les listeners kafka_api_tls et admin_api_tls. Les clients devront alors se connecter avec tls.enabled=true et le CA root du certificat. Pour les déploiements internes, un certificat self-signed avec mTLS suffit et évite la dépendance ACME.

Étape 3 — Configurer la supervision Prometheus + Grafana

Redpanda expose nativement les métriques Prometheus sur le port 9644 endpoint /metrics. Déployer en parallèle dans Coolify une stack Prometheus + Grafana qui scrappe ces métriques et alimente un dashboard de supervision.

services:
  prometheus:
    image: prom/prometheus:v2.55.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prom_data:/prometheus
    ports:
      - "9090:9090"
  grafana:
    image: grafana/grafana:11.3.0
    environment:
      GF_SECURITY_ADMIN_PASSWORD: <mdp>
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
volumes:
  prom_data:
  grafana_data:

Le fichier prometheus.yml définit la cible Redpanda : scrape_configs:\n - job_name: redpanda\n static_configs:\n - targets: ['redpanda:9644']. Importer dans Grafana le dashboard officiel Redpanda (ID 18135 sur Grafana.com) qui visualise instantanément le débit, le lag, l’utilisation disque et la latence p99. Configurer trois alertes essentielles : lag consommateur > 10 000 messages, débit > 80 % capacity, disque > 70 %.

Pour les notifications, brancher Alertmanager sur un webhook Slack, Discord ou un canal Telegram dédié à l’équipe technique. Tester systématiquement chaque alerte au moment de la mise en place — une alerte mal configurée qui ne se déclenche pas en cas d’incident est pire que l’absence d’alerte.

Étape 4 — Premier producteur Python

Le client Python kafka-python ou confluent-kafka-python parle nativement le protocole Redpanda. Installer la dépendance et écrire un premier producteur qui publie un événement commerce.order.created.

pip install confluent-kafka

# producer.py
from confluent_kafka import Producer
import json, uuid

conf = {
  'bootstrap.servers': 'redpanda.masociete.sn:19092',
  'security.protocol': 'SASL_SSL',
  'sasl.mechanism': 'SCRAM-SHA-512',
  'sasl.username': 'commerce-app',
  'sasl.password': '<mdp>',
  'enable.idempotence': True,
  'acks': 'all',
}
p = Producer(conf)

event = {
  'event_id': str(uuid.uuid4()),
  'order_id': 'CMD-2026-04-29-001',
  'customer_phone': '+221770000000',
  'amount_xof': 25000,
  'items': [{'sku': 'PROD-001', 'qty': 2}],
  'timestamp': '2026-04-29T10:30:00Z',
}
p.produce('commerce.order.created.v1',
  key=event['order_id'].encode(),
  value=json.dumps(event).encode())
p.flush()

Les paramètres critiques : enable.idempotence=True garantit qu’un retry du producteur ne duplique pas le message côté broker. acks='all' attend la confirmation de tous les replicas avant de considérer le message comme publié — c’est plus lent mais aucune perte n’est possible. Le key détermine le partitionnement : tous les événements avec la même clé arrivent dans la même partition donc dans le même ordre, garantie souvent essentielle pour les flux financiers.

Étape 5 — Premier consommateur et test bout en bout

Le consommateur lit les événements du topic et applique sa logique métier. Implémenter l’idempotence est essentiel — stocker un identifiant unique par événement traité dans une table de déduplication.

# consumer.py
from confluent_kafka import Consumer
import json

conf = {
  'bootstrap.servers': 'redpanda.masociete.sn:19092',
  'security.protocol': 'SASL_SSL',
  'sasl.mechanism': 'SCRAM-SHA-512',
  'sasl.username': 'logistics-worker',
  'sasl.password': '<mdp>',
  'group.id': 'logistics-prepare-delivery',
  'auto.offset.reset': 'earliest',
  'enable.auto.commit': False,
}
c = Consumer(conf)
c.subscribe(['commerce.order.created.v1'])

while True:
  msg = c.poll(1.0)
  if msg is None: continue
  if msg.error(): print(msg.error()); continue
  event = json.loads(msg.value())
  if already_processed(event['event_id']): 
    c.commit(msg)
    continue
  prepare_delivery(event)
  mark_processed(event['event_id'])
  c.commit(msg)

Le commit manuel après traitement (et non auto-commit) garantit qu’en cas de crash du consommateur, le message non encore traité sera re-livré au prochain démarrage. Combiné à la table de déduplication, on obtient une sémantique effective exactly-once pour la logique métier sans utiliser les transactions Redpanda.

Étape 6 — Sauvegarde et restauration

Une perte de données dans le broker peut mettre la PME hors service pendant des heures. Mettre en place une sauvegarde régulière du volume Docker via Restic vers Hetzner Storage Box ou un bucket S3-compatible. Pour Redpanda, deux approches possibles. La première, simple : snapshot du volume redpanda_data avec le broker à l’arrêt — fenêtre de coupure de quelques minutes par jour. La seconde, sans coupure : utiliser le mécanisme natif Redpanda Cloud Storage qui réplique en quasi-temps réel les segments fermés vers un bucket S3.

Tester la restauration sur un VPS séparé une fois par trimestre. Vérifier que les topics, les ACL et les offsets de consommation sont correctement restaurés. Une procédure de restauration documentée et testée est la garantie de pouvoir réagir dans les 30 minutes en cas de panne — sans cette préparation, l’incident peut paralyser la PME plusieurs jours.

Tuning et performance avancée

Redpanda offre des performances brutes excellentes en configuration par défaut, mais quelques ajustements valent la peine pour une PME qui prévoit une croissance significative. Le premier réglage concerne le batching côté producteur. Au lieu d’envoyer chaque message individuellement, regrouper les messages en batches de 16 Ko à 1 Mo selon la latence acceptable. Le paramètre linger.ms contrôle le délai d’attente avant l’envoi d’un batch incomplet : 5 ms est un excellent compromis pour des charges modérées, 50 ms pour des charges massives où la latence importe moins que le débit.

Le deuxième réglage concerne le nombre de partitions par topic. Une partition par défaut suffit pour des charges sous 10 000 messages/seconde. Au-delà, augmenter à 3 ou 6 partitions permet le traitement parallèle côté consommateurs. Attention : le nombre de partitions ne peut être augmenté qu’à la création du topic, pas après. Anticiper la charge future en allouant 3 partitions dès le départ pour les topics critiques. Le troisième réglage concerne la taille de segment, qui détermine la granularité des fichiers de stockage : log.segment.bytes=536870912 (512 Mo) est l’optimum sur disque NVMe rapide, descendre à 128 Mo si on cible une rotation plus fréquente.

Le quatrième réglage concerne la mémoire allouée à Redpanda. La règle empirique : 50 % de la RAM totale du VPS, avec un minimum de 2 Go pour fonctionner correctement. Sur un VPS 16 Go, allouer 8 Go à Redpanda laisse un confort raisonnable pour les autres services. Au-delà de 32 Go, les retours décroissants apparaissent rapidement — il vaut mieux passer en cluster multi-nœuds que monter en gamme verticalement.

Migration depuis Apache Kafka existant

Pour les PME qui ont déjà un Apache Kafka en production et veulent migrer vers Redpanda pour réduire la complexité, la procédure est étonnamment simple grâce à la compatibilité protocole. La méthode recommandée : déployer Redpanda en parallèle, configurer Kafka MirrorMaker 2 pour répliquer en continu les topics de Kafka vers Redpanda, basculer progressivement les producteurs sur Redpanda, basculer enfin les consommateurs en alignant les offsets, décommissionner Kafka une fois la migration validée.

La fenêtre de bascule typique pour une PME tient en deux semaines. La première semaine, mise en place de la réplication et tests sur un sous-ensemble de topics non critiques. La deuxième semaine, bascule progressive des autres topics avec validation fonctionnelle à chaque étape. Aucune coupure utilisateur n’est nécessaire si l’opération est bien préparée. Le gain post-migration en exploitation est immédiat : pas de ZooKeeper à maintenir, pas de JVM à tuner, alertes plus claires, démarrage plus rapide.

Cluster multi-nœuds pour haute disponibilité

Pour une vraie résilience, déployer trois nœuds Redpanda sur trois VPS distincts (idéalement dans trois zones réseau différentes : Falkenstein, Helsinki, Nuremberg pour Hetzner). Le replication factor 3 stocke chaque message sur trois nœuds, et le quorum de 2 garantit qu’une perte de nœud n’entraîne aucune perte de donnée ni d’interruption de service. La configuration du cluster passe par --seeds qui liste les autres nœuds.

Le coût d’un cluster trois nœuds tient autour de 100 €/mois sur Hetzner CCX13 × 3, soit 1 200 €/an pour une infrastructure résiliente capable d’encaisser une panne datacenter complète. Pour comparaison, le même niveau de SLA en cloud managé (Confluent, Aiven) coûte facilement 5 à 10 fois plus. Le surcoût opérationnel d’un cluster reste contenu : les opérations de mise à jour et de maintenance se font une seule fois et se propagent automatiquement.

Gérer les évolutions de version

Redpanda publie une version mineure tous les trois mois et des correctifs de sécurité plus fréquents. La procédure de mise à jour en production se fait sans coupure si on a un cluster multi-nœuds : arrêter un nœud, mettre à jour son image Docker, redémarrer, attendre que le cluster récupère la pleine santé, puis passer au nœud suivant. En mode mono-nœud, prévoir une fenêtre de maintenance de 5 à 10 minutes pendant laquelle les producteurs accumulent localement les messages dans leur file d’attente.

Tester systématiquement les mises à jour majeures (passage de v24 à v25 par exemple) sur une instance bac à sable avant la production. Une mise à jour majeure peut introduire des changements de comportement subtils : politique de rétention par défaut différente, modifications des métriques exposées, nouveaux paramètres de configuration. Documenter chaque mise à jour dans un journal d’opérations qui mentionne la version d’origine, la version cible, les éventuels correctifs appliqués. Cette documentation vaut de l’or au bout de quelques années quand un nouvel admin reprend le système.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour une PME hébergée en Europe avec des consommateurs au Sénégal ou en Côte d’Ivoire, la latence aller-retour de 80 ms est négligeable pour le streaming d’événements. Activer la compression LZ4 ou Zstandard côté producteur réduit drastiquement la consommation bande passante : un événement de 1 Ko en JSON tombe à 200 octets compressés. Sur un million d’événements/jour, l’économie atteint 800 Mo par jour soit 24 Go par mois — significatif si la PME paie au volume sortant. Pour les déploiements souverains entièrement à Dakar ou Abidjan, Wagaden et Sonatel Cloud proposent des VPS qui hébergent confortablement Redpanda — la procédure ci-dessus reste identique.

Pour terminer la mise en production, prévoir une revue trimestrielle de la sécurité : rotation des credentials SASL, revue des ACL appliquées, vérification que les certificats TLS sont à jour avant échéance, audit des comptes inactifs depuis plus de 90 jours. Cette discipline simple maintient le cluster Redpanda dans un état de propreté opérationnelle qui résiste à la rotation des équipes et aux périodes de forte croissance. Documenter chaque opération de routine dans un runbook accessible à toute l’équipe technique transforme la dépendance individuelle en savoir collectif partagé.

Cette pratique systématique de revue trimestrielle prévient durablement les dérives sécuritaires et opérationnelles d’une plateforme événementielle critique.

Pour aller plus loin

🔝 Retour à l’article principal : Redpanda vs NATS vs RabbitMQ pour PME 2026. Documentation officielle Redpanda : docs.redpanda.com, image Docker officielle : hub.docker.com/r/redpandadata/redpanda. La suite logique consiste à mettre en place le Schema Registry pour gérer l’évolution des contrats d’événements — sujet du tutoriel dédié de cette série.

Pour pérenniser le déploiement, prévoir une revue mensuelle des métriques Grafana : croissance du volume d’événements, lag consommateurs moyens, utilisation disque. Ces tendances anticipent les besoins de montée en gamme avant que la performance ne dégrade pour les utilisateurs finaux. Documenter aussi en interne la procédure de bascule en cas de panne : numéro d’astreinte, étapes de redémarrage, contacts Hetzner support, point de restauration le plus récent. Cette préparation transforme un incident potentiellement long en simple coupure de service de quelques minutes.