Cómo autoalojar LiveContext con Docker Compose

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 disponible que ejecuta agentes de IA dentro de la propia automatización, y se distribuye como una pila Docker Compose de siete contenedores basados en un backend Java, uno de los cuales es una tarea de ejecución única que finaliza tras la configuración. La documentación de autoalojamiento del proveedor solicita un mínimo de 4 GB y recomienda 8 GB; el archivo README de su lanzador npm indica ahora un mínimo de 6 GB, y el archivo compose muestra dónde se asigna esa memoria.

El proyecto se publicó como livecontext-ai/livecontext-ce en GitHub bajo AGPL-3.0, pero CE ya no es AGPL. La licencia distribuida con la versión actual es la LiveContext Sustainable Use License 1.1, una licencia de código disponible que le permite ejecutar y modificar CE, incluso en producción dentro de su propia empresa, pero prohíbe ofrecerlo a terceros bajo una modalidad alojada o integrada para competir con las versiones de pago de LiveContext. El lanzador npm del proveedor muestra el cambio: livecontext@0.2.11 declaraba AGPL-3.0-only, mientras que livecontext@0.3.8 apunta a ese archivo de licencia. A fecha de 13 de octubre de 2026, el repositorio de GitHub y la organización livecontext-ai devuelven un error 404, aunque la documentación del proveedor todavía indica clonarlo, por lo que esta guía utiliza los archivos de la versión obtenidos del paquete npm. La versión actual es v0.3.8, publicada el 9 de octubre de 2026. Cada imagen de LiveContext está compilada solo para linux/amd64, lo que descarta los planes económicos con arquitectura Arm. Esta guía fija esa etiqueta, coloca la pila detrás de un proxy inverso y convierte los consejos de copia de seguridad del proveedor en comandos.

Dimensionar el VPS antes de autoalojar LiveContext

La mayoría de los servicios en el archivo compose distribuido incluyen un límite de memoria explícito, por lo que puede dimensionar el servidor antes de alquilarlo. Dos no lo tienen: el trabajo de ejecución única minio-init y el frontend. Estos son los límites escritos en el archivo compose v0.3.8, no el uso medido.

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 2048
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "postgres",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "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 está limitado a 2048 MB. Ese límite se aplica sobre un proceso Java 21 cuyo heap está configurado en 1 GiB (-Xmx1024m con ZGC), y el comentario del propio archivo compose indica que el heap crece hasta ese GiB completo, sumando además la sobrecarga propia de la JVM. Los cinco servicios base con límites suman aproximadamente 3.6 GB, y el frontend no tiene límite alguno, por lo que consume lo que Node solicite. En un VPS de 4 GB, esos límites dejan solo unos pocos cientos de MB para el frontend, el kernel y el caché de páginas, razón por la cual el README del lanzador ahora establece el mínimo en 6 GB, aunque la documentación de autoalojamiento aún indique 4 GB.

Los perfiles opcionales son los que llevan el servidor a 8 GB. El perfil del agente de navegador añade un contenedor Chromium limitado a 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 a menos que habilite su perfil, así que mantenga ambos desactivados hasta que los necesite. El contenedor de Chromium se compila localmente desde un directorio websearch-service que el paquete npm no incluye, por lo que, al no estar accesible el repositorio de GitHub, el perfil del agente de navegador no puede compilarse a partir de los archivos publicados a fecha de 13 de octubre de 2026. El renderizador utiliza una imagen publicada y no se ve afectado. Ese contenedor de SearXNG existe para ser el backend de búsqueda del agente, por lo que las páginas que devuelve llegan a sus prompts como texto no confiable; este es el límite de confianza que otorgar a un agente de IA búsqueda web con SearXNG detalla.

Si ya ejecuta n8n, planee reemplazarlo en lugar de añadirlo. La pila en nuestra guía para ejecutar n8n en un VPS con Docker y HTTPS es un proceso Node junto a Postgres, y funciona cómodamente en un servidor pequeño. LiveContext reserva más memoria para su backend solo de la que utiliza toda esa pila. Dos plataformas de automatización en un mismo VPS de 8 GB cabrán hasta que ambas ejecuten un trabajo en el mismo minuto. Si comparte el host, establezca límites explícitos en todo lo demás también, utilizando el método en nuestra publicación sobre cómo establecer límites de memoria en Docker Compose, para que un flujo de trabajo descontrolado no bloquee la máquina.

