Alojar LiveContext: alternativa a n8n con Docker

Qué es LiveContext y cuánto cuesta ejecutarlo

Para alojar LiveContext usted mismo necesita un VPS con unos 8 GB de RAM. LiveContext CE es una plataforma de automatización de código abierto que ejecuta agentes de IA dentro de la propia automatización. Se distribuye como una pila de Docker Compose con seis contenedores basados en un backend Java. El README del proyecto indica 4 GB como mínimo y 8 GB como configuración recomendada. El archivo de Compose muestra cómo se utiliza esa memoria.

El proyecto está en livecontext-ai/livecontext-ce en GitHub y usa la licencia AGPL-3.0. La versión actual en agosto de 2026 es v0.2.11, publicada el 3 de agosto de 2026. Todas las imágenes se crean únicamente para linux/amd64, por lo que no se pueden usar los planes económicos basados en Arm. Esta guía fija esa etiqueta, coloca la pila detrás de un reverse proxy y explica el procedimiento de copia de seguridad que no incluyen los documentos del proyecto.

Dimensiona el VPS antes de alojar LiveContext

Cada servicio del archivo compose incluido tiene un límite de memoria explícito, por lo que puedes dimensionar el servidor antes de alquilarlo. Estos son los límites escritos en el archivo compose de v0.2.11, no el uso medido.

[
  {
    "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
  }
]

El backend por sí solo tiene un límite de 1536 MB. Ese límite se aplica a un proceso Java 21, por lo que la JVM utilizará la mayor parte y permanecerá en ese nivel. Los cinco servicios base suman algo menos de 3 GB, y el frontend no tiene ningún límite, así que consume la memoria que solicite Node. En un VPS de 4 GB queda muy poca memoria para el kernel y la caché de páginas. Por eso 4 GB figura como mínimo y no como recomendación.

Los perfiles opcionales son los que elevan el requisito del servidor a 8 GB. El perfil del agente de navegador añade un contenedor Chromium con un límite de 2048 MB junto a una instancia de búsqueda SearXNG, y el perfil de renderizado añade otros 1024 MB para capturas de pantalla y archivos PDF. Ninguno se inicia si no habilitas su perfil, así que mantén ambos desactivados hasta que los necesites. Ese contenedor SearXNG existe para proporcionar la búsqueda al agente, por lo que las páginas que devuelve llegan a tus prompts como texto no confiable. Ese es el límite de confianza por el que funciona en detalle proporcionar búsqueda web de SearXNG a un agente de IA.

Si ya ejecutas n8n, planifica sustituirlo en lugar de añadir LiveContext al mismo servidor. La pila descrita en nuestra guía para ejecutar n8n en un VPS con Docker y HTTPS consta de un proceso Node junto a Postgres y funciona bien en un servidor pequeño. LiveContext reserva más memoria sólo para su backend que la que utiliza toda esa pila. Dos plataformas de automatización caben en un VPS de 8 GB hasta el momento en que ambas ejecutan un trabajo durante el mismo minuto. Si compartes el servidor, establece también límites explícitos para todo lo demás mediante el método de nuestra publicación sobre cómo establecer límites de memoria en Docker Compose, para que un flujo de trabajo descontrolado no bloquee todo el equipo.

Instalar LiveContext con Docker Compose, fijado a una etiqueta

Parta de un VPS Ubuntu 24.04 limpio con Docker Engine 24 o posterior y Compose v2. Si Docker todavía no está instalado, siga primero nuestra guía básica de Docker Compose para un VPS y vuelva después.

El README ofrece npx livecontext como comando de inicio de una sola línea. Esto está bien en un portátil. En un servidor, conviene guardar el archivo de Compose en un directorio que controle, porque así una actualización consiste en hacer un checkout de git y puede revisar exactamente qué ha cambiado.

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

El archivo de Compose ya fija cada imagen a su etiqueta de versión, por ejemplo ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Hacer checkout de la etiqueta de git correspondiente mantiene sincronizados el archivo de Compose y las imágenes, porque el archivo de Compose de v0.2.11 se creó para esas imágenes. No cambie las etiquetas a latest. Una etiqueta latest puede cambiar sin aviso, y el backend ejecuta las migraciones de la base de datos en cada inicio. Por tanto, una descarga accidental puede adelantar el esquema a las 3 de la madrugada sin otra forma de volver atrás que restaurar una copia.

