Auto-héberger LiveContext, l’alternative à n8n

Ce qu’est LiveContext et ce que coûte son exploitation

Pour auto-héberger LiveContext, vous avez besoin d’un VPS avec environ 8 GB de RAM. LiveContext CE est une plateforme d’automatisation open source qui exécute des agents IA au sein de l’automatisation elle-même. Elle est fournie sous la forme d’une stack Docker Compose composée de six conteneurs construits autour d’un backend Java. Le README du projet indique 4 GB minimum et 8 GB recommandés. Le fichier Compose montre comment cette mémoire est répartie.

Le projet se trouve sur livecontext-ai/livecontext-ce sur GitHub et est distribué sous licence AGPL-3.0. La release actuelle en août 2026 est v0.2.11, publiée le 3 août 2026. Chaque image est uniquement construite pour linux/amd64, ce qui exclut les VPS Arm peu coûteux. Ce guide utilise ce tag, place la stack derrière un reverse proxy et décrit la procédure de sauvegarde absente de la documentation du projet.

Dimensionnez le VPS avant d’auto-héberger LiveContext

Chaque service du fichier compose fourni comporte une limite mémoire explicite. Vous pouvez donc dimensionner la machine avant de la louer. Il s’agit des limites inscrites dans le fichier compose v0.2.11, et non de la mémoire réellement utilisée.

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 1536
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "label": "postgres",
    "memory_limit_mb": 256
  },
  {
    "label": "minio",
    "memory_limit_mb": 256
  },
  {
    "label": "websearch (optional)",
    "memory_limit_mb": 2048
  },
  {
    "label": "searxng (optional)",
    "memory_limit_mb": 512
  },
  {
    "label": "renderer (optional)",
    "memory_limit_mb": 1024
  }
]

Le backend est plafonné à 1536 Mo à lui seul. Cette limite s’applique à un processus Java 21. La JVM en utilisera donc la majeure partie et restera à ce niveau. Les cinq services de base totalisent un peu moins de 3 Go. Le frontend n’a aucune limite et utilise donc la mémoire demandée par Node. Sur un VPS de 4 Go, il ne reste presque rien pour le kernel et le cache de pages. C’est pourquoi 4 Go est indiqué comme un minimum, et non comme une recommandation.

Ce sont les profils optionnels qui font passer le besoin à 8 Go. Le profil de l’agent navigateur ajoute un conteneur Chromium plafonné à 2048 Mo, ainsi qu’une instance de recherche SearXNG. Le profil renderer ajoute 1024 Mo supplémentaires pour les captures d’écran et les PDF. Aucun de ces profils ne démarre tant que vous ne l’activez pas. Laissez-les donc désactivés jusqu’à ce que vous en ayez besoin. Le conteneur SearXNG sert de backend de recherche à l’agent. Les pages qu’il renvoie arrivent donc dans vos prompts sous forme de texte non fiable. C’est la limite de confiance au cœur de l’utilisation de la recherche web SearXNG par un agent IA, expliquée en détail.

Si vous utilisez déjà n8n, prévoyez de le remplacer plutôt que de l’ajouter. La stack présentée dans notre guide pour exécuter n8n sur un VPS avec Docker et HTTPS utilise un processus Node avec Postgres et fonctionne confortablement sur une petite machine. LiveContext réserve à lui seul davantage de mémoire pour son backend que toute cette stack. Deux plateformes d’automatisation tiennent sur un VPS de 8 Go, jusqu’au moment où elles exécutent toutes deux un job à la même minute. Si vous partagez la machine, définissez également des limites explicites pour tous les autres services, en suivant la méthode de notre article sur la définition de limites mémoire dans Docker Compose, afin qu’un workflow hors de contrôle ne fasse pas tomber toute la machine.

Installer LiveContext avec Docker Compose en épinglant un tag

Partez d’un VPS Ubuntu 24.04 vierge avec Docker Engine 24 ou une version plus récente et Compose v2. Si Docker n’est pas encore installé, suivez d’abord notre guide sur les bases de Docker Compose pour un VPS, puis revenez ici.

