Comment auto-héberger Agentlas OS sur un VPS Linux

Qu'est-ce qu'Agentlas OS réellement

Agentlas OS est un runtime d'agents open source qui conserve les agents spécialisés sous forme de paquets sur le disque et assemble un orchestrateur temporaire pour chaque tâche. Vous l'auto-hébergez en l'installant dans votre propre compte utilisateur sur un VPS Linux. Ce n'est pas un service. Il n'y a aucun daemon, aucun port en écoute, aucune interface web et aucune image de conteneur dans le dépôt.

Cette dernière phrase détermine tout le reste sur cette page. La plupart des systèmes multi-agents exécutent un processus superviseur qui reste actif et maintient les agents. Agentlas inverse ce fonctionnement : les spécialistes sont des fichiers au repos, et l'orchestrateur n'existe que pendant l'exécution d'une tâche. Le résultat pratique est qu'un hub inactif consomme du disque, pas de la mémoire vive.

Le projet nomme son noyau open source Hephaestus, et c'est ce nom que vous verrez dans les commandes, les chemins et les variables d'environnement. Le dépôt est agentlas-ai/Agentlas-OS, sous licence Apache-2.0, et écrit principalement en Python.

À quel point ce projet est-il récent, honnêtement

Le dépôt a été créé le 4 juin 2026. Au 12 août 2026, il a environ dix semaines d'existence, avec approximativement 1 150 stars et 112 forks. C'est jeune pour un outil que vous destinez à de la production.

La cadence des releases compte davantage que l'âge. La version v1.1.103 a été publiée le 8 août 2026, et la v1.2.0 est arrivée le 12 août 2026. Cela représente plus d'une centaine de releases taguées dans la série 1.1, parfois plusieurs par jour, publiées par automatisation. Un projet qui évolue à cette vitesse peut changer de comportement entre un mardi et un jeudi.

Par conséquent, fixez la version (pin). L'installeur lit une variable d'environnement à cet effet, et tout le guide ci-dessous l'utilise. Une installation sans version fixée d'un projet qui publie plusieurs fois par jour vous expose à récupérer ce qui se trouvait sur main à cette heure précise.

Ce dont vous avez besoin sur le VPS

Les prérequis sont faibles car aucun processus ne tourne en arrière-plan.

• Un VPS Linux. Ubuntu 24.04 constitue une excellente base. L'installateur détecte le système d'exploitation avec uname -s et sélectionne une branche non-macOS pour Linux ; les serveurs sans interface graphique (headless) sont donc pris en charge.
• curl, tar et git sur la machine, ainsi qu'un interpréteur Python fonctionnel.
• Un accès HTTPS sortant vers raw.githubusercontent.com et github.com. L'installateur télécharge une archive de release et vérifie son SHA-256 ; une machine sans accès sortant ne peut donc pas effectuer l'installation.
• Un agent hôte, c'est-à-dire l'agent de développement qui communique réellement avec un modèle. Claude Code, Codex, opencode, goose et Hermes sont tous des adaptateurs pris en charge.

Vous n'avez pas besoin des privilèges root. L'installateur écrit uniquement dans votre répertoire personnel et dans ~/.local/bin, et il affiche un avertissement plutôt que d'interrompre le processus lorsqu'un chemin n'est pas accessible en écriture. Si vous êtes encore en train de choisir la machine, exécuter un agent de développement sur un VPS couvre la configuration de l'image de base et des accès sur lesquels repose cette installation.

Installer la version épinglée

Le README amont documente une ligne unique qui redirige un script depuis main directement vers bash. Téléchargez-le et lisez-le d'abord. Il écrit dans votre configuration de shell et dans chaque harness d'agent qu'il détecte, cela mérite donc dix secondes de votre attention.

curl -fsSL -o install-all-runtimes.sh \
  https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh
less install-all-runtimes.sh
HEPHAESTUS_REF=v1.2.0 bash install-all-runtimes.sh

HEPHAESTUS_REF est l'épingle. Dans le script, la ligne est version="${HEPHAESTUS_REF:-v1.2.0}" ; ne pas la définir vous donne donc la v1.2.0 aujourd'hui et autre chose la semaine prochaine. Définissez-la explicitement et votre reconstruction en octobre installera ce que vous avez testé en août.

Une limite honnête : l'URL du script ci-dessus suit main, tandis que HEPHAESTUS_REF épingle la charge utile (payload) d'exécution que le script télécharge. Ce sont deux choses différentes. Pour épingler les deux, récupérez le script depuis le tag au lieu de main en remplaçant main par v1.2.0 dans cette URL.

Une exécution réussie affiche les chemins dans lesquels il a écrit, y compris ces deux lignes :