Instalar LiveContext con Docker Compose, fijado a una etiqueta

Comience con un VPS con Ubuntu 24.04 limpio, Docker Engine 24 o superior y Compose v2. Si aún no tiene Docker instalado, siga primero nuestros fundamentos de Docker Compose para un VPS y luego regrese.

El README del lanzador ofrece npx livecontext@latest como inicio en una sola línea. Esto es aceptable en un equipo portátil, pero el lanzador copia de nuevo su archivo compose en cada ejecución y las imágenes que nombra tienen la etiqueta latest. En un servidor, usted necesita que el archivo compose resida en un directorio bajo su control, fijado a una versión específica, de modo que una actualización sea un archivo que pueda comparar mediante diff. La documentación del proveedor aún describe un git clone del repositorio de GitHub para esto, pero dicho repositorio devuelve un error 404 desde el 13 de octubre de 2026. Por lo tanto, obtenga los mismos dos archivos, el archivo compose y el archivo de entorno de ejemplo, desde el paquete npm de la versión que desee.

sudo apt update && sudo apt install -y npm
npm view livecontext version
mkdir -p ~/livecontext-ce/docker ~/livecontext-ce/catalog-seeds
cd ~/livecontext-ce
npm pack livecontext@0.3.8
tar xzf livecontext-0.3.8.tgz
cp package/assets/docker-compose.yml .
cp package/assets/.env.example docker/.env.ce
chmod 600 docker/.env.ce

El archivo compose monta mediante bind-mount ./catalog-seeds en el backend, razón por la cual el directorio se crea arriba. El lanzador npm lo llena con un paquete de catálogo de modelos que descarga al iniciar, y la pila comienza con él vacío.

El archivo compose en el paquete npm nombra cada imagen de LiveContext con la etiqueta latest, por ejemplo ghcr.io/livecontext-ai/livecontext-ce:latest, a pesar de que su propio comentario de cabecera indica que la etiqueta está fijada a la versión. Fíjela usted mismo antes del primer inicio. El proveedor publica las mismas etiquetas de versión en Docker Hub bajo el espacio de nombres livecontext, donde v0.3.8 aparecía para las imágenes de backend, frontend, bridge y renderer el 13 de octubre de 2026, así que apunte las cuatro imágenes allí:

sed -i -E 's#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v0.3.8#' docker-compose.yml
grep -n 'image:' docker-compose.yml

Utilizar el archivo compose de la misma versión que las imágenes es lo que mantiene a ambos sincronizados, ya que el archivo compose para v0.3.8 fue escrito para esas imágenes. No deje las etiquetas en latest. Una etiqueta latest cambia sin previo aviso y el backend ejecuta sus migraciones de base de datos en cada inicio, por lo que una descarga accidental puede actualizar su esquema a las 3 a.m. sin posibilidad de revertirlo, salvo mediante una restauración.

Edite docker/.env.ce antes del primer inicio (la siguiente sección enumera qué cambiar) y luego levante la pila.

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

Utilice el mismo flag --env-file en cada comando de compose en esta guía. Compose lee ese archivo de nuevo en cada invocación, por lo que un comando sin el flag recurre a los valores predeterminados integrados en el archivo compose y puede publicar puertos diferentes a los que usted configuró.

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

curl -s localhost:8080/actuator/health

Esto debería imprimir {"status":"UP"}. Cuando lo haga, abra la interfaz web en el puerto 3000. La primera cuenta que cree se convierte en administrador, y el registro público se cierra después de eso a menos que un administrador lo vuelva a abrir, así que cree la suya antes de que el puerto sea accesible por cualquier otra persona. Esta es la razón más importante para no publicar el puerto 3000 en Internet desde el primer día.

