[{"data":1,"prerenderedAt":205},["ShallowReactive",2],{"seo-verification":3,"blog-installer-windmill-vps-ma-fr":6,"promo-bar-likely":204},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-installer-windmill-vps-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":32,"intro":34,"sections":35,"ctaTitle":147,"ctaBody":148,"ctaButton":149,"ctaUrl":150,"relatedPosts":151},27,"installer-windmill-vps",{"fr":10,"en":12,"ar":13,"es":14},"installing-windmill-on-a-vps-self-hosted-automation","تثبيت-windmill-على-خادم-vps-أتمتة-ذاتية-الاستضافة","instalar-windmill-en-un-vps","Installer Windmill sur un VPS : automatisation self-hosted","Installez Windmill sur votre VPS : transformez vos scripts Python, TypeScript et Bash en workflows et UI internes, en self-hosted via Docker.",13,1,false,"2026-05-24T00:00:00+00:00","2026-11-08T01:13:13+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},2,"Automatisation","automatisation","bg-brand-action\u002F10 text-brand-action",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Finstaller-windmill-vps-poster.svg",{"categorySlug":25,"appSlug":33},"windmill","Windmill est une plateforme open source qui transforme du code (Python, TypeScript, Go, Bash, SQL) en workflows, API et interfaces internes. Pensée pour les développeurs, elle combine la souplesse du code et la rapidité du no-code. Self-hébergée sur un VPS, elle devient votre moteur d'automatisation et votre app builder interne, sans dépendre d'un SaaS.",[36,40,51,54,61,86,89,98,101,105,108,116,145],{"type":37,"title":38,"body":39},"h2","Pourquoi self-héberger Windmill sur un VPS","Windmill s'exécute en continu sur votre serveur et expose chacun de vos scripts comme un endpoint REST authentifié par jeton, une tâche planifiée ou une interface auto-générée. Contrairement à une fonction serverless, il n'y a pas de démarrage à froid ni de limite d'exécution imposée par un tiers. Vos scripts Python, TypeScript ou Bash accèdent directement aux bases de données et aux services internes de votre VPS, sans traverser une passerelle cloud. Le backend est écrit en Rust : des serveurs d'API sans état et des workers qui dépilent les jobs d'une file stockée dans PostgreSQL, ce qui permet d'ajouter des workers sans toucher au reste.\n\nLe choix se fait surtout sur la façon de travailler. Si votre besoin est de relier des SaaS entre eux sur un canevas visuel, \u003Ca href=\"\u002Fblog\u002Finstaller-n8n-vps\">n8n\u003C\u002Fa> reste plus direct ; pour des processus métier très longs à garantie de reprise, \u003Ca href=\"\u002Fblog\u002Finstaller-temporal-vps\">Temporal\u003C\u002Fa> est taillé pour ça. Windmill vise les équipes qui écrivent déjà du code et veulent le rendre exécutable, planifiable et utilisable par des non-développeurs en quelques minutes. Côté licence, le cœur est en AGPLv3 et l'image Community Edition est gratuite, avec des quotas et des fonctions réservées à l'édition Enterprise ; la revendre ou la proposer comme service managé à vos clients exige une licence commerciale.",{"type":41,"title":42,"items":43},"ul","Bénéfices concrets du self-hosting",[44,45,46,47,48,49,50],"Aucune facturation à l'exécution : des milliers de jobs par jour sans facture d'infonuagique.","Accès direct aux bases et services internes du VPS, sans tunnel.","Secrets et clés API stockés chiffrés dans Windmill et jamais sortis de votre serveur.","Formulaires d'entrée et endpoints REST générés automatiquement pour chaque script, à partir de la signature de sa fonction `main`.","Workers additionnels ajoutables à chaud pour absorber les pics de charge.","Plusieurs workspaces isolés sur une même instance : un par équipe, par projet ou par environnement.","Versionnement : chaque déploiement d'un script est conservé, et Git Sync pousse le workspace vers un dépôt Git (inclus en Community Edition pour les workspaces de 2 utilisateurs au plus).",{"type":37,"title":52,"body":53},"Prérequis techniques","Windmill nécessite au minimum 2 vCPU et 4 Go de RAM. La stack officielle démarre PostgreSQL 18, le serveur, trois workers généralistes plafonnés à 2 Go de mémoire chacun, un worker natif pour les jobs légers, le service `windmill_extra` (autocomplétion LSP et débogueur de l'éditeur) et un Caddy en frontal : sur 4 Go, réduisez donc le nombre de workers. Comptez 20 Go de disque pour la base, les logs et le cache de dépendances des workers, qui grossit avec chaque paquet pip ou npm utilisé. Ubuntu 22.04\u002F24.04 ou Debian 12 avec Docker Engine et le plugin Docker Compose v2 suffisent, plus un nom de domaine pointé sur le VPS pour le certificat TLS. Aucun GPU n'est requis. Si vous prévoyez d'exécuter des workers Python lourds (ML, pandas sur de grands jeux de données), optez pour 4 vCPU et 8 Go de RAM au moins.",{"type":41,"title":55,"items":56},"Dimensionner le VPS selon l'usage",[57,58,59,60],"**Règle de l'éditeur** : environ 1 worker par vCPU et 1 à 2 Go de RAM par worker. Un job qui dépasse la limite mémoire de son worker (2048 Mo par défaut) est tué avec le code de sortie 137.","**Usage solo ou essai** : 2 vCPU, 4 Go de RAM, 20 Go de disque, avec un seul worker généraliste en plus du worker natif. Suffisant pour des scripts planifiés et quelques webhooks.","**Petite équipe** : 4 vCPU, 8 Go de RAM, 40 Go de disque. Les trois workers du fichier officiel et PostgreSQL tiennent sur le même hôte sans saturer la mémoire.","**Plusieurs équipes ou jobs Python lourds** : 8 vCPU, 16 Go de RAM, 80 Go de disque pour six à huit workers. À ce stade, une base PostgreSQL séparée simplifie les sauvegardes et la montée de version.",{"type":62,"title":63,"steps":64},"steps","Déployer Windmill avec Docker Compose",[65,68,71,74,77,80,83],{"title":66,"body":67},"Récupérer les fichiers officiels","Connectez-vous en SSH à votre VPS et téléchargez les trois fichiers de référence publiés dans le dépôt Windmill : le `docker-compose.yml`, le `Caddyfile` du reverse proxy et le `.env` :\n\n```bash\nmkdir -p \u002Fopt\u002Fwindmill && cd \u002Fopt\u002Fwindmill\ncurl -fsSL https:\u002F\u002Fraw.githubusercontent.com\u002Fwindmill-labs\u002Fwindmill\u002Fmain\u002Fdocker-compose.yml -o docker-compose.yml\ncurl -fsSL https:\u002F\u002Fraw.githubusercontent.com\u002Fwindmill-labs\u002Fwindmill\u002Fmain\u002FCaddyfile -o Caddyfile\ncurl -fsSL https:\u002F\u002Fraw.githubusercontent.com\u002Fwindmill-labs\u002Fwindmill\u002Fmain\u002F.env -o .env\n```\n\nInutile de cloner tout le dépôt. Ces fichiers suivent la branche `main` : relisez-les avant chaque mise à jour, car la stack évolue (passage à PostgreSQL 18, service `windmill_extra`…).",{"title":69,"body":70},"Renseigner le fichier .env","Le `.env` ne porte que deux variables. Remplacez le mot de passe par défaut de PostgreSQL et épinglez l'image sur une version publiée plutôt que sur `main` (1.864.1 au 06\u002F11\u002F2026, à vérifier sur la page des releases GitHub) :\n\n```bash\nDATABASE_URL=postgres:\u002F\u002Fpostgres:MOT_DE_PASSE_FORT@db\u002Fwindmill?sslmode=disable\nWM_IMAGE=ghcr.io\u002Fwindmill-labs\u002Fwindmill:1.864.1\n```\n\nReportez le même mot de passe dans `POSTGRES_PASSWORD`, sous le service `db` du `docker-compose.yml`. L'hôte `db` est le nom du service PostgreSQL dans la stack : ne le remplacez pas par `localhost`. Pour utiliser une base existante, pointez `DATABASE_URL` vers elle et passez le service `db` à `replicas: 0`.",{"title":72,"body":73},"Démarrer la stack","Lancez l'ensemble et suivez le démarrage du serveur :\n\n```bash\ndocker compose up -d\ndocker compose ps\ndocker compose logs -f windmill_server\n```\n\n`docker compose ps` doit lister `db`, `windmill_server`, trois réplicas de `windmill_worker`, `windmill_worker_native`, `windmill_extra` et `caddy` ; l'indexeur de recherche plein texte (`windmill_indexer`) reste à zéro réplica, c'est une fonction Enterprise. Le serveur attend que PostgreSQL réponde à son healthcheck, puis applique lui-même les migrations de schéma. Il écoute sur le port 8000 du réseau Docker, sans être publié sur l'hôte : c'est Caddy qui reçoit le trafic.",{"title":75,"body":76},"Configurer le reverse proxy et le TLS","Le plus simple est de laisser le Caddy fourni obtenir le certificat Let's Encrypt. Dans le service `caddy` du `docker-compose.yml`, décommentez le port 443 et remplacez `BASE_URL=\":80\"` par votre domaine, puis relancez `docker compose up -d` :\n\n```yaml\n  caddy:\n    ports:\n      - 80:80\n      - 25:25\n      - 443:443\n    environment:\n      - BASE_URL=windmill.example.com\n```\n\nGardez le port 80 ouvert pour la validation. Si un nginx sert déjà d'autres sites sur le VPS, supprimez le service `caddy`, publiez `127.0.0.1:8000:8000` sur `windmill_server` et `127.0.0.1:3000:3000` sur `windmill_extra`, puis reproduisez le routage du `Caddyfile` : les chemins `\u002Fws\u002F`, `\u002Fws_mp\u002F` et `\u002Fws_debug\u002F` vont vers `windmill_extra`, tout le reste vers le serveur.\n\n```nginx\nlocation ~ ^\u002Fws(_mp|_debug)?\u002F {\n    proxy_pass http:\u002F\u002F127.0.0.1:3000;\n    proxy_http_version 1.1;\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection \"upgrade\";\n    proxy_set_header Host $host;\n}\nlocation \u002F {\n    proxy_pass http:\u002F\u002F127.0.0.1:8000;\n    proxy_http_version 1.1;\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection \"upgrade\";\n    proxy_set_header Host $host;\n    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n    proxy_set_header X-Forwarded-Proto $scheme;\n}\n```\n\nLes en-têtes `Upgrade` et `Connection` sont indispensables : l'éditeur passe par des WebSockets pour l'autocomplétion et le débogage. Le certificat s'obtient ensuite avec `certbot --nginx -d windmill.example.com`.",{"title":78,"body":79},"Se connecter et sécuriser","Ouvrez `https:\u002F\u002Fwindmill.example.com` et connectez-vous avec le compte superadmin par défaut, `admin@windmill.dev` \u002F `changeme`. L'assistant de premier lancement propose de le remplacer par votre propre compte : faites-le, car si vous sautez l'étape, les identifiants par défaut restent actifs, et c'est la faille la plus courante sur les instances Windmill exposées publiquement. Dans les **Instance settings**, fixez ensuite la Base URL sur l'adresse publique en `https:\u002F\u002F` : Windmill s'en sert pour construire les URL des webhooks et les liens de retour des flows. Créez enfin votre premier workspace avec un identifiant court (`prod`, `equipe-data`).",{"title":81,"body":82},"Ajuster le nombre de workers","Le fichier officiel démarre trois réplicas de `windmill_worker`, chacun plafonné à 2048 Mo. Sur un VPS de 4 Go, descendez à un ou deux ; sur une machine plus grosse, montez à un worker par vCPU :\n\n```bash\ndocker compose up -d --scale windmill_worker=2\ndocker compose ps windmill_worker\n```\n\nPour rendre le réglage permanent, modifiez `deploy.replicas` du service dans le `docker-compose.yml`. Le serveur n'a pas besoin de redémarrer : les workers se déclarent eux-mêmes et apparaissent dans la page **Workers** de l'interface, avec leur groupe (`default` ou `native`).",{"title":84,"body":85},"Mettre à jour Windmill","Changez le tag dans `WM_IMAGE` après avoir lu les notes de version, puis :\n\n```bash\ndocker compose pull\ndocker compose up -d\ndocker image prune\n```\n\nLe `pull` télécharge les nouvelles images pendant que les anciens conteneurs tournent encore ; au redémarrage, le serveur migre la base tout seul et les workers terminent leurs jobs en cours dans le délai d'arrêt de Docker (30 secondes). Faites une sauvegarde de la base juste avant, et ne lancez `docker image prune -a` que si le VPS n'héberge rien d'autre : la commande supprime aussi les images des autres projets.",{"type":37,"title":87,"body":88},"Configuration après l'installation","Une fois l'instance en ligne, six réglages décident de la façon dont vos scripts tourneront en production. Ils se font tous depuis l'interface, workspace par workspace.",{"type":41,"title":90,"items":91},"Les réglages essentiels",[92,93,94,95,96,97],"**Workspaces** : un workspace isole scripts, flows, secrets et membres. Créez-en un par équipe ou par environnement plutôt que de tout mélanger, et réservez le rôle superadmin à l'administration de l'instance.","**Variables et secrets** : toutes les variables sont chiffrées avec une clé symétrique propre au workspace ; celles marquées secrètes ne s'affichent plus dans l'interface après saisie. C'est l'endroit des jetons d'API et des mots de passe, jamais le code du script.","**Ressources** : des objets JSON typés (connexion PostgreSQL, compte SMTP, identifiants OAuth). Un paramètre typé `postgresql` dans un script ne propose alors que les ressources de ce type dans le formulaire généré.","**Planifications** : chaque script ou flow accepte un ou plusieurs schedules au format cron à cinq champs, avec un champ secondes facultatif en tête. Le gestionnaire d'erreur de schedule est une fonction Enterprise ; en Community Edition, surveillez les exécutions en échec depuis la liste des runs.","**Webhooks** : un script s'appelle en asynchrone par `\u002Fapi\u002Fw\u002F\u003Cworkspace>\u002Fjobs\u002Frun\u002Fp\u002F\u003Cchemin>` (réponse : l'identifiant du job) ou en synchrone par `\u002Fapi\u002Fw\u002F\u003Cworkspace>\u002Fjobs\u002Frun_wait_result\u002Fp\u002F\u003Cchemin>` (réponse : le résultat). Authentifiez avec l'en-tête `Authorization: Bearer \u003Cjeton>` plutôt qu'avec `?token=`, qui finit dans les journaux d'accès.","**Git Sync** : dans les paramètres du workspace, reliez un dépôt pour y pousser scripts, flows et ressources à chaque déploiement. Gratuit en Community Edition jusqu'à 2 utilisateurs par workspace ; le déploiement automatique depuis Git, lui, est réservé à l'édition Enterprise.",{"type":37,"title":99,"body":100},"Exemple : un script Python de bout en bout","Ce script interroge une API, garde les éléments actifs et les insère dans PostgreSQL via une ressource Windmill. Créez un script Python, collez le code et lancez-le depuis l'éditeur :\n\n```python\n# requirements:\n# httpx\n# psycopg2-binary\nfrom typing import TypedDict\n\nimport httpx\nimport psycopg2\n\n\nclass postgresql(TypedDict):\n    host: str\n    port: int\n    user: str\n    dbname: str\n    sslmode: str\n    password: str\n\n\ndef main(api_url: str, db: postgresql) -> dict:\n    resp = httpx.get(api_url, timeout=10)\n    resp.raise_for_status()\n    rows = [r for r in resp.json() if r.get(\"active\")]\n    conn = psycopg2.connect(\n        host=db[\"host\"], port=db[\"port\"], user=db[\"user\"],\n        password=db[\"password\"], dbname=db[\"dbname\"], sslmode=db[\"sslmode\"],\n    )\n    with conn, conn.cursor() as cur:\n        cur.executemany(\n            \"INSERT INTO items (id, name) VALUES (%(id)s, %(name)s) ON CONFLICT DO NOTHING\",\n            rows,\n        )\n    conn.close()\n    return {\"candidates\": len(rows), \"source\": api_url}\n```\n\nLes commentaires `# requirements:` remplacent la déduction automatique des dépendances à partir des imports : utile ici, car l'import `psycopg2` se publie sous le paquet `psycopg2-binary`. Windmill résout ces paquets, écrit un lockfile et les met en cache sur le worker, si bien qu'une même version du script tourne toujours avec les mêmes dépendances. La classe `postgresql`, nommée comme le type de ressource, fait apparaître un sélecteur de ressources dans le formulaire. Une fois déployé sous le chemin `f\u002Fetl\u002Fimport_items`, le script s'appelle depuis n'importe quel outil :\n\n```bash\ncurl -X POST \"https:\u002F\u002Fwindmill.example.com\u002Fapi\u002Fw\u002Fprod\u002Fjobs\u002Frun_wait_result\u002Fp\u002Ff\u002Fetl\u002Fimport_items\" \\\n  -H \"Authorization: Bearer $WM_TOKEN\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"api_url\": \"https:\u002F\u002Fapi.example.com\u002Fitems\"}'\n```",{"type":102,"title":103,"body":104},"tip","Durcissement de l'instance","Ne publiez jamais les ports 8000 et 3000 sur l'interface publique : seul le reverse proxy doit les atteindre, en local. Sauvegardez la base avec `docker compose exec -T db pg_dumpall -U postgres | gzip > \u002Fbackups\u002Fwindmill-$(date +%F).sql.gz` : le dump doit couvrir tout le cluster, pas la seule base `windmill`, car Windmill crée des bases annexes et attache ses politiques de sécurité à des rôles de niveau cluster. Ce dump contient vos secrets chiffrés : stockez-le hors du VPS et protégez-le comme un secret. Ne montez le socket Docker dans les workers que si vous faites confiance à tous les utilisateurs de l'instance, puisqu'il donne aux scripts la main sur l'hôte. Enfin, laissez `REQUIRE_SIGNED_DEBUG_REQUESTS=true` sur `windmill_extra` : le désactiver sur une instance joignable depuis Internet expose un débogueur capable d'exécuter du code sans authentification.",{"type":37,"title":106,"body":107},"Dépannage : les erreurs d'un premier déploiement","La plupart des incidents viennent de la base de données, de la mémoire des workers ou du reverse proxy. Les symptômes et leurs corrections :",{"type":41,"title":109,"items":110},"Symptômes et corrections",[111,112,113,114,115],"**Le conteneur `db` s'arrête aussitôt après une mise à jour** : le volume a été créé par PostgreSQL 16 et l'image est passée en 18, qui refuse de le lire. Suivez la procédure de migration de la documentation (dump complet puis restauration), ou épinglez `postgres:16` avec son ancien point de montage : la version 16 reste maintenue jusqu'en novembre 2028.","**Job interrompu avec le code 137** : il a dépassé la limite mémoire de son worker. Augmentez `resources.limits.memory` du service `windmill_worker`, ou réduisez la taille des données chargées en mémoire par le script.","**Serveur ou workers incapables de joindre la base** : `DATABASE_URL` pointe vers `localhost` au lieu du service `db`, ou le mot de passe diffère de `POSTGRES_PASSWORD`. Corrigez le `.env`, puis `docker compose up -d` pour recréer les conteneurs.","**`ModuleNotFoundError` ou installation de dépendances en échec** : le worker télécharge les paquets à la première exécution et doit joindre `pypi.org` et `files.pythonhosted.org` en HTTPS sortant. Derrière un proxy d'entreprise, les variables `PY_TRUSTED_HOST` et `PY_INDEX_CERT` règlent la confiance ; un index privé se déclare dans les Instance settings (édition Enterprise).","**Éditeur sans autocomplétion, débogueur muet** : le reverse proxy ne route pas `\u002Fws\u002F`, `\u002Fws_mp\u002F` et `\u002Fws_debug\u002F` vers `windmill_extra`, ou il supprime les en-têtes `Upgrade` et `Connection`. Reprenez le routage du `Caddyfile` officiel.",{"type":117,"title":118,"headers":119,"rows":124},"comparison","Windmill, n8n ou Temporal",[120,121,122,123],"Critère","Windmill","n8n","Temporal",[125,130,135,140],[126,127,128,129],"Écriture des workflows","Scripts Python, TypeScript, Go, Bash, SQL… assemblés en flows","Canevas de nœuds ; nœud Code en JavaScript ou Python","Code applicatif via SDK (Go, Java, Python, TypeScript, .NET, PHP, Ruby, Rust)",[131,132,133,134],"Licence","AGPLv3 pour le cœur ; Community Edition gratuite avec quotas, fonctions Enterprise sous licence","Sustainable Use License (fair-code), fichiers `.ee` sous licence commerciale","MIT pour le serveur",[136,137,138,139],"Interface","Éditeur web, formulaires et apps internes générés","Éditeur visuel de nœuds","Interface web d'observation ; le code s'écrit hors de l'outil",[141,142,143,144],"Pour qui","Équipes qui écrivent du code et veulent l'exposer vite","Intégrations visuelles entre SaaS","Processus longs à forte exigence de durabilité",{"type":102,"body":146},"**L'installer en un clic depuis le Marketplace ServOrbit.** Si vous préférez éviter la configuration manuelle, le Marketplace ServOrbit provisionne Windmill automatiquement — serveur, deux workers, PostgreSQL 16, reverse proxy nginx et certificat Let's Encrypt — en quelques minutes. La section « Premier accès » de votre espace client indique l'URL et les identifiants générés. La fiche Windmill, accessible depuis le bouton en fin d'article, permet de démarrer.","Déployez Windmill en un clic sur votre VPS ServOrbit","Le Marketplace ServOrbit provisionne automatiquement Windmill avec PostgreSQL 16, deux workers et un reverse proxy — vos scripts tournent en production en quelques minutes, sans ligne de configuration.","Voir la fiche Windmill","\u002Fapplications\u002Fautomatisation\u002Fwindmill",[152,170,187],{"id":153,"slug":154,"slugs":155,"title":159,"excerpt":160,"readTime":161,"views":162,"isPinned":19,"noindex":19,"publishedAt":163,"updatedAt":164,"category":165,"categories":166,"featuredImage":29,"bgImage":30,"posterImage":168,"relatedSolution":169},3,"installer-n8n-vps",{"fr":154,"en":156,"ar":157,"es":158},"install-n8n-on-vps-with-docker-complete-2026-guide","تثبيت-n8n-على-vps-مع-docker-دليل-شامل-2026","instalar-n8n-en-vps-con-docker","Installer n8n sur VPS avec Docker : guide complet 2026","Déployez n8n sur VPS avec Docker, reverse proxy et HTTPS. Crash V8, 502 nginx, migration npm vers Docker et sécurisation des exécutions persistées (advisory août 2026).",19,4,"2026-06-05T00:00:00+00:00","2026-11-09T20:55:18+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[167],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Finstaller-n8n-vps-poster.svg",{"categorySlug":25,"appSlug":122},{"id":171,"slug":172,"slugs":173,"title":177,"excerpt":178,"readTime":162,"views":23,"isPinned":19,"noindex":19,"publishedAt":179,"updatedAt":180,"category":181,"categories":182,"featuredImage":29,"bgImage":30,"posterImage":184,"relatedSolution":185},26,"installer-activepieces-vps",{"fr":172,"en":174,"ar":175,"es":176},"installing-activepieces-on-a-vps-self-hosted-automation","تثبيت-activepieces-على-خادم-vps-أتمتة-ذاتية-الاستضافة","instalar-activepieces-en-un-vps","Installer Activepieces sur un VPS : automatisation self-hosted","Déployez Activepieces sur votre VPS : automatisation no-code self-hosted, données privées, intégrations illimitées et déploiement Docker en 15 minutes.","2026-05-25T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[183],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Finstaller-activepieces-vps-poster.svg",{"categorySlug":25,"appSlug":186},"activepieces",{"id":188,"slug":189,"slugs":190,"title":194,"excerpt":195,"readTime":162,"views":18,"isPinned":19,"noindex":19,"publishedAt":196,"updatedAt":197,"category":198,"categories":199,"featuredImage":29,"bgImage":30,"posterImage":201,"relatedSolution":202},24,"installer-node-red-vps",{"fr":189,"en":191,"ar":192,"es":193},"installing-node-red-on-a-vps-self-hosted-automation","تثبيت-node-red-على-خادم-vps-أتمتة-ذاتية-الاستضافة","instalar-node-red-en-un-vps","Installer Node-RED sur un VPS : automatisation self-hosted","Installez Node-RED sur un VPS pour automatiser vos workflows en flow-based, connecter vos API et objets IoT, le tout self-hosted et sécurisé.","2026-05-27T00:00:00+00:00","2026-11-04T16:30:24+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[200],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Finstaller-node-red-vps-poster.svg",{"categorySlug":25,"appSlug":203},"node-red",true,1794270741140]