Bêta précoce (0.1.0), pas encore pour un process critique. Voir la roadmap
PNeX logo

Auto-hébergement

Tiers, pile et notes d'exploitation

Tiers

  • Hobbyiste : un seul fichier SQLite, stockage local des artefacts — un atelier sur un laptop.
  • Scalable : PostgreSQL, artefacts S3 compatible (RustFS fourni ou S3 distant), la pile compose complète.

La pile compose

docker compose up -d démarre PostgreSQL, Rauthy, OpenObserve, RustFS, Valkey et le serveur PNeX. Caches non persistés par défaut ; les backends de stockage sont configurables par tiers.

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 une seule origine, https://<votre-domaine>, pour les navigateurs, les apps natives (desktop et Android) et les appareils :

  • 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 Pi pnex et la plateforme vit à https://pnex.local. Importez la CA une fois sur chaque client.
  • VM publique sans domaine : --domain sslip --tls cloud nomme 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.

Les appareils épinglent l'autorité de certification dans leur firmware. nginx a été choisi parce qu'il respecte les petits records TLS dont l'ESP8266 a besoin.

Stockage objet

Les artefacts firmware et les médias sont stockés en base par défaut. Pour les installations plus grandes, positionnez STORAGE_BACKEND=s3 et pointez PNeX vers n'importe quel stockage S3 compatible : l'instance RustFS fournie dans la pile compose, ou un service S3 distant.

VariableRôle
PNEX_S3_ENDPOINTURL de l'endpoint S3
PNEX_S3_BUCKETNom du bucket
PNEX_S3_REGIONRégion (optionnelle pour la plupart des stockages auto-hébergés)
PNEX_S3_ACCESS_KEY / PNEX_S3_SECRET_KEYIdentifiants — à injecter depuis un gestionnaire de secrets
PNEX_S3_PATH_STYLEtrue pour l'adressage path-style (courant en auto-hébergé)

Le backend se choisit à l'installation : il n'y a pas de migration entre le backend base de données et le backend S3.

Notes d'exploitation

  • Le serveur est un seul binaire statique : les backups sont la base plus les artefacts.
  • Un reverse proxy devant l'app web et l'API ; les upgrades WebSocket doivent passer.
  • Versions : le contrat d'API est versionné et l'app web se gate au boot contre un serveur incompatible (compatibility gate).

Page d'état de la plateforme

Page de rétention des données

Les builds firmware n'ont besoin du réseau que pour récupérer les packages PlatformIO au premier build ; tout le reste est embarqué dans le serveur.

On this page