Installed runner: /home/you/.agentlas/runtime/current/bin/hephaestus
Installed shell commands in /home/you/.local/bin (add ~/.local/bin to PATH to use them)

Cette seconde ligne est celle que les gens oublient. Sur une machine Ubuntu fraîche, ~/.local/bin est souvent absent de PATH, donc chaque commande hep-* échoue avec command not found alors même que l'installation a réussi. Corrigez cela et confirmez :

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
hep-global status

hep-global status rapporte ce que le routeur global a installé et quels harnesses il a détectés. S'il s'exécute, votre PATH est correct.

Emplacement de l'état

Tout est fichier dans votre répertoire personnel, ce qui simplifie les sauvegardes et la migration.

• ~/.agentlas/runtime/v1.2.0/ contient le runtime lui-même, avec ~/.agentlas/runtime/current/ comme lien symbolique vers la version active. Deux versions épinglées peuvent coexister.
• ~/.local/bin/ contient les wrappers shell : hephaestus, hep-build, hep-network, hep-search, hep-storm, hep-cloud et hep-upload.
• ~/.agentlas/networking/memory/ contient la mémoire durable : playbook-registry.json, playbook-candidates.jsonl et memory-events.jsonl.
• ~/.agentlas/networking/hub-agents/<slug>/memory/experience.sqlite contient l'expérience par agent, délimitée par propriétaire.
• <project>/.agentlas/ontology-runtime.sqlite contient l'état par projet, afin qu'il accompagne le dépôt plutôt que la machine.
• ~/.cache/agentlas/python contient le cache Python sous Linux. macOS utilise un chemin différent, qui est la branche choisie par l'installateur avec uname.

La documentation sur la mémoire précise que les secrets, les identifiants bruts et les transcriptions complètes ne doivent figurer dans aucun périmètre de mémoire. Les valeurs des identifiants restent dans des fichiers locaux ignorés par git, et la mémoire n'enregistre que les noms et les chemins. Sauvegardez ~/.agentlas et vos répertoires de projet .agentlas pour pouvoir reconstruire l'environnement sur un nouveau VPS.

Quels modèles de backends peuvent être ciblés

Voici le détail qui redéfinit toute l'installation : Agentlas n'appelle pas directement l'API d'un modèle. C'est le harness hôte qui s'en charge.

Le document d'architecture décrit des adaptateurs d'exécution qui traduisent un noyau vers chaque harness, et précise que le runtime hôte détient les identifiants du modèle. Agentlas fournit deux interfaces exploitables par un harness : un fichier AgentSkills et un serveur MCP (Model Context Protocol) communiquant via stdio. La question « quels modèles Agentlas supporte-t-il » revient donc à demander « quels modèles votre harness supporte-t-il ». La réponse est : tout ce que Claude Code, Codex, opencode, goose ou Hermes peuvent atteindre.

L'enregistrement du serveur MCP s'effectue comme suit dans une configuration TOML de type Codex :

[mcp_servers.hephaestus-network]
command = "~/.agentlas/runtime/current/bin/hephaestus"
args = ["mcp", "serve"]

Le même serveur est automatiquement enregistré dans ~/.cursor/mcp.json, ~/.config/goose/config.yaml et les autres configurations de harness lors de l'installation. Si vous en configurez plusieurs sur une même machine, l'exécution de serveurs MCP sur un VPS détaille plus précisément le fonctionnement de stdio et du modèle de processus.

Pointer vers un endpoint Ollama auto-hébergé

Comme le harness gère la connexion au modèle, pointer Agentlas vers des modèles locaux revient à pointer votre harness vers Ollama. Ollama a ajouté une sous-commande launch dans la version 0.15 pour répondre exactement à ce besoin, et elle est toujours présente dans la version 0.32.9 au 11 août 2026. Elle configure un harness existant pour utiliser des modèles locaux sans aucune variable d'environnement à définir :

ollama pull qwen3-coder:30b
ollama launch opencode

Remplacez claude, codex ou droid par opencode selon le harness que vous avez installé. Ensuite, acheminez une requête via le runtime local :

~/.agentlas/runtime/current/bin/hephaestus route "summarise the failing tests" --runtime ollama

Un routage réussi renvoie une décision au format JSON nommant l'agent ou l'équipe sélectionné, avec un receipt_id. Si le résultat n'est pas exploitable, la cause habituelle est la longueur du contexte. La documentation d'Agentlas préconise un modèle avec au moins 64k de contexte pour les sessions à routage intensif et cite qwen3-coder, gemma3 et deepseek-r1 comme exemples. Les recommandations d'Ollama pour les outils de développement imposent le même seuil de 64k. Les décisions de routage incluent l'inventaire des agents dans le prompt ; un modèle avec 8k ou 32k de contexte tronque donc l'inventaire et effectue de mauvais choix.

