Auto-héberger OneCLI avec Docker Compose

Ce que vous obtenez en auto-hébergeant OneCLI

En auto-hébergeant OneCLI, chaque personne de votre équipe dispose de son propre agent. Chaque agent s’exécute dans son propre sandbox. Les clés d’API sont conservées dans une gateway que les agents ne peuvent jamais lire. L’installation est une stack Docker Compose avec PostgreSQL en arrière-plan, accessible sur http://localhost:10254. Prévoyez une machine adaptée. La valeur par défaut documentée est de 2 GiB de mémoire par sandbox d’agent. Cette charge de travail ne convient donc pas à un VPS de 1 GB.

Cette stack contient sept composants. Savoir à quoi chacun sert facilite la lecture de la suite de ce guide.

• Tableau de bord Web (Next.js), port 10254. Création des agents, chat, modification de la mémoire et des skills, connexions et secrets.
• Serveur d’API, port 10256. Le control plane : base de données, gestion des conversations et files de tâches.
• Gateway Rust, port 10255. Intercepte les requêtes sortantes des agents et injecte les identifiants.
• Runner. Le README le décrit comme le composant qui « démarre, met en pause et supprime les sandbox des agents. Il est limité aux connexions sortantes et n’accède jamais à la base de données. »
• Sandbox Supervisor. Le README le décrit comme un composant qui s’exécute « dans chaque sandbox et utilise une interface de harness indépendante du fournisseur, afin que le runtime de l’agent puisse être remplacé. »
• Adaptateur de canal. Un daemon qui connecte une application Slack afin qu’un agent réponde dans les canaux et les messages directs sous son propre nom.
• PostgreSQL. Le fichier Compose fourni exécute postgres:18-alpine avec un volume pgdata.

Le nom évoque une CLI, mais le produit est un serveur

OneCLI est une plateforme serveur. Son nom fait penser à un outil en ligne de commande installé sur un ordinateur portable, mais cette description ne correspond pas au produit présenté dans ce guide. Un client en ligne de commande distinct existe bien dans le dépôt onecli/onecli-cli. Il fait transiter le trafic d’un agent de code local par une gateway. Ce que vous déployez ici est une application web multi-utilisateur : un système de comptes dans lequel le premier compte devient propriétaire de l’instance, une base de données contenant les conversations et les secrets, ainsi qu’un runner qui démarre des conteneurs.

Le modèle par personne constitue le fondement de la conception. Le README indique : « Vous créez un agent par personne, vous donnez à chaque agent les accès dont il a besoin, puis il fonctionne dans un sandbox, en passant par une gateway qui injecte les identifiants et applique votre politique. » Chaque agent possède son propre système de fichiers et son propre shell, sa propre page de conversation, la mémoire conservée par la plateforme et les skills que vous écrivez une seule fois. La gestion des identifiants fonctionne à l’inverse de la configuration habituelle. Au lieu de copier une clé d’API dans l’environnement de chaque personne, vous stockez la clé une seule fois et vous l’accordez aux agents autorisés à l’utiliser.

Prérequis de la machine

• Docker, avec le plugin Compose en version 2.19 ou ultérieure. Le fichier Compose utilise un service de migration exécuté une seule fois, dont l’API attend la fin. Cette forme de dépendance nécessite la version 2.19.
• De la mémoire, qui constitue la vraie contrainte. Lisez la section sur le dimensionnement ci-dessous avant de choisir une offre.
• Les ports loopback libres 10254, 10255, 10256 et 5432.

Vous n’avez pas besoin d’installer PostgreSQL vous-même : le fichier Compose l’exécute comme un service. Vous n’avez pas non plus besoin de Node.js ni de Rust. Ces outils servent uniquement pour la procédure de compilation depuis les sources, dans laquelle mise verrouille la toolchain.

Combien de bacs à sable d’agents peuvent tenir sur votre VPS ?