Le README propose npx livecontext pour démarrer en une ligne. Cela convient sur un ordinateur portable. Sur un serveur, placez le fichier Compose dans un répertoire que vous contrôlez. Une mise à niveau consiste alors à effectuer un checkout Git, et vous pouvez lire précisément les changements.

sudo apt update && sudo apt install -y git
git clone https://github.com/livecontext-ai/livecontext-ce.git
cd livecontext-ce
git tag --list 'v*' | tail -5
git checkout v0.2.11
cp docker/.env.ce.example docker/.env.ce
chmod 600 docker/.env.ce

Le fichier Compose épingle déjà chaque image sur son tag de release, par exemple ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Le checkout du tag Git correspondant garantit la cohérence entre le fichier Compose et les images, car le fichier Compose de v0.2.11 a été écrit pour ces images. Ne remplacez pas les tags par latest. Un tag latest peut changer sans avertissement. Le backend exécute les migrations de base de données à chaque démarrage. Un pull accidentel peut donc faire évoluer votre schéma à 3 heures du matin, sans possibilité de revenir en arrière autrement qu’avec une restauration.

Modifiez docker/.env.ce avant le premier démarrage. La section suivante indique les éléments à changer. Démarrez ensuite la stack.

docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce ps

Utilisez le même flag --env-file avec chaque commande Compose de ce guide. Compose relit ce fichier à chaque invocation. Une commande sans ce flag utilise les valeurs par défaut intégrées au fichier Compose et peut publier des ports différents de ceux que vous avez configurés.

Le healthcheck du backend a un start_period de 120s et interroge /actuator/health. Ainsi, docker compose ps indique que le service livecontext est health: starting pendant environ les deux premières minutes, le temps d’exécuter les migrations du schéma et l’enregistrement des outils. C’est normal. Vérifiez rapidement depuis le serveur :

curl -s localhost:8080/actuator/health

Cette commande doit afficher {"status":"UP"}. Dans ce cas, ouvrez l’interface web sur le port 3000. Le premier compte que vous créez devient le compte administrateur. Créez donc le vôtre avant que le port soit accessible à d’autres personnes. C’est la principale raison de ne pas publier le port 3000 sur Internet dès le premier jour.

Les valeurs d’environnement à modifier

Le fichier d’exemple contient des valeurs par défaut fonctionnelles afin que la stack démarre sur un ordinateur portable. Plusieurs de ces valeurs sont dangereuses sur un serveur public.

POSTGRES_PASSWORD=<random>
MINIO_ROOT_USER=<not minioadmin>
MINIO_ROOT_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_SALT=<random>
ANTHROPIC_API_KEY=sk-ant-...
FRONTEND_PORT=3000
BACKEND_PORT=8080
GATEWAY_PUBLIC_URL=https://lc-api.example.com

Générez chaque valeur aléatoire avec openssl rand -base64 32. Points importants :

• POSTGRES_PASSWORD et MINIO_ROOT_PASSWORD sont fournis avec les valeurs postgres et minioadmin. Aucun des deux ports de base de données n’est publié sur l’hôte. Ils ne sont donc pas directement exposés. En revanche, tout conteneur que vous ajouterez ensuite au même réseau pourra atteindre les deux ports avec la valeur par défaut indiquée dans la documentation.
• CREDENTIAL_ENCRYPTION_PASSWORD et CREDENTIAL_ENCRYPTION_SALT sont générés automatiquement lorsqu’ils sont laissés vides. Définissez-les vous-même. Les identifiants enregistrés par vos workflows sont chiffrés avec cette paire de valeurs. Si vous restaurez un dump de base de données sur une nouvelle machine sans le même mot de passe ni le même salt, les lignes contenant les identifiants seront illisibles. Définissez ces valeurs une seule fois, puis considérez docker/.env.ce comme faisant partie de la sauvegarde.
• FRONTEND_PORT et BACKEND_PORT sont substitués dans les mappings de ports sous la forme ${FRONTEND_PORT:-3000}:3000 et ${BACKEND_PORT:-8080}:8080. Le fichier env d’exemple définit explicitement les deux valeurs, qui ne sont pas toujours 3000 et 8080. Consultez votre propre fichier au lieu de partir du principe que ces valeurs sont utilisées.
• GATEWAY_PUBLIC_URL correspond à l’origine du backend visible par le navigateur. Cette valeur devient importante dès qu’un reverse proxy est utilisé. Consultez la section suivante.
• Les clés des modèles (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY et, éventuellement, MISTRAL_API_KEY ou DEEPSEEK_API_KEY) se trouvent ici en clair. Renseignez uniquement le fournisseur que vous utilisez réellement.