Une mise en garde que le slogan ne vous dira pas. Ollama, Gemma et DeepSeek ne possèdent pas de système de plugins ou de commandes propre, les commandes slash /agentlas n'y existent donc pas. Sur une configuration avec modèle local, vous pilotez le système via le serveur MCP et la commande hephaestus route à la place. C'est une réduction réelle de la surface d'exposition, et c'est le compromis honnête à accepter pour conserver les poids sur votre propre machine.

Le coût en RAM d'un hub de spécialistes inactifs

Rien. C'est la réponse complète, et vous pouvez le vérifier plutôt que de nous croire sur parole.

Les spécialistes de hub empruntés arrivent sous forme d'artefacts de paquets, et non de processus. Un spécialiste est un agent.md ainsi qu'un répertoire .agentlas/ de fichiers JSON : routing-card.json pour les déclencheurs et les capacités, memory-map.json pour les limites d'écriture, mode-map.json pour définir s'il s'exécute seul ou en équipe. Le Hephaestus Network est décrit comme un ordonnanceur in-process sans service d'arrière-plan. Entre deux tâches, vérifiez par vous-même :

pgrep -af hephaestus
systemctl --user list-units --type=service | grep -i agentlas
du -sh ~/.agentlas

Les deux premières commandes n'affichent rien sur une machine inactive, car rien n'est résident en mémoire. La troisième affiche le seul coût qu'un hub en attente vous impose, à savoir l'espace disque, qui augmente avec le nombre de spécialistes conservés ainsi que le modèle d'embedding fourni avec le runtime.

La question de la mémoire concerne donc uniquement le pic d'activité, et ce pic dépend de votre harness et de votre backend de modèle. Si le harness communique avec une API hébergée, le coût résident est un processus de quelques centaines de mégaoctets. Si vous auto-hébergez les poids, ce sont eux qui constituent la facture :

[
  {
    "label": "Hosted API model",
    "weights_gb": 0
  },
  {
    "label": "gemma3:4b",
    "weights_gb": 3.3
  },
  {
    "label": "gemma3:12b",
    "weights_gb": 8.1
  },
  {
    "label": "gemma3:27b",
    "weights_gb": 17
  },
  {
    "label": "qwen3-coder:30b",
    "weights_gb": 19
  }
]

Il s'agit des tailles de téléchargement publiées par la bibliothèque de modèles d'Ollama, et non de mesures issues d'un benchmark. Le cache KV pour un contexte de 64k s'ajoute à chaque chiffre supérieur à zéro. Le modèle cité en premier dans la documentation d'Agentlas, qwen3-coder:30b, nécessite 19 Go de poids avant le contexte, et même la variante 27B de Gemma demande 17 Go. Face à ces chiffres, la couche Agentlas elle-même n'apparaît pas dans le budget.

Comparaison avec l'exécution d'un seul harness

Exécutez un seul harness contre une API hébergée et votre VPS ne supporte qu'un seul processus. Ajoutez Agentlas et il supporte ce même processus, en plus des fichiers. L'orchestrateur n'est pas un programme supplémentaire à exécution longue ; il s'agit d'un prompt plus large assemblé à partir des paquets sur le disque, puis supprimé.

Le coût qui varie est le contexte, pas la mémoire. Un orchestrateur qui récupère plusieurs cartes spécialisées et leurs métadonnées de routage consomme plus de tokens par tâche qu'un harness nu. Sur une API hébergée, cela représente de l'argent plutôt que de la RAM. Avec des poids locaux, cela représente du temps, car un prompt plus long signifie un prefill plus long sur le CPU ou une charge plus importante sur le GPU.

C'est pourquoi les conseils de dimensionnement pour une machine de ce type dépendent du choix du modèle et non du framework d'agent. Dimensionnement de la RAM et du CPU pour un VPS d'agent de codage détaille ce point, et la conclusion reste valable ici : choisissez l'offre correspondant au backend que vous comptez exécuter, puis ajoutez quelques gigaoctets de marge pour le harness. Si vous préférez comparer avec une conception de superviseur permanent, le harness multi-agent Omnigent maintient son coordinateur en mémoire, ce qui constitue le compromis inverse et se répercute directement sur la mémoire au repos.

Modes de défaillance et messages d'erreur associés

hep-build: command not found juste après une installation propre. L'installateur a écrit dans ~/.local/bin, qui ne se trouve pas sur PATH dans une image Ubuntu par défaut. Cela était indiqué sur la dernière ligne, mais le texte a défilé trop vite. Ajoutez l'export indiqué ci-dessus.