La documentation du runner fournit des chiffres concrets. Chaque bac à sable dispose de 2048 Mo de mémoire (RUNNER_SANDBOX_MEMORY_MB), d’un CPU (RUNNER_SANDBOX_CPUS) et de 512 processus (RUNNER_SANDBOX_PIDS). La limite de concurrence est de 4 (RUNNER_MAX_SANDBOXES), et la documentation recommande environ 10 GiB de mémoire libre en plus de la stack de base pour respecter cette limite.

[
  {
    "plan": "2 GB box",
    "ram_gb": 2,
    "sandbox_slots": 0
  },
  {
    "plan": "4 GB box",
    "ram_gb": 4,
    "sandbox_slots": 1
  },
  {
    "plan": "8 GB box",
    "ram_gb": 8,
    "sandbox_slots": 3
  },
  {
    "plan": "16 GB box",
    "ram_gb": 16,
    "sandbox_slots": 7
  },
  {
    "plan": "32 GB box",
    "ram_gb": 32,
    "sandbox_slots": 15
  }
]

Ces nombres de slots sont issus d’un calcul, pas d’un benchmark : la mémoire totale, moins environ 2 GB pour PostgreSQL et les quatre services persistants, divisée par la limite de 2 GiB par bac à sable. Sur cette base, le 2 GB box peut héberger 0 bacs à sable, ce qui signifie que l’offre la moins chère ne peut pas exécuter d’agent hébergé. Une 16 GB box laisse de la place pour 7, largement au-dessus de la limite par défaut de quatre et des environ 10 GiB de mémoire libre demandés par la documentation du runner. La 32 GB box permet d’atteindre 15.

Deux éléments modifient ce calcul. Un bac à sable qui exécute un processus en arrière-plan ne se met jamais en veille. Il conserve donc son slot en permanence. Vous devez dimensionner RUNNER_MAX_SANDBOXES pour la charge soutenue, et non pour la minute la plus chargée. La mémoire vient aussi à manquer avant le CPU. Chaque bac à sable est limité à un CPU. Quatre agents très sollicités veulent donc quatre cœurs, mais quatre agents inactifs qui restent actifs occupent tout de même 8 GiB.

Installer OneCLI avec Docker Compose

La documentation officielle d’auto-hébergement fournit cette séquence exacte. Elle écrit trois secrets dans docker/.env, à côté du fichier Compose, puis démarre la stack.

git clone https://github.com/onecli/onecli.git && cd onecli/docker
cat > .env <<EOF
SECRET_ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
GATEWAY_INTERNAL_SECRET=$(head -c 32 /dev/urandom | base64)
BETTER_AUTH_SECRET=$(head -c 32 /dev/urandom | base64)
COMPOSE_PROFILES=runner
EOF
chmod 600 .env
docker compose up -d --wait

Lisez ce bloc avant de l’exécuter. Le marqueur heredoc n’est pas entre guillemets : votre shell exécute donc chaque head -c 32 /dev/urandom | base64 et écrit le résultat au lieu du texte littéral. SECRET_ENCRYPTION_KEY est la clé AES-256-GCM utilisée pour chaque secret de la base de données. GATEWAY_INTERNAL_SECRET authentifie la gateway auprès de l’API. BETTER_AUTH_SECRET signe les cookies de session. COMPOSE_PROFILES=runner est la ligne la plus importante, car le service runner se trouve derrière un profil Compose : si vous l’omettez, la stack démarre correctement, mais aucun sandbox d’agent ne démarre.

--wait bloque le shell jusqu’à ce que chaque service soit signalé comme sain. Une sortie différente de zéro est donc le premier indice d’un problème. Vérifiez ensuite les services qui ont réellement démarré.

docker compose ps
docker compose logs migrations