Rôle des six conteneurs

• postgres exécute pgvector/pgvector:pg16 dans le conteneur livecontext-db, qui contient la base de données nommée livecontext. L’extension pgvector sert à la recherche par embeddings ; une image postgres:16 standard ne convient donc pas.
• redis exécute redis:7-alpine avec appendonly yes et --maxmemory-policy noeviction. Cette policy est volontaire : Redis conserve ici l’état des files d’attente et des exécutions. Lorsqu’il atteint sa limite mémoire, il renvoie une erreur à l’émetteur au lieu de supprimer silencieusement des clés. Une erreur visible vaut mieux qu’un travail qui disparaît.
• minio est le stockage d’objets compatible S3 utilisé pour les fichiers qui circulent dans les workflows. Un conteneur minio-init à exécution unique lance mc mb myminio/workflow-files --ignore-existing au démarrage, crée le bucket, puis s’arrête. Voir minio-init comme exited (0) dans docker compose ps indique un état sain.
• bridge contient les adaptateurs CLI et les outils MCP (model context protocol). Il écoute sur le port 8093 dans le réseau Docker et n’est pas publié sur l’hôte.
• livecontext est le backend : un monolithe Java 21 sur le port 8080. Il exécute le moteur de workflow, les schedulers et les agents.
• frontend est l’interface web Next.js sur le port 3000. Seuls ces deux derniers conteneurs sont publiés sur l’hôte.

L’état est conservé dans cinq volumes nommés : livecontext_data pour Postgres, livecontext_redis, livecontext_minio, livecontext_keys et livecontext_logs. Compose les préfixe avec le nom du projet, qui correspond par défaut au nom du répertoire. Le volume réel sur le disque s’appelle donc quelque chose comme livecontext-ce_livecontext_minio. Exécutez docker volume ls et copiez les noms exacts avant d’écrire un script de sauvegarde qui les utilise.

docker compose down -v supprime les cinq volumes. C’est la méthode documentée pour repartir de zéro, mais aussi le moyen le plus rapide de perdre tous les workflows que vous avez créés. Tout se joue dans -v.

Placez-le derrière Traefik au lieu de publier le port 3000

Publier les ports 3000 et 8080 sur un VPS public expose l’application sans TLS (transport layer security) et sans contrôle devant l’inscription administrateur. Une règle ufw ne suffit pas à elle seule, car Docker insère ses propres règles iptables pour les ports publiés avant la chaîne gérée par ufw. Un port publié sur 0.0.0.0 reste donc accessible même lorsque ufw indique qu’il est refusé.

La solution propre consiste à ne publier aucun port et à laisser le proxy accéder aux conteneurs via un réseau Docker partagé. Créez docker-compose.override.yml à la racine du dépôt :

services:
  frontend:
    ports: !override []
    networks:
      - default
      - proxy
  livecontext:
    ports: !override []
    networks:
      - default
      - proxy

networks:
  proxy:
    external: true