Edite docker/.env.ce antes del primer inicio (la siguiente sección indica qué debe cambiar) y, después, inicie la pila.

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

Use el mismo indicador --env-file en todos los comandos de Compose de esta guía. Compose lee de nuevo ese archivo en cada ejecución, por lo que un comando sin el indicador utiliza los valores predeterminados incluidos en el archivo de Compose y puede publicar puertos distintos de los que configuró.

La comprobación de estado del backend tiene un start_period de 120s y consulta /actuator/health, por lo que docker compose ps muestra el servicio livecontext como health: starting durante aproximadamente los dos primeros minutos, mientras se ejecutan las migraciones del esquema y el registro de la herramienta. Esto es normal. Una comprobación rápida desde el servidor:

curl -s localhost:8080/actuator/health

Debe mostrar {"status":"UP"}. Cuando lo haga, abra la interfaz web en el puerto 3000. La primera cuenta que cree se convierte en la cuenta de administrador, así que cree la suya antes de que cualquier otra persona pueda acceder al puerto. Esta es la razón más importante para no publicar el puerto 3000 en Internet desde el primer día.

Los valores de entorno que debe cambiar

El archivo de ejemplo incluye valores predeterminados funcionales para que la pila se inicie en un portátil. Varios de ellos no son seguros en un servidor público.

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

Genere cada valor aleatorio con openssl rand -base64 32. Estos son los aspectos que pueden causar problemas:

• POSTGRES_PASSWORD y MINIO_ROOT_PASSWORD se incluyen como postgres y minioadmin. Ninguno de los dos puertos de base de datos se publica en el host, por lo que no están expuestos directamente. Sin embargo, cualquier contenedor que conecte después a la misma red puede acceder a ambos mediante el valor predeterminado documentado.
• CREDENTIAL_ENCRYPTION_PASSWORD y CREDENTIAL_ENCRYPTION_SALT se generan automáticamente cuando se dejan vacíos. Defínalos manualmente. Las credenciales que almacenan sus flujos de trabajo se cifran con ese par. Por tanto, un volcado de la base de datos restaurado en otro equipo sin la misma contraseña y salt no proporciona credenciales que se puedan leer. Defínalos una sola vez y trate después docker/.env.ce como parte de la copia de seguridad.
• FRONTEND_PORT y BACKEND_PORT se sustituyen en las asignaciones de puertos como ${FRONTEND_PORT:-3000}:3000 y ${BACKEND_PORT:-8080}:8080. El archivo de entorno de ejemplo define ambos explícitamente, y los valores incluidos no siempre son 3000 y 8080. Consulte su propia copia en lugar de dar por hecho esos valores.
• GATEWAY_PUBLIC_URL es el origen al que accede el navegador para el backend. Es importante en cuanto interviene un reverse proxy. Consulte la sección siguiente.
• Las claves de los modelos (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY y, opcionalmente, MISTRAL_API_KEY o DEEPSEEK_API_KEY) se almacenan aquí en texto plano. Rellene sólo el proveedor que utilice realmente.

Qué hacen los seis contenedores

• postgres ejecuta pgvector/pgvector:pg16 como el contenedor livecontext-db y contiene la base de datos llamada livecontext. La extensión pgvector se utiliza para las búsquedas de embeddings, por lo que una imagen postgres:16 sin modificaciones no sirve.
• redis ejecuta redis:7-alpine con appendonly yes y --maxmemory-policy noeviction. Esta política es intencionada: Redis almacena aquí el estado de las colas y de las ejecuciones. Cuando alcanza su límite de memoria, devuelve un error al proceso que escribe en lugar de descartar claves en silencio. Un error visible es preferible a un trabajo que desaparece.
• minio es el almacén de objetos compatible con S3 para los archivos que pasan por los flujos de trabajo. Un contenedor minio-init de ejecución única ejecuta mc mb myminio/workflow-files --ignore-existing al arrancar, crea el bucket y termina. Ver minio-init como exited (0) en docker compose ps indica que el estado es correcto.
• bridge contiene los adaptadores de CLI y las herramientas MCP (protocolo de contexto del modelo). Escucha en el puerto 8093 dentro de la red de Docker y no se publica en el host.
• livecontext es el backend: un monolito Java 21 en el puerto 8080. Ejecuta el motor de flujos de trabajo, los programadores y los agentes.
• frontend es la interfaz web de Next.js en el puerto 3000. Sólo estos dos últimos contenedores se publican en el host.