Figez la version. ONECLI_VERSION définit le tag de tous les services en une seule fois. L’image du sandbox d’agent suit cette version, sauf si RUNNER_AGENT_IMAGE pointe vers une autre image. Au 19 août 2026, la version actuelle est v2.0.1, publiée le 18 août 2026. Ajoutez-la au même fichier, puis redémarrez la stack.

echo 'ONECLI_VERSION=v2.0.1' >> .env
docker compose up -d --wait

Un installateur existe également : curl -fsSL https://onecli.sh/install | sh. Il écrit sa configuration dans ~/.onecli/.env et effectue les mêmes opérations. La méthode Compose permet de lire chaque fichier avant toute exécution. Utilisez-la sur un serveur qui héberge déjà d’autres stacks Compose. La compilation depuis les sources constitue une troisième méthode, documentée sous la forme pnpm install puis pnpm run setup dans le dépôt cloné. Cette méthode nécessite mise, Rust pour la gateway et Docker malgré tout. Elle s’adresse aux personnes qui prévoient de modifier le code.

Accéder au tableau de bord depuis votre ordinateur portable

Chaque port publié dans le fichier compose fourni est lié à ${ONECLI_BIND_HOST:-127.0.0.1}. Sur un VPS, cela signifie que le tableau de bord fonctionne, mais qu’aucune connexion extérieure ne peut l’atteindre. Ce réglage par défaut est correct. Conservez-le et créez un tunnel :

ssh -N -L 10254:127.0.0.1:10254 you@your-server

Ouvrez maintenant http://localhost:10254 sur votre ordinateur portable. Le trafic passe par la connexion SSH. Le tableau de bord n’est donc pas exposé en HTTP non chiffré sur Internet et vous n’avez pas besoin d’ouvrir un port supplémentaire dans le firewall.

Le réglage ONECLI_BIND_HOST=0.0.0.0 publie le tableau de bord en HTTP non chiffré et publie également PostgreSQL. Si plusieurs personnes doivent accéder au tableau de bord, placez un reverse proxy avec TLS (transport layer security) devant le port 10254 et ne modifiez pas l’adresse de bind. Faites-le avant d’attribuer un propriétaire à l’instance. La documentation amont explique clairement pourquoi : « Tant que ce n’est pas fait, l’instance n’a pas de propriétaire et, sur un hôte accessible, la première personne qui y accède devient propriétaire. » Si ce proxy est déjà placé devant vos autres applications auto-hébergées, le forward auth via une couche d’authentification unique auto-hébergée place le tableau de bord derrière le login que votre équipe utilise déjà. La suppression d’un utilisateur à un seul endroit ferme donc également cet accès.

Créer le premier compte, puis accorder une clé de modèle

Ouvrez le tableau de bord et créez immédiatement le compte. Ce compte possède l’instance. Une fois le compte créé, la participation nécessite une invitation.

Enregistrez ensuite une clé de modèle avant de créer un agent. Un agent hébergé a besoin d’une clé de modèle qui lui est accordée. L’ordre est important : enregistrez la clé dans le tableau de bord, accordez-la à l’agent, puis démarrez seulement une conversation. Si vous omettez cette autorisation, le sandbox ne se lance jamais. L’agent reste alors inactif.

Accordez uniquement les autorisations nécessaires. Chaque agent reçoit uniquement les accès que vous lui avez accordés, et la gateway les applique à chaque requête. Un agent qui lit un seul dépôt ne peut donc pas accéder à la clé de votre fournisseur de paiement. La même liste d’autorisations vous permet aussi de contrôler les dépenses. Un agent par personne pouvant appeler n’importe quel modèle que vous possédez génère une facture par personne. Lisez donc comment plafonner les dépenses d’un agent pour les appels de modèle avant d’en distribuer dix.

Comment la gateway conserve les clés hors des agents