Changements de comportement après une reconstruction de la machine. Vous n'avez pas défini HEPHAESTUS_REF, donc l'installateur a utilisé par défaut le tag en vigueur ce jour-là. Fixez la version (pin) et notez-la à côté de vos autres numéros de version.

Le routage sélectionne le mauvais spécialiste sur un modèle local. La fenêtre de contexte du modèle est trop petite pour l'inventaire des agents. Passez à un modèle avec 64k ou plus et configurez la longueur de contexte d'Ollama en conséquence, car la valeur par défaut est inférieure aux besoins des outils de développement.

ollama launch n'est pas reconnu. Cette sous-commande a été introduite dans Ollama v0.15. Les paquets plus anciens provenant des dépôts de distribution sont antérieurs à cette version ; installez donc une version actuelle d'Ollama.

L'installation écrit dans des répertoires que vous n'aviez pas prévus. Le script détecte et configure chaque harnais qu'il trouve, en écrivant dans ~/.claude/, ~/.codex/, ~/.gemini/, ~/.cursor/ et d'autres encore. Sur une machine de build partagée, lisez le script avant de l'exécuter et identifiez les répertoires qui vous concernent.

Est-il déjà temps de l'utiliser

Un projet vieux de dix semaines qui publie des releases automatisées plusieurs fois par jour n'est pas adapté à une charge de travail en production. L'architecture est réellement intéressante, la licence est Apache-2.0 et la conception basée sur des fichiers permet une désinstallation simple : il suffit de supprimer deux répertoires. Ces éléments rendent l'essai peu coûteux, mais la dépendance risquée.

Une position raisonnable pour le moment : fixez la version v1.2.0, exécutez-la sur une machine que vous pouvez reconstruire, incluez ~/.agentlas dans vos sauvegardes et relisez le changelog avant de modifier la version fixée. Pour un panorama plus large des alternatives disponibles et de leur maturité, le comparatif des agents IA auto-hébergés constitue un meilleur point de départ, et l'auto-hébergement d'un agent Hermes sur un VPS couvre l'un des environnements qu'Agentlas adapte.

FAQ

Agentlas OS s'exécute-t-il en tant que serveur sur mon VPS ?

Non. Il n'y a aucun daemon, aucun port en écoute et aucune image de conteneur dans le dépôt. L'installateur écrit un runtime sous ~/.agentlas/runtime/ et des wrappers de commande dans ~/.local/bin, et le Hephaestus Network est un ordonnanceur intégré au processus plutôt qu'un service d'arrière-plan. Vous pouvez le confirmer sur une machine inactive : pgrep -af hephaestus n'affiche rien, et il n'y a aucune unité systemd à activer. L'auto-hébergement signifie ici que le code et l'état sont sur votre machine, et non qu'un service est en écoute.

Quelle quantité de RAM un hub de spécialistes inactifs consomme-t-il ?

Aucune, car les spécialistes inactifs ne sont pas des processus. Un spécialiste est un fichier agent.md plus un répertoire .agentlas/ contenant des routing-card.json, memory-map.json et des métadonnées similaires ; un hub en attente ne consomme donc que de l'espace disque. Mesurez-le avec du -sh ~/.agentlas. La mémoire n'est consommée que pendant l'exécution d'une tâche, et ce qui la consomme est votre processus hôte (harness) et votre backend de modèle, pas la couche Agentlas.

Quels modèles puis-je utiliser, et puis-je le pointer vers mon propre Ollama ?

Agentlas n'appelle pas lui-même les API de modèles. Le harness hôte gère les identifiants et la connexion ; les modèles supportés sont donc ceux que votre harness supporte. Pour des poids locaux, exécutez ollama launch opencode (en remplaçant par claude, codex ou droid), ce qui configure le harness avec votre serveur Ollama sans variables d'environnement. Utilisez un modèle avec au moins 64k de contexte, comme qwen3-coder ou gemma3, car les prompts de routage contiennent l'inventaire des agents et sont tronqués de manière problématique sur des fenêtres plus petites.

Quelle version dois-je installer, et pourquoi le verrouillage de version (pinning) est-il important ici ?

Installez la v1.2.0, la version taguée actuelle au 12 août 2026, en définissant HEPHAESTUS_REF=v1.2.0 avant d'exécuter l'installateur. La valeur par défaut du script est version="${HEPHAESTUS_REF:-v1.2.0}", qui suit chaque nouveau tag des mainteneurs. Le verrouillage est plus important que d'habitude car le projet a publié plus d'une centaine de versions dans sa série 1.1, parfois plusieurs par jour ; une reconstruction sans version verrouillée quelques semaines plus tard ne vous donnera pas le système que vous avez testé.