VM300 est une machine virtuelle applicative dédiée à n8n :
elle exécute les workflows d'automatisation, délègue la persistance à une VM de services (PostgreSQL) et
consomme les API IA d'une VM GPU distincte. Cette séparation application / données / calcul permet à
chaque composant d'évoluer, d'être maintenu et sauvegardé selon son propre cycle de vie.
✅ État déployé
- Ubuntu Server 24.04 LTS · Docker Engine + Compose
- n8n 2.32.6 — image officielle épinglée
- Instance unique, mode standard, sans Redis
- PostgreSQL externe — connexion chiffrée, authentification forte
- API Ollama distante consommée par un workflow validé
- Interface publiée en HTTPS par le reverse proxy mutualisé
- Persistance vérifiée après recréation du conteneur et redémarrage
🔒 Sécurité de l'état actuel
- Port applicatif conservé sur le réseau interne, interface publique exposée uniquement en HTTPS
- Filtrage système + publication Docker maîtrisée
- Secrets et clé de chiffrement hors Compose et hors Git
- Image applicative épinglée
- Base PostgreSQL et rôle dédiés, liaison chiffrée
- Aucune redirection Internet directe vers VM300
- Origine publique, cookies sécurisés, confiance limitée au reverse proxy
- Inspection des workflows et des types de nœuds utilisés
🧱 Architecture interne (VM300)
isolation Docker · déploiement reproductible (Compose)
VM300
├── Ubuntu Server
├── Docker Engine
├── Docker Compose
└── conteneur n8n
├── moteur de workflows
├── interface d'administration
├── appels vers les services autorisés
└── données binaires locales nécessairesn8n fonctionne volontairement en mono-instance : Redis et le mode queue ne sont pas ajoutés tant qu'un besoin de parallélisme ou de haute disponibilité n'est pas démontré — ce qui réduit le nombre de composants à exploiter.
Composants externes
🗄️ PostgreSQL (VM de services)
- Base réservée à l'application
- Rôle applicatif distinct, droits limités au besoin
- Connexion chiffrée · filtrage réseau ciblé
- Recréer n8n ne supprime ni comptes ni workflows (données hors conteneur)
🧠 Ollama (VM GPU)
- Calculs IA déportés vers le nœud GPU
- VM300 appelle une API Ollama autorisée, sans GPU ni copie de modèle
- Workflow validé : préparation requête → appel HTTP → réponse du modèle → normalisation de la sortie
🌐 Publication Internet active
L'éditeur est publié en HTTPS sous n8n.stephanemuraro.fr (interface d'administration
authentifiée et URL de webhook produites par l'instance), derrière le reverse proxy VM200. Le port
applicatif de VM300 n'est pas exposé directement : toute requête publique traverse VM200, qui termine
HTTPS, sélectionne le service par le nom demandé et ne relaie que les routes prévues. Une séparation ultérieure sous
un nom dédié aux webhooks reste possible si un besoin d'exposition plus restrictive est confirmé.
chemin d'une requête publique
Utilisateur ou service externe
↓ HTTPS
Nom DNS public
↓
Routeur Internet
↓ trafic Web uniquement
VM200 — reverse proxy (terminaison TLS · sélection par nom · routes autorisées)
↓ flux interne autorisé
VM300 — n8n
↓
PostgreSQL ou API IA selon le workflow
n8n connaît son origine HTTPS publique, fait confiance au proxy attendu et utilise des
cookies sécurisés. L'authentification, l'éditeur, l'exécution d'un workflow, la reconnexion et la
persistance ont été validés depuis Internet (réseau extérieur).
🔄 Exemple — workflow n8n vers l'IA
workflow (illustratif)
Trigger : Webhook → Nœud HTTP : préparation de la requête → Nœud HTTP : appel API Ollama (LLM local sur la VM GPU) → Nœud Function : normalisation de la réponse pour les étapes suivantes → Réponse : JSON structuré
🎯 Compétences mises en œuvre
- Déploiement Docker Compose reproductible
- Séparation application / données / calcul GPU
- Intégration PostgreSQL chiffrée, moindre privilège
- Consommation contrôlée d'une API LLM distante
- Conception de workflows persistants
- Préparation d'une publication HTTPS derrière un reverse proxy
- Gestion des secrets et réduction de la surface d'exposition
Limites & travaux ouverts :
- Une séparation future entre l'éditeur et les webhooks (nom dédié) reste à arbitrer.
- La procédure complète de sauvegarde et de restauration reste à formaliser.
- Le durcissement final de l'administration SSH reste ouvert.
- L'audit automatisé (anomalie de chargement, compensée par un contrôle manuel) sera rejoué après correctif de n8n.
- Le mode queue ne sera étudié qu'en présence d'un besoin mesuré.
IA Locale / LLM
Docker
Infrastructure
Proxmox VE
Outils libres & DevOps