La gateway est un proxy HTTPS écrit en Rust, à l’écoute sur le port 10255. Le client HTTP d’un agent est configuré pour l’utiliser, et l’agent envoie un identifiant factice au lieu d’un identifiant réel. La gateway compare la requête sortante aux autorisations de cet agent, déchiffre le secret réel, le remplace dans la requête, puis la transmet. Les secrets sont stockés dans PostgreSQL, chiffrés avec AES-256-GCM (advanced encryption standard, 256-bit, Galois/counter mode), et ne sont déchiffrés qu’au moment de la requête. Chaque appel est journalisé avec l’identité de l’agent et sa cible. Vous disposez ainsi d’une piste d’audit impossible à obtenir lorsque les clés sont stockées dans les profils shell de dix personnes.

Deux mécanismes déterminent le mode de déploiement.

• L’interception HTTPS est une attaque de type man-in-the-middle. La gateway génère une autorité de certification locale, l’agent lui fait confiance, puis la gateway termine la connexion TLS de l’agent et en ouvre une nouvelle vers le service upstream. C’est pourquoi un agent dont le client HTTP ne fait pas confiance à l’autorité de certification de la gateway échoue avec une erreur de vérification du certificat, et non avec une erreur d’authentification.
• L’agent s’identifie avec un en-tête Proxy-Authorization. Sur une même machine, lorsque les agents et la gateway partagent un réseau Docker interne, cet en-tête ne traverse jamais un réseau que vous ne contrôlez pas. Si vous configurez un agent situé sur une autre machine pour utiliser la gateway, le port du proxy doit utiliser son propre TLS, car cet en-tête est un bearer token.

Le compromis réel est le suivant : la gateway lit en clair, par conception, chaque requête envoyée par vos agents. Il s’agit du processus le plus sensible de la machine. Sécurisez son hôte en conséquence et limitez le nombre de personnes pouvant s’y connecter avec des utilisateurs Linux dotés du principe du moindre privilège.

Pourquoi le runner n’a besoin d’aucun port entrant

Le runner fonctionne uniquement en sortie. Sa documentation précise : « il n’expose aucun port accessible depuis l’extérieur. Un laptop, un homelab ou un VPC derrière NAT fonctionne donc sans ingress, sans tunnel et sans terminaison TLS. » NAT signifie network address translation, le mécanisme utilisé par un routeur domestique. Le runner ouvre une connexion vers le control plane et y récupère le travail. Il n’y a donc aucun port à rediriger ni à ouvrir.

Cette conception est utile sur le réseau de sandbox. Le fichier Compose définit un second réseau marqué internal: true. Dans Docker, cela signifie qu’aucune route ne permet de sortir de l’hôte. Les sandbox y sont connectées. La gateway est connectée aux deux réseaux. C’est donc le seul chemin vers l’extérieur. La documentation du runner l’explique clairement : « un réseau internal auquel la gateway est connectée sur deux réseaux transforme une sortie autorisée uniquement via la gateway en véritable frontière, et non en simple recommandation. » Un agent qui décide d’envoyer votre code source vers une adresse de son choix n’a aucune route pour le faire.

Vérifiez-le sur votre propre machine au lieu de vous fier au paragraphe précédent.

docker network ls
docker network inspect onecli-sandboxes | grep -i internal

Vous devez voir "Internal": true. Si la sortie indique false, le contrôle des sorties est désactivé et la gateway redevient une simple recommandation. Utilisez le nom du réseau de sandbox affiché par docker network ls, car onecli-sandboxes n’est que la valeur par défaut.

Quelle est la robustesse du sandbox OneCLI ?

Lisez cette section attentivement, car le terme « sandbox » joue un rôle important dans la description du projet, alors que son mécanisme n’est documenté qu’à un seul endroit.