Deux points déterminent le fonctionnement de cette configuration. !override remplace la liste des ports au lieu de la fusionner, ce qui nécessite Compose v2.24 ou une version plus récente. Vérifiez-le avec docker compose version, car avec une ancienne version de Compose, les deux listes sont fusionnées et les ports restent publiés. De plus, default doit rester présent dans chaque liste networks. Le fait de nommer un réseau remplace le réseau par défaut. Si vous l’omettez, le frontend ne peut plus communiquer avec Postgres et Redis. Vérifiez le résultat fusionné avant de démarrer quoi que ce soit :

docker compose --env-file docker/.env.ce config

Les routers, le certificate resolver et la redirection de HTTP vers HTTPS sont identiques à ceux des autres applications. Suivez donc notre guide sur le reverse proxy Traefik pour exécuter plusieurs applications sur un même VPS au lieu d’écrire ici une nouvelle configuration TLS. Faites pointer un premier nom d’hôte vers frontend sur le port 3000 et un second vers livecontext sur le port 8080.

Le second nom d’hôte est obligatoire. L’interface web appelle le backend depuis le navigateur. Le backend doit donc avoir sa propre origin, accessible par le navigateur. Définissez GATEWAY_PUBLIC_URL dans docker/.env.ce avec l’URL du backend, par exemple https://lc-api.example.com. Si vous l’omettez, la page se charge normalement, mais chaque action échoue. L’interface déduit l’origin du backend à partir de l’adresse que vous avez ouverte et appelle un port que votre proxy n’a jamais publié.

Comme la page d’inscription est ouverte à la première personne qui y accède, il est préférable d’ajouter une forward auth au router du frontend. Ainsi, personne ne voit cette page sans s’authentifier auprès du proxy. C’est ce qu’ajoute l’exécution d’Authentik comme couche SSO dédiée à la même configuration Traefik.

Où placer la clé du modèle et pourquoi une instance inactive coûte quand même de l’argent

Les agents s’exécutent dans l’automatisation, ce qui modifie les coûts par rapport à un simple outil de workflow. La clé du fournisseur se trouve dans docker/.env.ce, sous la forme de ANTHROPIC_API_KEY ou OPENAI_API_KEY. Le backend et le bridge la lisent au démarrage et elle s’applique à toute l’instance. Elle n’est pas limitée à un utilisateur. Toute personne qui possède un compte sur votre instance et peut créer un agent utilise cette clé pour générer des dépenses. La première personne qui s’inscrit devient administrateur.

Trois pratiques permettent de garder une facture prévisible. Créez une clé de fournisseur distincte pour ce VPS afin de pouvoir la révoquer sans modifier le reste. Définissez un plafond de dépenses strict dans la console du fournisseur, car cette limite est la seule qui soit située en dehors de la machine que vous sécurisez. Utilisez ensuite les budgets de crédits par agent et les métriques par agent fournies par LiveContext. Ainsi, une seule boucle ne peut pas épuiser la clé avant que vous le remarquiez.

Le coût d’une instance inactive n’est pas nul lorsqu’un agent est exécuté selon un schedule. Un déclencheur de schedule s’exécute même si personne ne surveille l’instance, et chaque exécution envoie des tokens. Un schedule de cinq minutes représente 288 exécutions par jour. Un agent qui lit une page et décide de ne rien faire consomme quand même des tokens pour lire cette page. Configurez vos premiers agents avec un webhook ou un déclencheur de chat. Surveillez les dépenses réelles pendant une semaine. Passez ensuite à un schedule lorsque vous connaissez le coût par exécution.

Sauvegarder Postgres et le stockage d’objets

Il y a deux magasins de données et un secret. La perte de l’un des trois entraîne la perte de votre instance. Sauvegardez la base de données et le bucket pendant la même fenêtre, avec le backend arrêté, afin qu’aucun fichier ne puisse être écrit après l’export de sa ligne en base de données.

cd ~/livecontext-ce
mkdir -p ~/backups
docker compose --env-file docker/.env.ce stop livecontext frontend
docker compose --env-file docker/.env.ce exec -T postgres \
  pg_dump -U postgres -d livecontext --clean --if-exists \
  | gzip > ~/backups/livecontext-db-$(date +%F).sql.gz

