Auto-hébergement
Base, stockage, pile et notes d'exploitation
Base de données : PostgreSQL uniquement
PNeX tourne sur PostgreSQL, et uniquement sur PostgreSQL. La pile compose le
fournit (postgres:18-alpine), allégé par le profil raspi : la même base tourne
sur un Raspberry Pi, un laptop ou un cluster.
- Il n'y a plus de mode SQLite (abandonné avant la 0.1.0) :
DATABASE_URLdoit pointer sur PostgreSQL. - La file de jobs (builds firmware, médias) vit dans la même base : rien d'autre à faire tourner.
- Les migrations de schéma s'appliquent au démarrage du serveur, un pod à la fois derrière un verrou en base : plusieurs réplicas peuvent démarrer ensemble.
- Les sauvegardes = la base + le stockage objet (
pnexctl backup).
Stockage : PostgreSQL et S3
Deux magasins, les mêmes sur un Raspberry Pi et sur un cluster :
- PostgreSQL porte les données et la file de jobs.
- Un stockage objet S3 compatible porte les fichiers : artefacts firmware, médias, modèles, enregistrements. RustFS est la référence, fourni avec la pile ; n’importe quel service S3 distant convient aussi.
Le stockage sur système de fichiers local est abandonné : RustFS ne coûte presque rien, même sur un Raspberry Pi, et un seul chemin de stockage se fiabilise mieux. Des réplicas d’API sans état s’ajoutent au-dessus des mêmes deux magasins.
La pile compose
docker compose up -d démarre PostgreSQL, Rauthy, OpenObserve, RustFS, Valkey et le
serveur PNeX. Valkey ne porte que des caches et la présence, sans persistance.
La même pile Compose tourne en développement et en production — sur un laptop, un Raspberry Pi ou une VM cloud. Le développement construit l'image PNeX ; la production tire une image de release taguée. Les images partent de Wolfi (Chainguard) pour une empreinte minimale.
Kubernetes : un chart Helm déploie la même stack sur un cluster — voir Installation → Kubernetes.
TLS partout
Un edge nginx termine tout le TLS, sur deux portes :
- 443 :
https://<votre-domaine>, pour les navigateurs et les apps natives (desktop et Android) — interface, API, WebSockets du navigateur, identité ; - 4443 : le point d'entrée devices (
PNEX_DEVICE_PORT), réservé aux appareils — WebSockets appareil, caméras et téléchargements OTA uniquement, en TLS mutuel avec un certificat client par appareil. Le serveur compile ce nom dans les firmwares viaPNEX_DEVICE_HOST(hôte[:port], ou:portseul en LAN).
Modes de certificat de l'interface :
- Mode local (par défaut) : une autorité de certification privée est générée une
fois et le certificat serveur est renouvelé automatiquement. Le nom par défaut est
<hostname>.local, publié sur le LAN par mDNS — nommez votre Raspberry Pipnexet la plateforme vit àhttps://pnex.local. Importez la CA une fois sur chaque client. - VM publique sans domaine :
--domain sslip --tls cloudnomme le serveur d'après son IP publique (pnex-203-0-113-7.sslip.io) et obtient un certificat Let's Encrypt — voir Noms et TLS. - Mode cloud : certificats Let's Encrypt, renouvelés automatiquement. Les ports 80 et 443 doivent être joignables depuis internet, et 4443 là où sont les appareils.
Ce que les appareils épinglent. Le firmware épingle la CA du point d'entrée
devices, injectée à chaque build : la CA locale en mode local, ISRG Root X1 en mode
cloud Compose (le 4443 sert le même certificat Let's Encrypt que l'interface), la CA
privée générée par le chart en Helm (par défaut). Perdre la CA locale ou en changer
impose de recompiler et reflasher les appareils : sauvegardez-la (pnexctl backup).
CA d'organisation. Indépendamment du certificat serveur, chaque organisation a sa propre CA (ECDSA P-256, 30 ans, clé dans le coffre) qui émet le certificat client de chaque build. Sa rotation n'est pas outillée en V1 : une nouvelle CA implique la recompilation et le flash de tous les appareils de l'organisation.
nginx a été choisi parce qu'il respecte les petits records TLS dont l'ESP8266 a besoin. Ne placez jamais un reverse proxy, un CDN ou un Ingress devant le point d'entrée devices : le TLS y serait terminé et le certificat client perdu.
Stockage objet
Installez avec --storage s3 : l’installeur ajoute RustFS et y raccorde PNeX
(PNEX_STORAGE_BACKEND=s3 pour les artefacts firmware, PNEX_MEDIA_BACKEND=s3
pour les médias). Le chart Helm déploie toujours RustFS. Pour un service S3
distant, renseignez plutôt :
| Variable | Rôle |
|---|---|
PNEX_S3_ENDPOINT | URL de l'endpoint S3 |
PNEX_S3_BUCKET | Nom du bucket |
PNEX_S3_REGION | Région (optionnelle pour la plupart des stockages auto-hébergés) |
PNEX_S3_ACCESS_KEY / PNEX_S3_SECRET_KEY | Identifiants — à injecter depuis un gestionnaire de secrets |
PNEX_S3_PATH_STYLE | true pour l'adressage path-style (courant en auto-hébergé) |
L’installeur accepte encore --storage fs (firmware dans PostgreSQL, médias sur
un volume local) pour les installations existantes ; cette option est en voie de
retrait. Démarrez les nouvelles installations sur S3. Passer une installation de
l’un à l’autre ne migre pas ses fichiers.
Notes d'exploitation
- Le serveur est un seul binaire statique : les backups sont la base plus le stockage objet.
- Un reverse proxy peut se placer devant l'app web et l'API (443) ; les upgrades WebSocket doivent passer. Jamais devant le point d'entrée devices (4443).
- Versions : le contrat d'API est versionné et l'app web se gate au boot contre un serveur incompatible (compatibility gate).
Mises à jour
Mettre à jour, c'est relancer l'installeur ou sudo pnexctl upgrade : les secrets
sont conservés et les migrations tournent au démarrage du serveur. Les bêtas
publiées vont jusqu'à 0.2.0-beta.2 ; la version de fin d'année sera plutôt une
0.3.0.
Mettre à jour depuis la 0.1.0-beta.7 ou avant vers n'importe quelle version
ultérieure (--version latest compris) est une rupture volontaire, une seule fois : le
contrat strict du lien appareil (TLS mutuel, Noise, OTA signée, point d'entrée devices)
n'est pas dans la beta.7.
- Recréer la base : le schéma a été recoupé en une nouvelle base de référence ; une base créée avant est refusée au démarrage. Une installation bêta sur SQLite doit passer à PostgreSQL (repartir d'une base neuve).
- Recompiler et reflasher en USB chaque appareil : un firmware compilé avant est refusé (il ne peut pas recevoir l'OTA qui le remplacerait).
- Ré-enrôler les agents edge : ils reçoivent un certificat client à l'enrôlement.
- Ouvrir le port 4443 là où sont les appareils.
Builds hors ligne
Le builder fonctionne hors ligne : l'image du builder embarque les deux cores PlatformIO et les bibliothèques préchargées (celles des firmwares PNeX et du catalogue de bibliothèques épinglées). Les firmwares PNeX et les builds custom qui n'utilisent que le catalogue compilent sans réseau, y compris sur un site isolé.