Le README indique que chaque agent dispose de « son propre sandbox isolé, avec un système de fichiers et un shell », et présente le Sandbox Supervisor comme le composant qui « s’exécute dans chaque sandbox, en utilisant une interface de harness indépendante du fournisseur, afin que le runtime de l’agent puisse être remplacé ». Aucune de ces phrases ne précise la nature de l’isolation. La documentation du runner le précise : le backend par défaut est Docker (RUNNER_BACKEND=docker), et un sandbox est un conteneur Docker avec une limite de mémoire, une limite de CPU et une limite de processus, connecté au réseau interne. Le code prévoit un point d’extension pour d’autres backends, et la documentation cite notamment Kubernetes et les microVM comme modules que quelqu’un devrait développer. Aujourd’hui, sur votre machine, un sandbox est un conteneur.

Ce que la documentation ne dit pas est tout aussi important. Il n’existe aucun modèle de menace. Rien n’indique que le daemon Docker doit s’exécuter en rootless, qu’un remappage des user namespaces est utilisé, ni que des profils seccomp ou AppArmor sont appliqués au-delà des paramètres par défaut de Docker. Aucune frontière fournie par le kernel, comme gVisor ou une microVM, n’est revendiquée. Retenez donc l’interprétation la plus limitée. Les limites concernent les ressources. Le réseau interne constitue bien un contrôle des connexions sortantes. L’isolation entre un agent et votre hôte correspond à celle d’un conteneur Docker standard, et un conteneur partage le kernel de l’hôte.

Un deuxième fait doit être pris en compte. Le service runner monte /var/run/docker.sock, car c’est ainsi qu’il crée les sandboxes. L’accès au socket Docker équivaut à un accès root sur l’hôte : toute personne capable d’appeler cette API peut démarrer un conteneur avec le système de fichiers de l’hôte monté à l’intérieur. Tous les runners qui utilisent Docker fonctionnent de cette manière. Le runner est donc aussi sensible que la gateway.

Considérez cette frontière comme non démontrée tant que le projet upstream ne l’a pas documentée. En pratique, cela implique trois habitudes.

1. Exécutez OneCLI sur une machine qui ne fait rien d’autre. Aucun service de production sans rapport, aucune base de données partagée, aucune donnée d’une autre équipe.
2. Partez du principe qu’un agent qui obtient l’exécution de code arbitraire dans son sandbox pourrait atteindre l’hôte, et rendez cette situation récupérable grâce à des sauvegardes conservées hors de la machine.
3. Lisez apps/runner/src ou interrogez l’upstream avant d’affirmer à un collègue que l’agent est confiné.

Pour voir à quoi ressemble une frontière documentée, et quelles questions valent la peine d’être posées à l’upstream, comparez ce texte avec ce à quoi ressemble une véritable frontière de sandbox d’agent. La différence tient à l’existence d’une description écrite du mécanisme et de ce qu’il n’empêche pas.

La séparation des licences et les vérifications à effectuer avant de déployer

Le cœur de OneCLI est sous licence Apache-2.0, et son auto-hébergement en production est autorisé. Les répertoires nommés ee/ sont couverts par une licence OneCLI Enterprise distincte : leur utilisation est gratuite pour le développement, les tests et l’évaluation, mais un abonnement est requis en production. Les notes de version de v2.0.1, datées du 18 August 2026, mentionnent la restauration d’un fichier de licence Apache-2.0 détectable par GitHub. Le badge affiché sur la page du dépôt a donc changé récemment. Vérifiez le tag que vous allez réellement déployer plutôt qu’un résumé rédigé à une autre date.

cd onecli && find . -type d -name ee -not -path '*/node_modules/*'

Tout ce qui se trouve sous ces chemins appartient à la partie commerciale. Si une fonctionnalité dont vous prévoyez de dépendre s’y trouve, vérifiez son coût avant de bâtir un processus autour d’elle.

Mises à niveau, migrations et le seul fichier que vous ne pouvez pas perdre