El estado se almacena en cinco volúmenes con nombre: livecontext_data para Postgres, livecontext_redis, livecontext_minio, livecontext_keys y livecontext_logs. Compose les antepone el nombre del proyecto, que de forma predeterminada es el nombre del directorio. Por tanto, el volumen real del disco se llama algo como livecontext-ce_livecontext_minio. Ejecute docker volume ls y copie los nombres exactos antes de escribir cualquier script de copia de seguridad que los utilice.

docker compose down -v elimina los cinco volúmenes. Es la forma documentada de empezar de nuevo, pero también es la forma más rápida de perder todos los flujos de trabajo que haya creado. -v es la diferencia completa.

Colóquelo detrás de Traefik en lugar de publicar el puerto 3000

Publicar los puertos 3000 y 8080 en un VPS público expone la aplicación sin TLS (seguridad de la capa de transporte) y sin un control de acceso delante del registro de administradores. Una regla de ufw no basta por sí sola, porque Docker inserta sus propias reglas de iptables para los puertos publicados antes de la cadena que administra ufw. Por tanto, un puerto publicado en 0.0.0.0 sigue siendo accesible aunque ufw indique que está denegado.

La solución adecuada es no publicar ningún puerto y permitir que el proxy acceda a los contenedores mediante una red Docker compartida. Cree docker-compose.override.yml en la raíz del repositorio:

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

networks:
  proxy:
    external: true

Dos detalles determinan si esto funciona. !override reemplaza la lista de puertos en lugar de combinarla con ella. Esto requiere Compose v2.24 o posterior. Compruébelo con docker compose version, porque en una versión anterior de Compose las dos listas se combinan y los puertos siguen publicados. Además, default debe permanecer en cada lista networks. Al asignar cualquier red, se reemplaza la red predeterminada, por lo que omitirla desconecta el frontend de Postgres y Redis. Confirme el resultado combinado antes de iniciar nada:

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

Los routers, el resolvedor de certificados y la redirección de HTTP a HTTPS son los mismos que para cualquier otra aplicación. Por tanto, siga nuestra guía de proxy inverso Traefik para ejecutar varias aplicaciones en un VPS en lugar de escribir aquí una configuración TLS nueva. Encamine un nombre de host a frontend en el puerto 3000 y otro a livecontext en el puerto 8080.

El segundo nombre de host no es opcional. La interfaz web llama al backend desde el navegador, por lo que el backend necesita su propio origen accesible desde el navegador. Configure GATEWAY_PUBLIC_URL en docker/.env.ce con la URL del backend, por ejemplo https://lc-api.example.com. Si lo omite, la página se carga con normalidad, pero todas las acciones fallan, porque la interfaz obtiene el origen del backend a partir de la dirección que abrió y llama a un puerto que el proxy nunca publicó.

Como la página de registro está abierta para cualquiera que acceda a ella primero, conviene configurar la autenticación previa en el router del frontend. Así, nadie verá esa página sin autenticarse en el proxy. Eso es lo que añade ejecutar Authentik como su propia capa SSO sobre la misma configuración de Traefik.

Dónde se configura la clave del modelo y por qué una instancia inactiva sigue costando dinero

Los agentes se ejecutan dentro de la automatización, lo que cambia los costes respecto a una herramienta de flujos de trabajo sencilla. La clave del proveedor se almacena en docker/.env.ce como ANTHROPIC_API_KEY o OPENAI_API_KEY, el backend y el puente la leen al iniciar y se aplica a toda la instancia. No se limita por usuario. Cualquier persona que tenga una cuenta en la instancia y pueda crear un agente utiliza esa clave, y la primera persona que se registra obtiene permisos de administrador.