Los valores de env que debe cambiar

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

DB_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
PUBLIC_BASE_URL=https://lc.example.com
GATEWAY_PUBLIC_URL=https://lc-api.example.com

Genere cada valor aleatorio con openssl rand -base64 32. Notas sobre los que pueden causar problemas:

• DB_PASSWORD y MINIO_ROOT_PASSWORD se distribuyen como postgres y minioadmin. El archivo compose pasa DB_PASSWORD a Postgres como su POSTGRES_PASSWORD. Ninguno de los puertos de la base de datos se publica en el host, por lo que no están expuestos directamente, pero cualquier contenedor que conecte más tarde a la misma red puede acceder a ambos con el valor predeterminado documentado.
• CREDENTIAL_ENCRYPTION_PASSWORD y CREDENTIAL_ENCRYPTION_SALT se distribuyen comentados y se generan automáticamente en el primer arranque si se dejan vacíos. Defínalos usted mismo en su lugar. Las credenciales que almacenan sus flujos de trabajo se cifran con ese par, por lo que una copia de seguridad de la base de datos restaurada en una máquina nueva sin la misma contraseña y salt deja las filas de credenciales ilegibles. Defínalos una vez y luego trate docker/.env.ce como parte de la copia de seguridad.
• FRONTEND_PORT y BACKEND_PORT se sustituyen en los mapeos de puertos como ${FRONTEND_PORT:-3000}:3000 y ${BACKEND_PORT:-8080}:8080. El archivo env de ejemplo se distribuye con ambos comentados, como # FRONTEND_PORT=3000 y # BACKEND_PORT=8080, por lo que se aplican los valores predeterminados 3000 y 8080 hasta que descomente una línea para sobrescribirlos.
• PUBLIC_BASE_URL es la dirección de la interfaz web visible desde el navegador, y el archivo de ejemplo solicita a las instalaciones en servidor que la definan junto con GATEWAY_PUBLIC_URL. Escríbalas ambas sin una barra diagonal al final, ya que el archivo de ejemplo advierte que una de ellas interrumpe las devoluciones de llamada de OAuth.
• GATEWAY_PUBLIC_URL es el origen del backend visible desde el navegador. Es importante tan pronto como se utiliza un reverse proxy. Consulte la siguiente sección.
• Las claves de modelo (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY y, opcionalmente, MISTRAL_API_KEY o DEEPSEEK_API_KEY) residen aquí en texto plano. Rellene solo el proveedor que utilice realmente.

Qué hacen los siete contenedores

• postgres ejecuta pgvector/pgvector:pg16 como el contenedor livecontext-db, que contiene la base de datos llamada livecontext. La extensión pgvector está presente para la búsqueda de embeddings, por lo que una imagen postgres:16 estándar no sirve.
• redis ejecuta redis:7-alpine con appendonly yes y --maxmemory-policy noeviction. Esta política es deliberada: Redis gestiona aquí la cola y el estado de ejecución, de modo que cuando alcanza su límite de memoria, devuelve un error al escritor en lugar de descartar claves silenciosamente. Un error visible es preferible a un trabajo que desaparece.
• minio es el almacenamiento de objetos compatible con S3 para los archivos que se mueven a través de los flujos de trabajo.
• minio-init es un contenedor de ejecución única que ejecuta mc mb myminio/workflow-files --ignore-existing al iniciar, crea el bucket y finaliza. Ver minio-init como exited (0) en docker compose ps es el estado correcto.
• bridge contiene los adaptadores CLI y las herramientas MCP (model context protocol). Escucha en el puerto 8093 dentro de la red de Docker y no está publicado hacia el host.
• livecontext es el backend, un monolito en Java 21 en el puerto 8080. Ejecuta el motor de flujo de trabajo, los planificadores y los agentes.
• frontend es la interfaz web en Next.js en el puerto 3000. Solo estos dos últimos están publicados hacia el host.