Les mises à niveau consistent à changer de version et à redémarrer. Un service de migration ponctuel s’exécute avant l’API à chaque up. Si une migration échoue, la stack refuse de démarrer au lieu de servir des requêtes avec un schéma partiellement migré. C’est le comportement attendu : une mise à niveau échouée se manifeste alors par une indisponibilité plutôt que par une corruption silencieuse. docker compose logs migrations explique pourquoi.

cd onecli/docker
docker compose pull
docker compose up -d --wait
docker compose logs migrations

Si vous avez utilisé le script d’installation, exécutez-le de nouveau au lieu de faire un pull manuellement. Le fichier Compose reste ainsi synchronisé avec les images qu’il référence.

Sauvegardez deux éléments. PostgreSQL contient les agents, les conversations, la mémoire et les secrets chiffrés. Le fichier docker/.env contient SECRET_ENCRYPTION_KEY. Sans cette clé, les secrets chiffrés sont illisibles. Un dump de la base de données seul ne permet donc pas de restaurer un système utilisable.

cd onecli/docker
docker compose exec -T postgres pg_dump -U onecli onecli | gzip > ~/onecli-db.sql.gz
install -m 600 .env ~/onecli-env.backup

Conservez les deux copies hors de la machine. La procédure est la même que pour toute stack Compose avec état. Si vous sauvegardez et mettez à niveau une stack Docker Compose selon un calendrier, ajoutez ces deux chemins à cette procédure et n’y pensez plus.

Quand cela ne fonctionne pas

• La stack ne devient jamais saine et docker compose up -d --wait se termine avec un code différent de 0. Consultez d’abord docker compose logs migrations, car l’API attend volontairement que ce service soit disponible.
• Un agent reste inactif et aucun sandbox n’apparaît. Vérifiez que COMPOSE_PROFILES=runner figure dans docker/.env et que docker compose ps répertorie un runner. Vérifiez ensuite que l’agent dispose d’une model key accordée, car les sandbox ne démarrent pas sans celle-ci.
• Il ne reste plus de slot. RUNNER_MAX_SANDBOXES vaut 4 par défaut, et un sandbox qui exécute un processus en arrière-plan conserve son slot en permanence. docker ps indique ce qui est réellement actif.
• Les conteneurs disparaissent ou l’hôte devient très lent. La mémoire est épuisée. dmesg -T | grep -i oom enregistre les arrêts déclenchés par le manque de mémoire du kernel, et un seul sandbox peut utiliser 2048 MB à lui seul.
• Les appels HTTPS d’un agent échouent avec des erreurs de vérification de certificat, et non avec des erreurs d’authentification. Son client HTTP ne fait pas confiance à l’autorité de certification de la gateway.
• D’anciens conteneurs ou volumes restent présents après la suppression d’un agent. Le runner effectue une réconciliation toutes les 60 secondes et détruit les orphelins âgés de plus de RUNNER_ORPHAN_GRACE_SECONDS, dont la valeur par défaut est 3600. Attendez donc une heure avant de conclure à une fuite.

Est-ce la bonne solution pour vous ?

Le test d’adéquation est simple. OneCLI est pertinent lorsque plusieurs personnes ont chacune besoin d’un agent et que vous voulez centraliser les identifiants : un seul magasin à faire tourner, un seul journal d’audit à consulter et un seul tableau de bord où la révocation de l’accès d’une personne révoque effectivement cet accès. C’est un véritable problème opérationnel. Copier une clé d’API sur six ordinateurs portables est une réponse moins sûre.

Pour une seule personne, cette architecture apporte beaucoup de complexité sans réel avantage. Vous devriez exécuter PostgreSQL, un control plane, une gateway et un runner pour fournir un seul agent. Le problème d’identifiants que la gateway résout est alors presque inexistant, puisque vous êtes la seule personne à détenir la clé. Exécutez plutôt un seul harness sur une machine moins puissante : un harness d’agent unique sur un VPS remplit ce rôle avec une fraction de la mémoire. Si vous n’avez pas encore choisi de solution, l’étude comparatif des agents IA auto-hébergés constitue une première étape moins coûteuse.