Tres prácticas ayudan a mantener los costes bajo control. Cree una clave de proveedor independiente para este VPS, de modo que pueda revocarla sin afectar a nada más. Establezca un límite de gasto estricto en la consola del proveedor, porque ese límite es el único que está fuera de la máquina que está protegiendo. Después, use los presupuestos de crédito por agente y las métricas por agente que expone LiveContext, para que un solo bucle no agote la clave antes de que lo detecte.

El coste en reposo no es cero cuando un agente tiene una tarea programada. Un activador programado se ejecuta tanto si alguien lo supervisa como si no, y cada ejecución consume tokens. Una tarea programada cada cinco minutos equivale a 288 ejecuciones al día, y un agente que lee una página y decide no hacer nada también consume recursos por leerla. Configure los primeros agentes con un webhook o un activador de chat, supervise el gasto real durante una semana y cambie a una tarea programada cuando conozca el coste por ejecución.

Haga una copia de seguridad de Postgres y del almacén de objetos

Hay dos almacenes de datos y un secreto. Si pierde cualquiera de los tres, perderá la instancia. Haga una copia de la base de datos y del bucket durante la misma ventana, con el backend detenido. Así evita que se escriba un archivo después de volcar su fila de la base de datos.

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

Use como DB_USERNAME el valor que haya configurado para postgres si lo cambió. Después, copie el volumen del almacén de objetos usando el nombre con prefijo que mostró 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)

Compruebe que el volcado no esté vacío antes de confiar en él: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 debería mostrar CREATE TABLE y sentencias DROP TABLE, no un error en una sola línea. Después, copie los tres archivos fuera del servidor. Una copia de seguridad que sólo reside en el equipo que protege no es una copia de seguridad.

Para restaurar en un equipo nuevo, instale la misma etiqueta, vuelva a colocar el docker/.env.ce guardado para que coincidan la contraseña y la sal del cifrado de credenciales, inicie la pila una vez para crear los volúmenes, detenga el backend y cargue el volcado:

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

Actualizaciones y recuperación tras un fallo

Cree primero un volcado, siempre. El backend aplica sus migraciones de esquema al iniciar, y las migraciones sólo avanzan. Por eso, cambiar a un tag anterior después de una actualización defectuosa deja código antiguo ejecutándose con un esquema más reciente. La reversión consiste en restaurar el volcado. Por eso el volcado se crea primero.

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

Establezca TAG en el tag que seleccionó de la lista mostrada por el tercer comando. Supervise el registro del backend hasta que el endpoint de estado vuelva a responder. Su docker-compose.override.yml no está bajo seguimiento, por lo que un git checkout lo deja intacto. Sin embargo, revise la diferencia de docker-compose.yml entre los tags, porque un servicio nuevo o un servicio renombrado puede dejar obsoleta su anulación sin mostrar ningún mensaje de error.

Modos de fallo y mensajes que verá

Un contenedor se reinicia continuamente y docker compose ps muestra exited (137). Se trata del terminador de procesos por falta de memoria del kernel, y docker inspect livecontext-app lo confirma con "OOMKilled": true en el bloque de estado. El backend alcanzó su límite de 1536M, o el host se quedó sin memoria antes. Compruebe free -m antes de aumentar cualquier límite, porque aumentar el límite de un contenedor en un host sin memoria disponible sólo hará que el proceso terminado pertenezca a otro contenedor.

La descarga falla con no matching manifest for linux/arm64/v8 in the manifest list entries. Las imágenes sólo se publican para linux/amd64. Un VPS Arm no puede ejecutar esta pila con las imágenes publicadas, y la emulación mediante QEMU es demasiado lenta para una JVM con Chromium. Cambie a un plan x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. Otro proceso del host ya utiliza ese puerto. Cambie FRONTEND_PORT en docker/.env.ce, o aplique la sobrescritura anterior y no publique ningún puerto.