El estado reside en siete volúmenes con nombre: livecontext_data para Postgres, livecontext_redis, livecontext_minio, livecontext_keys, livecontext_bridge_secret, livecontext_cli_home y livecontext_logs. Compose les añade el prefijo del nombre del proyecto, que el archivo compose define como livecontext-ce, por lo que el volumen real en el disco se llama algo parecido a livecontext-ce_livecontext_minio. El lanzador npm sobrescribe ese nombre con -p livecontext, por lo que un equipo que ejecutó npx livecontext mantiene un segundo conjunto con el prefijo livecontext_. Ejecute docker volume ls y copie los nombres exactos antes de escribir cualquier script de copia de seguridad para ellos.

docker compose down -v elimina los siete volúmenes. La documentación del proveedor indica no ejecutarlo nunca, ya que es la forma más rápida de perder todos los flujos de trabajo creados. El -v marca toda la diferencia.

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 una puerta de acceso antes del registro de administradores. Una regla de ufw no es suficiente por sí sola, ya que Docker inserta sus propias reglas de iptables para los puertos publicados antes de la cadena que gestiona ufw, por lo que un puerto publicado en 0.0.0.0 permanece accesible incluso cuando ufw indica que el puerto está denegado.

La solución limpia es no publicar nada y permitir que el proxy acceda a los contenedores a través de una red Docker compartida. Cree docker-compose.override.yml junto a docker-compose.yml:

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 fusionarse con ella, lo cual requiere Compose v2.24 o posterior: verifique con docker compose version, ya que en una versión anterior de Compose las dos listas se fusionan y los puertos permanecen publicados. Además, default debe permanecer en cada lista de networks, porque nombrar cualquier red reemplaza a la predeterminada, por lo que omitirlo desconecta el backend de Postgres y Redis, y el frontend del backend. Confirme el resultado de la fusión 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, así que siga nuestra guía de proxy inverso Traefik para ejecutar varias aplicaciones en un mismo VPS en lugar de escribir una nueva configuración TLS aquí. Enrute un nombre de host a frontend en el puerto 3000 y un segundo 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 al que el navegador pueda acceder. Establezca GATEWAY_PUBLIC_URL en docker/.env.ce a esa URL del backend, por ejemplo https://lc-api.example.com, y PUBLIC_BASE_URL a la URL del frontend. Si lo omite, la página se cargará normalmente mientras que cada acción fallará, porque la interfaz resolvió el origen del backend a partir de la dirección con la que la abrió y está llamando a un puerto que su proxy nunca publicó.

Dado que la página de registro está abierta para quien llegue primero, vale la pena implementar autenticación en el router del frontend para que nadie vea esa página sin autenticarse en el proxy, que es lo que añade ejecutar Authentik como su propia capa de 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 la economía frente a una herramienta de flujos de trabajo convencional. La clave del proveedor se guarda en docker/.env.ce como ANTHROPIC_API_KEY o OPENAI_API_KEY, el backend y el bridge la leen al iniciarse y se aplica a toda la instancia. No está limitada por usuario. Cualquier persona que tenga una cuenta en la instancia y pueda crear un agente utilizará esa clave, y la primera persona que se registre obtiene permisos de administrador. Si necesita agentes y gasto por persona que pueda atribuir realmente a un compañero, alojar OneCLI como un sistema de un agente por persona aborda el mismo problema de las claves desde el lado contrario: coloca todas las claves de modelos detrás de un gateway que sabe quién realiza la llamada.

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.

Realizar copias de seguridad de Postgres y del almacenamiento de objetos

Existen dos almacenes de datos y dos ubicaciones que contienen secretos: el archivo de entorno y el volumen livecontext_keys, que la documentación del proveedor incluye entre los volúmenes que deben respaldarse. La pérdida de cualquiera de ellos implica la pérdida de su instancia. Realice la copia de la base de datos y del bucket en la misma ventana de tiempo, con el backend detenido, para evitar que se escriba un archivo después de que su fila correspondiente en la base de datos haya sido volcada.

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

Utilice el valor que haya configurado como DB_USERNAME en lugar de postgres si lo ha modificado. A continuación, copie los volúmenes del almacenamiento de objetos y de las claves, utilizando los nombres con prefijo que docker volume ls mostró:

docker run --rm \
  -v livecontext-ce_livecontext_minio:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-minio-$(date +%F).tgz -C /data .
docker run --rm \
  -v livecontext-ce_livecontext_keys:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-keys-$(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 sentencias CREATE TABLE y DROP TABLE, no un error de una sola línea. Después, copie los cuatro archivos fuera del servidor, junto con docker-compose.yml y su archivo de anulación. Una copia de seguridad que reside únicamente en la máquina que protege no es una copia de seguridad.

Para restaurar en un equipo nuevo, instale la misma etiqueta, coloque el archivo docker/.env.ce guardado en su lugar para que la contraseña de cifrado de credenciales y el salt coincidan, inicie la pila una vez para que los volúmenes existan, detenga el backend, descomprima el archivo de claves en el volumen de claves de la misma forma en que se obtuvo y, finalmente, 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 ante fallos

Realice siempre una copia de seguridad antes de empezar. El backend aplica sus migraciones de esquema al iniciar y estas solo avanzan, por lo que volver a una versión anterior tras una actualización fallida deja código antiguo ejecutándose sobre un esquema nuevo. Revertir implica restaurar la copia de seguridad, razón por la cual esta es el paso previo obligatorio.

cd ~/livecontext-ce
npm view livecontext version
TAG=0.3.8
npm pack "livecontext@$TAG"
rm -rf package && tar xzf "livecontext-$TAG.tgz"
cp docker-compose.yml docker-compose.yml.prev
cp package/assets/docker-compose.yml .
sed -i -E "s#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v$TAG#" docker-compose.yml
diff docker-compose.yml.prev docker-compose.yml
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 la versión que imprimió el segundo comando. Monitorice el registro del backend hasta que el endpoint de salud vuelva a responder. Su docker-compose.override.yml no forma parte del paquete, por lo que copiar el nuevo archivo compose lo mantiene en su lugar, pero revise el diff que imprime el comando diff, ya que un servicio nuevo o renombrado puede dejar su configuración de anulación obsoleta sin mostrar ningún mensaje de error. Compare también docker/.env.ce con package/assets/.env.example, puesto que allí se incluyen los nuevos ajustes.

Modos de fallo y mensajes asociados

Un contenedor se reinicia constantemente y docker compose ps muestra exited (137). Se trata del mecanismo OOM Killer (Out-Of-Memory) del kernel, y docker inspect livecontext-app lo confirma con "OOMKilled": true en el bloque de estado. El backend alcanzó su límite de 2048M o el host se quedó sin memoria. Compruebe free -m antes de aumentar cualquier límite, ya que elevar el límite de un contenedor en un host sin recursos libres solo provocará que el kernel termine otro proceso.

La descarga (pull) falla con no matching manifest for linux/arm64/v8 in the manifest list entries. Las imágenes están publicadas únicamente para linux/amd64. Un VPS con arquitectura Arm no puede ejecutar esta pila a partir de las imágenes publicadas, y la emulación mediante QEMU es demasiado lenta para una JVM junto con Chromium. Migre a un plan x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. Otro proceso en el host ya está utilizando ese puerto. Configure FRONTEND_PORT en docker/.env.ce, o aplique la anulación anterior y no publique ningún puerto.

La interfaz está activa pero la solicitud de inicio de sesión falla tras añadir el proxy. El navegador está llamando al backend en un origen que su proxy no sirve. Abra la pestaña de red del navegador y observe el host de la solicitud fallida. Establezca GATEWAY_PUBLIC_URL en la URL pública del backend y vuelva a crear el contenedor del frontend, ya que ese valor se lee durante el inicio.

Todo funciona correctamente pero los archivos subidos en un flujo de trabajo desaparecen. Compruebe que minio-init muestra 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.

Elegir entre LiveContext o n8n

Elija LiveContext cuando el agente sea el objetivo: usted desea que el modelo cree y ejecute la automatización, y acepta una máquina de 8 GB y un servicio Java como coste. Elija n8n cuando necesite flujos de trabajo deterministas, una amplia biblioteca de nodos y un consumo de recursos que permita compartir un VPS con otros servicios. Las licencias ya no marcan una diferencia entre ambos. LiveContext CE pasó de AGPL-3.0 a la LiveContext Sustainable Use License 1.1, una licencia de código disponible de la misma familia fair-code que la licencia de uso sostenible de n8n, así que lea las restricciones de alojamiento antes de ofrecer cualquiera de ellos a personas ajenas a su empresa. La versión autohospedada de n8n también reserva algunas funciones para clientes de pago, por lo que debe comprobar qué partes de n8n son gratuitas y cuáles requieren una clave de licencia antes de crear un flujo de trabajo de equipo en torno a una de ellas. Los números de versión aquí son recientes, v0.3.8 a fecha de 13 de octubre de 2026, y la línea 0.3 lanzó nueve versiones entre el 22 de septiembre y el 9 de octubre de 2026, así que fije su versión y lea los cambios antes de cada actualización. Para un panorama más amplio, incluyendo las herramientas que se sitúan entre estas dos posiciones, consulte nuestro resumen de alternativas autohospedadas a n8n en lugar de leer una comparativa centrada únicamente en estos dos.

FAQ

¿Cuánta memoria RAM necesita una instancia de LiveContext autohospedada?

Planifique 8 GB. La documentación de autohospedaje del proveedor indica 4 GB como mínimo y 8 GB como recomendación, el README del lanzador menciona ahora 6 GB como mínimo, y el archivo compose incluido explica el motivo: el backend por sí solo está limitado a 2048 MB, y los cinco servicios base con límites suman unos 3,6 GB antes de contar el contenedor del frontend, que no tiene límite. Habilitar el perfil del agente de navegador añade otros 2048 MB para Chromium además de un contenedor SearXNG, por lo que 8 GB dejan de ser opcionales en ese punto.

¿Puedo ejecutar LiveContext en un VPS con arquitectura Arm?

No. Todas las imágenes publicadas de LiveContext para v0.3.8 están compiladas para linux/amd64, por lo que docker compose up en un plan Arm falla durante el pull con no matching manifest for linux/arm64/v8 in the manifest list entries. Ejecutarlo bajo emulación QEMU es posible en teoría, pero inutilizable en la práctica para una carga de trabajo JVM. Elija un plan x86.

¿Dónde debo colocar mi clave API del modelo?

En docker/.env.ce, como ANTHROPIC_API_KEY, OPENAI_API_KEY o GOOGLE_API_KEY, antes del primer inicio. El backend y el bridge la leen al arrancar y se aplica a toda la instancia en lugar de a un solo usuario. Mantenga el archivo con permisos 600, utilice una clave creada exclusivamente para este servidor para poder revocarla de forma independiente y establezca un límite de gasto en la consola del proveedor, ya que ese límite es la única restricción que reside fuera de la máquina.

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

Cuatro elementos: un pg_dump de la base de datos livecontext, una copia del volumen de MinIO, una copia del volumen livecontext_keys y el archivo docker/.env.ce. Detenga los servicios livecontext y frontend mientras realiza el volcado y las copias de los volúmenes para que la base de datos y el almacenamiento de objetos sean coherentes entre sí. El archivo env es fundamental porque las credenciales almacenadas en sus flujos de trabajo están cifradas con CREDENTIAL_ENCRYPTION_PASSWORD y CREDENTIAL_ENCRYPTION_SALT; una restauración sin esos valores deja filas de credenciales que ningún componente en el nuevo servidor podrá leer.

¿Por qué el backend permanece en health: starting durante minutos tras el arranque?

El healthcheck del compose establece start_period: 120s y consulta /actuator/health, por lo que Docker informa que el servicio está iniciando mientras se ejecutan las migraciones de esquema y el registro de herramientas. Es normal que tarde de dos a tres minutos en el primer arranque. Si nunca llega a un estado saludable, consulte docker compose logs -f livecontext. Una pila que se detiene en el paso de migración suele estar apuntando a un volumen de base de datos de una versión más reciente.