FAQ

Quelles sont les exigences minimales du serveur pour auto-héberger OneCLI ?

Docker avec le plugin Compose en version 2.19 ou ultérieure, ainsi que suffisamment de mémoire. PostgreSQL est inclus dans le fichier Compose ; vous n’avez donc pas besoin de l’installer séparément. La mémoire détermine la configuration à choisir : le runner alloue par défaut 2048 MB par sandbox d’agent, sa documentation recommande environ 10 GiB libres en plus de la stack de base pour atteindre la limite par défaut de quatre sandboxes, et environ 2 GB sont utilisés par PostgreSQL et les quatre services persistants. Un serveur de 4 GB exécute un seul agent à la fois. Un serveur de 16 GB couvre confortablement la limite par défaut. Un VPS de 1 GB ou 2 GB ne peut pas démarrer d’agent hébergé.

OneCLI a-t-il besoin de PostgreSQL, ou peut-il utiliser SQLite ?

Il a besoin de PostgreSQL. DATABASE_URL est documenté comme une chaîne de connexion PostgreSQL, le fichier Compose fourni exécute postgres:18-alpine avec un volume pgdata, et un service de migrations distinct applique le schéma avant le démarrage de l’API. Aucune option SQLite n’est documentée. Si vous utilisez déjà PostgreSQL ailleurs, configurez DATABASE_URL pour pointer vers cette instance et conservez le service de migrations, car une migration échouée arrête la stack au lieu de la laisser servir un schéma partiellement appliqué.

La sandbox de l’agent OneCLI constitue-t-elle une véritable frontière de sécurité ?

Le mécanisme documenté repose sur un conteneur Docker avec des limites de mémoire, de CPU et de processus. Il est connecté à un réseau marqué internal: true, sans route externe à l’exception de la gateway. Le contrôle des connexions sortantes est réel et vous pouvez le vérifier avec docker network inspect. L’isolation vis-à-vis de l’hôte repose sur un conteneur, et le projet amont ne publie ni modèle de menace, ni garantie concernant le mode rootless ou les user namespaces, ni frontière au niveau du noyau telle que gVisor ou une microVM. Le runner monte également /var/run/docker.sock, ce qui équivaut à disposer des privilèges root sur l’hôte. Considérez la frontière entre l’agent et l’hôte comme non démontrée tant que le projet amont ne l’a pas explicitement établie. Exécutez OneCLI sur un serveur dédié et conservez les sauvegardes sur un autre serveur.

Dois-je ouvrir des ports entrants pour OneCLI ?

Non. Le runner fonctionne uniquement en sortie et n’expose aucun port accessible depuis l’extérieur. Il fonctionne donc derrière un NAT, sans tunnel. Le fichier Compose lie par défaut le dashboard, la gateway, l’API et PostgreSQL à 127.0.0.1. Accédez au dashboard via un tunnel SSH, ou placez un reverse proxy avec TLS devant le port 10254 si plusieurs personnes doivent y accéder. La gateway sur le port 10255 est destinée aux agents. Sur un serveur unique, ces agents y accèdent via le réseau Docker interne.

OneCLI peut-il être utilisé gratuitement au sein d’une entreprise ?

Le cœur du projet est sous licence Apache-2.0 et son utilisation en production sur votre propre infrastructure est autorisée sans licence commerciale. Les répertoires nommés ee/ sont couverts par la OneCLI Enterprise License. Cette licence est gratuite pour le développement, les tests et l’évaluation, mais un abonnement est nécessaire en production. La répartition change entre les releases. Les notes de la version v2.0.1 du 18 August 2026 mentionnent la restauration d’un fichier de licence Apache-2.0 détectable par GitHub. Vérifiez donc LICENSE et les répertoires ee/ dans le tag exact que vous déployez avant de construire un workflow dépendant d’une fonctionnalité particulière.