Pangolin étend son contrôle d’accès aux modèles d’IA et simplifie son déploiement sur plusieurs serveurs. La version 1.22 ajoute une passerelle pour les API cloud ou auto-hébergées et ouvre plusieurs accès distants à Community Edition. La 1.23 rend le clustering déployable sans accompagnement du fournisseur et intègre le connecteur de site à la CLI. Deux versions qui méritent un détour, que l’on cherche à partager un Ollama dans son homelab ou à rendre une instance Pangolin plus disponible.
En bref#
- 1.22 : une AI Gateway centralise les fournisseurs, les droits, les clés et les budgets, y compris pour des modèles locaux joints par tunnel.
- Davantage d’accès en Community : SSH, RDP et VNC dans le navigateur, ainsi que les ressources privées SSH et HTTPS.
- 1.23 : un clustering documenté et déployable soi-même, toujours dans Enterprise Edition, avec PostgreSQL, Redis ou Valkey et un répartiteur de charge à prévoir.
- Une CLI commune pour les sites et les clients. Les installations Newt existantes continuent de fonctionner.
Les releases GitHub sont datées du 27 août 2026 pour la 1.22.0 et du 16 septembre pour la 1.23.0. Les annonces du projet les précèdent, respectivement le 24 août et le 15 septembre.
Ce que fait réellement l’AI Gateway#
Une AI Gateway est une ressource Pangolin avec son propre nom de domaine. Les clients appellent cette adresse ; Pangolin contrôle l’accès puis transmet la requête au fournisseur associé. Les clés réelles restent côté passerelle, au lieu d’être copiées dans les fichiers d’environnement de chaque utilisateur ou agent.
Le fournisseur est configuré au niveau de l’organisation, puis attaché à une ou plusieurs passerelles. Une même URL peut ainsi donner accès à plusieurs modèles cloud et locaux. Des listes d’autorisation et de blocage déterminent les modèles exposés.
Les intégrations prédéfinies couvrent notamment OpenAI, Anthropic, Gemini, Vertex AI, Bedrock et OpenRouter. Le type Custom sert aux autres API compatibles, dont les serveurs auto-hébergés. Il faut faire correspondre les capacités du fournisseur à celles du client : une passerelle configurée pour Chat Completions ne fournit pas automatiquement l’API Responses ou Anthropic Messages.
Ollama à la maison, utilisable depuis l’extérieur#
Prenons un Ollama installé sur une machine du homelab, avec les modèles et le GPU sur place. Depuis un portable en déplacement, on veut continuer à utiliser cette machine, ou en partager l’accès avec quelques personnes. La passerelle donne une URL commune, par exemple https://ia.example.net/v1, à configurer dans un client de chat ou un outil compatible OpenAI. Les droits sont gérés dans Pangolin.
Le connecteur du site rejoint Ollama sur le LAN. Pangolin lui transmet les appels par le tunnel, via un Site Target configuré sur le fournisseur. Le port 11434 d’Ollama n’a donc pas besoin d’être ouvert sur Internet. Le calcul reste effectué par la machine locale : le serveur qui héberge Pangolin assure le relais et le contrôle d’accès, sans exécuter le modèle. Ce routage est décrit dans la documentation des fournisseurs personnalisés.
L’intérêt dépasse l’accès à distance : on peut partager quelques modèles autorisés, attribuer les appels aux utilisateurs et limiter leur consommation en tokens. Une clé Pangolin peut servir à un outil externe ; un poste déjà connecté au réseau privé Pangolin peut utiliser son identité existante. On retrouve ainsi le même contrôle d’accès que pour les autres services du homelab.
Dans ce montage, « local » désigne l’endroit où tourne le modèle. Les requêtes et réponses transitent par Pangolin : si l’instance tourne sur un VPS, celui-ci fait partie du trajet des données.
Passerelle publique ou privée#
Les deux modes ne répondent pas au même besoin.
| Passerelle publique | Passerelle privée | |
|---|---|---|
| Exposition | FQDN public | Réseau Pangolin uniquement |
| Authentification | Clé API virtuelle à chaque requête | Identité du client Pangolin connecté |
| Usage typique | CI, prestataires, services sans client Pangolin | Postes et machines déjà rattachés au réseau privé |
| Secret côté client | Clé Pangolin | Aucun secret utile, éventuellement none comme valeur factice |
Sur une ressource publique, chaque utilisateur possède une clé d’identité liée à son compte. Les droits suivent les utilisateurs et les rôles attribués à la ressource. Pour une CI ou un service, un administrateur peut créer une clé manuelle limitée à certaines passerelles. Attention à cette différence : une clé manuelle accorde directement l’accès aux passerelles sélectionnées, indépendamment de leurs droits utilisateurs et rôles. La documentation des clés virtuelles distingue ces deux mécanismes.
La clé virtuelle n’est pas la clé OpenAI ou Anthropic. Pangolin la vérifie, l’utilise pour attribuer la requête, puis la retire avant de transmettre l’appel avec le secret du fournisseur.
Une ressource privée n’accepte que le trafic venant du tunnel Pangolin. L’identité est déjà portée par la connexion du client. Certains outils refusent toutefois de démarrer sans champ de clé API. La documentation recommande alors la valeur littérale none, qui ne sert pas à authentifier la requête.
Le gain est concret pour une équipe : révoquer l’accès d’un agent ne demande plus de remplacer la clé fournisseur sur tous les postes. En contrepartie, Pangolin concentre ces secrets. Les comptes administrateurs et les sauvegardes de l’instance doivent donc être protégés comme ceux d’un service qui détient des clés d’API.
Budgets et suivi d’usage : utiles, avec quelques limites#
Pangolin peut appliquer un budget en tokens ou en dollars à un fournisseur, un modèle, une ressource, un rôle ou une clé virtuelle. Tous les budgets correspondants sont vérifiés avant l’envoi. Si l’un est déjà atteint, la requête est refusée.
Le contrôle utilise la consommation déjà enregistrée : l’appel qui franchit le plafond peut encore terminer. Les périodes sont glissantes, avec les dernières 24 heures pour un budget quotidien. Le montant affiché reste une estimation à partir des tarifs du catalogue, pas une copie de la facture du fournisseur.
Un point compte particulièrement avec les modèles locaux : un modèle absent du catalogue ne contribue pas au budget en dollars. Le budget en tokens continue de comptabiliser son usage, mesuré ou estimé quand le fournisseur ne le renvoie pas. C’est donc le plafond le plus utile pour commencer avec un modèle interne.
Le catalogue provient par défaut de api.fossorial.io. Une instance auto-hébergée peut le remplacer par un fichier local ou une URL interne, notamment pour ajouter ses propres modèles et tarifs.
Les statistiques de consommation sont distinctes des journaux de session. Ces derniers enregistrent prompts, réponses et corps bruts des échanges. Ils sont réservés à Pangolin Cloud et à Enterprise Edition auto-hébergée, et désactivés par défaut avec une rétention de zéro jour. Activer leur conservation revient à stocker les données envoyées aux modèles, potentiellement du code ou des informations internes : la durée de rétention et l’accès aux sauvegardes doivent suivre cette sensibilité.
Exemple avec Ollama sur un réseau privé#
La procédure officielle pour Ollama utilise l’API compatible OpenAI sur /v1/chat/completions, et non l’API native /api/chat. Le site doit être connecté à un nœud serveur Pangolin : les sites rattachés à un Remote Node ne sont pas utilisables comme cibles de fournisseur IA.
- Installer ou réutiliser un connecteur de site capable de joindre la machine Ollama.
- Dans AI Gateway > Providers, créer un fournisseur
Custom. - Activer la capacité OpenAI Chat Completions.
- Choisir Site Targets comme mode de routage.
- Choisir
No Authpour un serveur local sans authentification amont. - Autoriser les identifiants exacts des modèles installés que l’on veut publier, puis enregistrer le fournisseur.
- Dans son onglet Network, ajouter l’adresse Ollama joignable depuis le connecteur, en HTTP sur le port
11434. - Créer une ressource AI Gateway publique ou privée et lui attacher ce fournisseur.
- Accorder l’accès uniquement aux utilisateurs et rôles nécessaires, ou aux identités machine pour une passerelle privée.
Pourquoi 127.0.0.1 ne fonctionne souvent pas#
La cible est jointe depuis le réseau du connecteur. Si celui-ci tourne dans un conteneur Docker en mode bridge, 127.0.0.1 désigne ce conteneur, pas l’hôte ni le conteneur Ollama.
Avec Ollama et le connecteur sur un même réseau Docker défini par l’utilisateur, utilisez le nom du service, par exemple ollama, et le port 11434. Si Ollama tourne sur une autre machine, renseignez son adresse privée. Dans les deux cas, il doit écouter sur une interface joignable depuis le connecteur ; son port peut rester réservé à ce réseau.
Sur l’hôte Ollama, si le serveur écoute sur la boucle locale et que curl et jq sont installés, cette commande en lecture seule liste les modèles disponibles :
curl -fsS http://127.0.0.1:11434/api/tags | jq -r '.models[].name'L’API de liste des modèles renvoie leurs noms dans models[].name. Reprenez ces identifiants dans la liste d’autorisation. Une réponse locale valide le serveur Ollama, mais pas encore le tunnel ni les droits Pangolin. Pour vérifier l’ensemble, configurez ensuite un client compatible Chat Completions avec l’URL de la passerelle et appelez l’un des modèles autorisés.
SSH, RDP et VNC arrivent en Community#
L’autre apport de la 1.22 intéressera ceux qui n’hébergent aucun modèle. Les ressources publiques SSH, RDP et VNC, utilisables depuis le navigateur après authentification Pangolin, rejoignent Community Edition. Les ressources privées SSH et HTTPS accessibles par le client Pangolin deviennent elles aussi disponibles dans cette édition. Le tableau de bord y affiche également l’état des certificats TLS. Ces changements sont détaillés dans l’annonce de la 1.22.
Pour un homelab, c’est probablement le bénéfice le plus immédiat : davantage d’accès interactifs peuvent être centralisés avec les comptes et les règles déjà en place, sans changer d’édition.
La 1.23 simplifie le clustering#
La haute disponibilité existait déjà dans Pangolin. Son déploiement dépendait cependant de composants externes propriétaires, notamment pour le DNS et les certificats, et d’un accompagnement contractuel. La 1.23 intègre ces fonctions au conteneur Pangolin et fournit une procédure publique pour monter son cluster soi-même.
La fonction reste réservée à Enterprise Edition, avec disponibilité annoncée dans l’offre Scale et les contrats Enterprise. Cela ne signifie pas qu’un particulier doit acheter une licence : le projet propose une clé gratuite pour l’usage personnel et les organisations dont le chiffre d’affaires annuel brut est inférieur à 100 000 dollars. L’image Enterprise et une clé valide restent nécessaires, comme le précise la documentation des licences.
Ce qu’il faut réellement déployer#
Le cluster de référence repose sur plusieurs éléments :
| Composant | Rôle |
|---|---|
| Au moins deux nœuds Pangolin, chacun avec Gerbil et Traefik | Servir les accès et maintenir les tunnels |
| PostgreSQL partagé | Conserver l’état persistant et les certificats chiffrés |
| Redis ou Valkey avec pub/sub | Synchroniser les nœuds |
| Un répartiteur de charge hautement disponible | Distribuer les accès au tableau de bord, à l’API et au DNS |
Les nœuds ont chacun une IP publique fixe et doivent communiquer entre eux. Une délégation DNS est également nécessaire. PostgreSQL et Redis peuvent être fournis par une infrastructure existante ou des services managés. Le cluster ne prend en charge que les Pangolin Sites, pas les sites locaux ni les sites WireGuard basiques.
L’architecture documentée utilise le DNS pour orienter les ressources vers le nœud auquel leur site est connecté. Si le cache DNS envoie une requête sur un autre nœud disponible, Gerbil peut la transmettre au bon endroit. Lors d’une panne, le connecteur détecte l’échec puis rejoint un nœud disponible. Une brève interruption reste donc possible pendant cette reconnexion.
Deux nœuds Pangolin ne suffisent pas à rendre toute l’installation redondante : il faut aussi assurer la disponibilité de PostgreSQL, de Redis ou Valkey et du répartiteur. Le guide de déploiement confie par ailleurs l’émission et le renouvellement des certificats à un seul client ACME actif dans le cluster. Ce rôle doit figurer dans le plan de reprise.
Pour une équipe qui exploite déjà ces services, le déploiement autonome enlève un obstacle appréciable. Pour un homelab sur un seul VPS, l’intérêt dépend surtout du besoin de continuité : le cluster ajoute plusieurs composants à administrer.
Les sites passent par la CLI, Newt reste disponible#
La 1.23 intègre Newt dans Pangolin CLI. L’assistant de création recommande désormais cette méthode et emploie le nom Pangolin Site. Le connecteur Newt autonome reste disponible, plus léger, et ses installations existantes continuent de fonctionner.
Après installation de la CLI et création d’un site dans le tableau de bord, la commande documentée pour démarrer le connecteur est :
pangolin up site \
--id ID_DU_SITE \
--secret SECRET_DU_SITE \
--endpoint https://pangolin.example.comRemplacez l’identifiant, le secret et l’adresse par ceux de votre instance. Cette commande démarre la connexion du site ; vérifiez son état en ligne dans le tableau de bord. Pour une connexion persistante au redémarrage, la même documentation décrit l’installation en service sous Linux, macOS et Windows, ainsi que l’image Docker fosrl/pangolin-cli.
La 1.23 permet aussi de nommer plusieurs administrateurs serveur et ajoute une liste globale des organisations. Le Resource Launcher affiche les sites associés à une ressource et fournit une commande à copier pour les accès SSH privés. Des changements modestes, mais utiles quand plusieurs personnes administrent la même instance. La release 1.23.0 les récapitule.
Préparer la mise à jour#
Sur un serveur Linux avec Docker Compose, placez-vous dans le répertoire du fichier Compose. Ces commandes en lecture seule affichent les images déclarées et l’état des conteneurs :
sudo docker compose config --images
sudo docker compose psLe plugin Badger est déclaré dans la configuration statique de Traefik. Sur une installation standard :
grep -A3 -n 'github.com/fosrl/badger' \
config/traefik/traefik_config.ymlSi vous venez d’une version antérieure à la 1.22, contrôlez les prérequis de l’AI Gateway :
- Badger doit être en version
v1.6.0ou plus récente ; - les passerelles privées nécessitent le support introduit dans Gerbil
1.5.0; - les clients Pangolin doivent intégrer le support publié après le 19 août 2026 pour joindre une passerelle privée.
La migration tente de mettre Badger à jour dans la configuration Traefik standard, mais ne met pas Gerbil à jour. La sortie de grep doit montrer la version du plugin ; l’absence de résultat impose de retrouver la configuration réellement utilisée.
Pour une installation à un seul nœud, suivez la procédure de mise à jour. Conservez d’abord une copie des fichiers Compose et Traefik avec leurs versions actuelles, puis modifiez les versions à mettre à jour et téléchargez les images. Gardez votre édition Community ou Enterprise.
Les étapes suivantes interrompent les accès pendant l’arrêt et les migrations. Gardez un accès d’administration indépendant du tunnel Pangolin.
sudo docker compose pull
sudo docker compose downUne fois la stack arrêtée, sauvegardez le répertoire config et la base utilisée. Avec PostgreSQL externe, la copie de config ne contient pas la base. Un retour arrière peut nécessiter de restaurer cette base et les anciens fichiers de configuration en plus des images précédentes.
Après cette sauvegarde, relancez :
sudo docker compose up -d
sudo docker compose logs -fVérifiez l’absence d’erreur de migration, puis ouvrez le tableau de bord, contrôlez les sites et testez une ressource déjà utilisée. Si vous activez l’AI Gateway, ajoutez un appel avec votre client réel et vérifiez son attribution dans les statistiques d’usage.
Sources#
- Annonce officielle de Pangolin 1.22
- Release Pangolin 1.22.0 sur GitHub
- Annonce officielle de Pangolin 1.23
- Release Pangolin 1.23.0 sur GitHub
- Vue d’ensemble de l’AI Gateway
- Fournisseurs et capacités d’API
- Fournisseurs personnalisés et routage vers les sites
- Documentation des ressources AI Gateway publiques
- Documentation des ressources AI Gateway privées
- Clés virtuelles et droits d’accès
- Budgets et limites de calcul
- Catalogue de modèles et tarifs
- Journaux de session AI Gateway
- Configurer Ollama comme fournisseur
- API Ollama : lister les modèles
- Réseaux bridge Docker
- Architecture du clustering
- Prérequis du clustering
- Déployer un cluster
- Enterprise Edition et licences
- Installer un connecteur de site avec Pangolin CLI
- Procédure officielle de mise à jour