Utilisez la valeur définie pour DB_USERNAME à la place de postgres si vous l’avez modifiée. Copiez ensuite le volume du stockage d’objets en utilisant le nom préfixé affiché par docker volume ls :

docker run --rm \
  -v livecontext-ce_livecontext_minio:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-minio-$(date +%F).tgz -C /data .
docker compose --env-file docker/.env.ce start livecontext frontend
cp docker/.env.ce ~/backups/env.ce.$(date +%F)

Vérifiez que le dump n’est pas vide avant de lui faire confiance : gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 doit afficher CREATE TABLE et des instructions DROP TABLE, et non une erreur sur une seule ligne. Copiez ensuite les trois fichiers hors du serveur. Une sauvegarde qui se trouve uniquement sur la machine qu’elle protège n’est pas une sauvegarde.

Pour restaurer sur une nouvelle machine, installez le même tag, remettez docker/.env.ce à sa place afin que le mot de passe et le sel de chiffrement des identifiants correspondent, démarrez la stack une fois pour créer les volumes, arrêtez le backend, puis chargez le dump :

gunzip -c livecontext-db-2026-08-10.sql.gz \
  | docker compose --env-file docker/.env.ce exec -T postgres psql -U postgres -d livecontext

Mises à niveau et retour en arrière en cas de problème

Commencez toujours par créer un dump. Le backend applique ses migrations de schéma au démarrage, et ces migrations vont uniquement vers l’avant. Après une mise à niveau défaillante, revenir à un ancien tag laisse donc l’ancien code s’exécuter avec un schéma plus récent. Un rollback consiste à restaurer le dump. C’est pourquoi le dump vient en premier.

cd ~/livecontext-ce
git fetch --tags
git tag --list 'v*' | tail -5
TAG=v0.2.11
git checkout "$TAG"
docker compose --env-file docker/.env.ce pull
docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce logs -f livecontext

Définissez TAG sur le tag sélectionné dans la liste affichée par la troisième commande. Surveillez le log du backend jusqu’à ce que l’endpoint de health check réponde de nouveau. Votre docker-compose.override.yml n’est pas suivi par Git, donc un git checkout le laisse en place. Consultez toutefois le diff de docker-compose.yml entre les tags, car l’ajout d’un service ou le renommage d’un service peut rendre votre override obsolète sans afficher de message d’erreur.

Modes de panne, avec les chaînes que vous verrez

Un conteneur redémarre en boucle et docker compose ps affiche exited (137). Il s’agit du mécanisme du noyau qui tue les processus en cas de manque de mémoire. docker inspect livecontext-app le confirme avec "OOMKilled": true dans le bloc d’état. Le backend a atteint sa limite de 1536M, ou l’hôte a manqué de mémoire en premier. Vérifiez free -m avant d’augmenter une limite, car augmenter la limite d’un conteneur sur un hôte qui n’a plus de mémoire disponible déplace simplement l’arrêt forcé vers un autre conteneur.

Le pull échoue avec no matching manifest for linux/arm64/v8 in the manifest list entries. Les images sont publiées uniquement pour linux/amd64. Un VPS Arm ne peut pas exécuter cette stack à partir des images publiées, et l’émulation avec QEMU est beaucoup trop lente pour une JVM et Chromium. Passez à une offre x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. Un autre processus sur l’hôte utilise déjà ce port. Modifiez FRONTEND_PORT dans docker/.env.ce, ou appliquez la surcharge indiquée ci-dessus et ne publiez aucun port.

L’interface est accessible, mais la requête de connexion échoue après l’ajout du proxy. Le navigateur appelle le backend sur une origine que votre proxy ne sert pas. Ouvrez l’onglet réseau du navigateur et examinez l’hôte de la requête en échec. Définissez GATEWAY_PUBLIC_URL sur l’URL publique du backend, puis recréez le conteneur frontend, car cette valeur est lue au démarrage.