La interfaz está disponible, pero la solicitud de inicio de sesión falla después de añadir el proxy. El navegador está llamando al backend mediante un origen que el proxy no sirve. Abra la pestaña de red del navegador y compruebe el host de la solicitud que falla. Establezca GATEWAY_PUBLIC_URL en la URL pública del backend y vuelva a crear el contenedor frontend, porque ese valor se lee durante el arranque.

Todo está correcto, pero los archivos cargados en un flujo de trabajo desaparecen. Compruebe que minio-init muestre exited (0) en lugar de un código distinto de cero. Si el bucket workflow-files nunca se creó, el backend no tiene dónde almacenar los objetos.

Elija LiveContext o n8n

Elija LiveContext cuando el agente sea el elemento principal: quiere que el modelo cree y ejecute la automatización, y acepta que un servidor de 8 GB y un servicio Java son el coste. Elija n8n cuando necesite flujos de trabajo deterministas, una biblioteca amplia de nodos y una huella de recursos que pueda compartir un VPS con otros servicios. Los números de versión indicados aquí son recientes, v0.2.11 a fecha de agosto de 2026, así que fije la etiqueta de imagen y lea las notas de la versión antes de cada actualización. Para conocer el panorama más amplio, incluidas las herramientas intermedias entre estas dos opciones, consulte nuestro resumen de alternativas autoalojadas a n8n en lugar de leer una comparación limitada a estas dos.

FAQ

¿Cuánta RAM necesita un LiveContext autohospedado?

Planifique 8 GB. El README del proyecto indica 4 GB como mínimo y 8 GB como recomendación, y el archivo compose incluido coincide con ello: el backend por sí solo está limitado a 1536 MB, y los cinco servicios base suman algo menos de 3 GB antes de contar el contenedor frontend sin límite. Activar el perfil del agente de navegador añade otros 2048 MB para Chromium, además de un contenedor SearXNG, por lo que 8 GB deja de ser opcional.

¿Puedo ejecutar LiveContext en un VPS Arm?

No. Todas las imágenes publicadas están compiladas para linux/amd64, por lo que docker compose up en un plan Arm falla al extraer la imagen con no matching manifest for linux/arm64/v8 in the manifest list entries. En teoría, puede ejecutarlo mediante la emulación de QEMU, pero en la práctica no resulta utilizable para una carga de trabajo basada en JVM. Elija un plan x86.

¿Dónde coloco la clave de API del modelo?

En docker/.env.ce, como ANTHROPIC_API_KEY, OPENAI_API_KEY o GOOGLE_API_KEY, antes del primer arranque. El backend y el bridge la leen durante el arranque, y se aplica a toda la instancia, no a un solo usuario. Mantenga el archivo con el modo 600, use una clave creada únicamente para este servidor para poder revocarla por separado y establezca un límite de gasto en la consola del proveedor, porque ese límite es el único que se aplica fuera de la máquina.

¿Cómo hago una copia de seguridad de LiveContext?

Tres elementos: un pg_dump de la base de datos livecontext, una copia del volumen de MinIO y el archivo docker/.env.ce. Detenga los servicios livecontext y frontend mientras realiza las dos primeras copias, para que la base de datos y el almacén de objetos mantengan un estado coherente. El archivo de entorno es importante porque las credenciales almacenadas en los flujos de trabajo están cifradas con CREDENTIAL_ENCRYPTION_PASSWORD y CREDENTIAL_ENCRYPTION_SALT, por lo que una restauración sin esos valores deja filas de credenciales que ningún proceso del nuevo servidor puede leer.

¿Por qué el backend permanece en health: starting durante varios minutos después del arranque?

La comprobación de estado de compose establece start_period: 120s y consulta /actuator/health, por lo que Docker informa de que el servicio está arrancando mientras se ejecutan las migraciones del esquema y el registro de herramientas. Entre dos y tres minutos en el primer arranque es un comportamiento esperado. Si nunca pasa a un estado saludable, lea docker compose logs -f livecontext. Si la pila se detiene en el paso de migración, normalmente está apuntando a un volumen de base de datos de una versión más reciente.