Tout fonctionne, mais les fichiers téléversés dans un workflow disparaissent. Vérifiez que minio-init affiche exited (0) plutôt qu’un code différent de zéro. Si le bucket workflow-files n’a jamais été créé, le backend n’a aucun emplacement où stocker les objets.

Choisissez LiveContext ou n8n

Choisissez LiveContext lorsque l’agent est au centre du système : vous voulez que le modèle construise et exécute l’automatisation, et vous acceptez une machine de 8 GB ainsi qu’un service Java comme contrepartie. Choisissez n8n si vous voulez des workflows déterministes, une vaste bibliothèque de nœuds et une empreinte qui permet de partager un VPS avec d’autres services. Les numéros de version présentés ici sont récents, v0.2.11 en août 2026. Épinglez donc votre tag et lisez les notes de version avant chaque mise à niveau. Pour avoir une vue d’ensemble, notamment des outils qui se situent entre ces deux options, consultez notre panorama des alternatives auto-hébergées à n8n plutôt que de lire une comparaison limitée à ces deux solutions.

FAQ

De quelle quantité de RAM LiveContext auto-hébergé a-t-il besoin ?

Prévoyez 8 GB. Le README upstream indique 4 GB comme minimum et 8 GB comme recommandation. Le fichier compose fourni suit cette recommandation : le backend seul est limité à 1536 MB, et les cinq services de base utilisent ensemble un peu moins de 3 GB, avant même de compter le conteneur frontend sans limite. L’activation du profil browser agent ajoute 2048 MB pour Chromium ainsi qu’un conteneur SearXNG. À partir de là, 8 GB ne sont plus facultatifs.

Puis-je exécuter LiveContext sur un VPS Arm ?

Non. Chaque image publiée est construite pour linux/amd64. Ainsi, docker compose up sur une offre Arm échoue lors du pull avec no matching manifest for linux/arm64/v8 in the manifest list entries. L’exécution avec l’émulation QEMU est théoriquement possible, mais inutilisable en pratique pour une charge JVM. Choisissez une offre x86.

Où dois-je placer la clé API de mon modèle ?

Dans docker/.env.ce, sous la forme ANTHROPIC_API_KEY, OPENAI_API_KEY ou GOOGLE_API_KEY, avant le premier démarrage. Le backend et le bridge la lisent au démarrage. Elle s’applique à toute l’instance, et non à un seul utilisateur. Conservez le fichier avec le mode 600. Utilisez une clé créée uniquement pour ce serveur afin de pouvoir la révoquer indépendamment. Définissez aussi un plafond de dépenses dans la console du fournisseur, car ce plafond est la seule limite gérée en dehors de la machine.

Comment sauvegarder LiveContext ?

Il faut sauvegarder trois éléments : un pg_dump de la base de données livecontext, une copie du volume MinIO et le fichier docker/.env.ce. Arrêtez les services livecontext et frontend pendant la sauvegarde des deux premiers éléments. La base de données et le stockage d’objets resteront ainsi cohérents. Le fichier env est également important, car les identifiants enregistrés dans vos workflows sont chiffrés avec CREDENTIAL_ENCRYPTION_PASSWORD et CREDENTIAL_ENCRYPTION_SALT. Une restauration sans ces valeurs laisse des lignes d’identifiants que rien sur le nouveau serveur ne peut lire.

Pourquoi le backend reste-t-il à health: starting pendant plusieurs minutes après le démarrage ?

Le healthcheck de compose définit start_period: 120s et interroge /actuator/health. Docker indique donc que le service est en cours de démarrage pendant l’exécution des migrations du schéma et l’enregistrement des outils. Deux à trois minutes au premier démarrage sont normales. Si le service ne passe jamais à l’état healthy, consultez docker compose logs -f livecontext. Une stack qui s’arrête à l’étape des migrations pointe généralement vers un volume de base de données provenant d’une release plus récente.