Como hospedar o LiveContext, alternativa ao n8n

O que é o LiveContext e quanto custa executá-lo

Para alojar o LiveContext por conta própria, precisa de um VPS com cerca de 8 GB de RAM. O LiveContext CE é uma plataforma de automação de código aberto que executa agentes de IA dentro da própria automação. É distribuída como uma stack Docker Compose com seis contentores, construída em torno de um backend Java. O README upstream indica 4 GB como requisito mínimo e 8 GB como valor recomendado. O ficheiro compose mostra como essa memória é utilizada.

O projeto está em livecontext-ai/livecontext-ce no GitHub e é licenciado ao abrigo da AGPL-3.0. A versão atual em agosto de 2026 é v0.2.11, publicada em 3 de agosto de 2026. Todas as imagens são compiladas apenas para linux/amd64, o que exclui os planos Arm económicos. Este guia fixa essa tag, coloca a stack atrás de um reverse proxy e explica o procedimento de backup que não está incluído na documentação upstream.

Dimensione o VPS antes de alojar o LiveContext

Todos os serviços do ficheiro compose fornecido têm um limite de memória explícito, para que possa dimensionar o servidor antes de o alugar. Estes são os limites definidos no ficheiro compose v0.2.11, não o consumo 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
  }
]

O backend, por si só, está limitado a 1536 MB. Esse limite aplica-se a um processo Java 21, pelo que a JVM ocupará grande parte dele e permanecerá nesse nível. Os cinco serviços base totalizam pouco menos de 3 GB, e o frontend não tem qualquer limite, pelo que utiliza a memória solicitada pelo Node. Num VPS de 4 GB, quase não sobra memória para o kernel e para a cache de páginas. Por isso, 4 GB é indicado como mínimo, não como recomendação.

Os perfis opcionais são o que eleva o requisito do servidor para 8 GB. O perfil do agente de browser adiciona um contentor Chromium limitado a 2048 MB, juntamente com uma instância de pesquisa SearXNG. O perfil de renderização adiciona mais 1024 MB para capturas de ecrã e PDFs. Nenhum dos dois arranca sem ativar o respetivo perfil, portanto mantenha ambos desativados até precisar deles. Esse contentor SearXNG existe para funcionar como backend de pesquisa do agente. Assim, as páginas que devolve chegam aos seus prompts como texto não fiável. Essa é a fronteira de confiança através da qual dar pesquisa web SearXNG a um agente de IA funciona em detalhe.

Se já executa o n8n, planeie substituí-lo em vez de o adicionar. A stack descrita em o nosso guia para executar o n8n num VPS com Docker e HTTPS consiste num processo Node juntamente com o Postgres e funciona confortavelmente num servidor pequeno. O LiveContext reserva mais memória apenas para o seu backend do que toda essa stack utiliza. Duas plataformas de automação num VPS de 8 GB funcionarão até ao momento em que ambas executarem uma tarefa no mesmo minuto. Se partilhar o servidor, defina também limites explícitos para todos os restantes serviços, usando o método descrito em o nosso artigo sobre como definir limites de memória no Docker Compose, para que um workflow descontrolado não derrube também a máquina.

Instalar o LiveContext com Docker Compose, fixado numa tag

Comece com uma VPS Ubuntu 24.04 limpa, com Docker Engine 24 ou mais recente e Compose v2. Se o Docker ainda não estiver instalado, siga primeiro o nosso guia básico de Docker Compose para uma VPS e depois volte aqui.

O README oferece npx livecontext como comando de arranque numa única linha. Isso é suficiente num portátil. Num servidor, é melhor manter o ficheiro Compose num diretório que controla, porque assim uma atualização consiste num checkout do git e pode consultar exatamente o que mudou.

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

O ficheiro Compose já fixa cada imagem na respetiva tag de lançamento, por exemplo ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Fazer checkout da tag correspondente do git mantém o ficheiro Compose e as imagens sincronizados, porque o ficheiro Compose de v0.2.11 foi criado para essas imagens. Não altere as tags para latest. Uma tag latest pode mudar sem aviso, e o backend executa as migrações da base de dados em cada arranque. Assim, um pull acidental pode avançar o schema às 3 da manhã, sem outra forma de recuperar além de restaurar uma cópia de segurança.

Edite docker/.env.ce antes do primeiro arranque (a secção seguinte indica o que deve alterar) e depois inicie a stack.

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

Use a mesma opção --env-file em todos os comandos do Compose neste guia. O Compose lê esse ficheiro novamente em cada invocação. Por isso, um comando sem essa opção usa os valores predefinidos incorporados no ficheiro Compose e pode publicar portas diferentes das que configurou.

O healthcheck do backend tem um start_period de 120s e consulta /actuator/health. Por isso, docker compose ps apresenta o serviço livecontext como health: starting durante aproximadamente os primeiros dois minutos, enquanto são executadas as migrações do schema e o registo da ferramenta. Isto é normal. Pode fazer uma verificação rápida a partir do servidor:

curl -s localhost:8080/actuator/health

Isto deve apresentar {"status":"UP"}. Quando isso acontecer, abra a interface web na porta 3000. A primeira conta que criar torna-se a conta de administrador, por isso crie a sua antes de a porta ficar acessível a terceiros. Esta é a razão mais importante para não publicar a porta 3000 na Internet no primeiro dia.

Os valores de ambiente que deve alterar

O ficheiro de exemplo inclui valores predefinidos funcionais para que a stack arranque num portátil. Vários deles são inseguros num 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

Gere cada valor aleatório com openssl rand -base64 32. Tenha em atenção os seguintes valores:

• POSTGRES_PASSWORD e MINIO_ROOT_PASSWORD são fornecidos como postgres e minioadmin. Nenhuma das portas da base de dados é publicada no host, por isso não ficam diretamente expostas. No entanto, qualquer contentor que associe posteriormente à mesma rede pode alcançar ambas com o valor predefinido documentado.
• CREDENTIAL_ENCRYPTION_PASSWORD e CREDENTIAL_ENCRYPTION_SALT são gerados automaticamente quando ficam vazios. Defina-os manualmente. As credenciais que os seus workflows armazenam são encriptadas com esse par. Por isso, um dump da base de dados restaurado num servidor novo sem a mesma password e salt produz linhas de credenciais que ninguém consegue ler. Defina-os uma vez e trate docker/.env.ce como parte da cópia de segurança.
• FRONTEND_PORT e BACKEND_PORT são substituídos nos mapeamentos de portas como ${FRONTEND_PORT:-3000}:3000 e ${BACKEND_PORT:-8080}:8080. O ficheiro de ambiente de exemplo define ambos explicitamente, e os valores fornecidos nem sempre são 3000 e 8080. Consulte a sua cópia em vez de assumir esses valores.
• GATEWAY_PUBLIC_URL é a origem do backend visível no browser. Torna-se relevante assim que utiliza um reverse proxy. Consulte a secção seguinte.
• As chaves dos modelos (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY e, opcionalmente, MISTRAL_API_KEY ou DEEPSEEK_API_KEY) ficam aqui em texto simples. Preencha apenas o provider que utiliza.

O que fazem os seis containers

• postgres executa pgvector/pgvector:pg16 como o container livecontext-db e contém a base de dados chamada livecontext. A extensão pgvector é necessária para a pesquisa por embeddings, por isso uma imagem postgres:16 normal não é suficiente.
• redis executa redis:7-alpine com appendonly yes e --maxmemory-policy noeviction. Esta política é deliberada: o Redis armazena aqui o estado das filas e das execuções. Quando atinge o limite de memória, devolve um erro ao processo que escreve, em vez de eliminar chaves silenciosamente. Um erro visível é preferível a trabalho que desaparece.
• minio é o armazenamento de objetos compatível com S3 para os ficheiros que circulam nos workflows. Um container minio-init executa mc mb myminio/workflow-files --ignore-existing no arranque, cria o bucket e termina. Ver minio-init como exited (0) em docker compose ps indica um estado saudável.
• bridge contém os adaptadores CLI e as ferramentas MCP (model context protocol). Escuta na porta 8093 dentro da rede Docker e não é publicada no host.
• livecontext é o backend, um monólito Java 21 na porta 8080. Executa o motor de workflows, os agendadores e os agentes.
• frontend é a interface web Next.js na porta 3000. Apenas estes dois últimos são publicados no host.

O estado é armazenado em cinco volumes nomeados: livecontext_data para o Postgres, livecontext_redis, livecontext_minio, livecontext_keys e livecontext_logs. O Compose acrescenta-lhes o nome do projeto como prefixo. Por predefinição, esse nome é o nome do diretório, pelo que o volume real no disco se chama algo como livecontext-ce_livecontext_minio. Execute docker volume ls e copie os nomes exatos antes de criar qualquer script de backup que os utilize.

docker compose down -v elimina os cinco volumes. É a forma documentada de começar de novo, mas também é a forma mais rápida de perder todos os workflows que criou. O -v é a diferença completa.

Coloque atrás do Traefik em vez de publicar a porta 3000

Publicar as portas 3000 e 8080 num VPS público expõe a aplicação sem TLS (segurança da camada de transporte) e sem uma barreira à frente do registo de administradores. Uma regra ufw não é suficiente por si só, porque o Docker insere as suas próprias regras iptables para as portas publicadas antes da cadeia gerida pelo ufw. Por isso, uma porta publicada em 0.0.0.0 continua acessível mesmo quando o ufw indica que a porta está bloqueada.

A correção adequada é não publicar nenhuma porta e permitir que o proxy alcance os contentores através de uma rede Docker partilhada. Crie docker-compose.override.yml na raiz do repositório:

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

networks:
  proxy:
    external: true

Dois detalhes determinam se isto funciona. !override substitui a lista de portas em vez de a combinar com ela. Isto requer o Compose v2.24 ou mais recente. Verifique com docker compose version, porque numa versão mais antiga do Compose as duas listas são combinadas e as portas continuam publicadas. Além disso, default tem de permanecer em cada lista networks, porque nomear uma rede substitui a rede predefinida. Se a remover, o frontend deixa de conseguir comunicar com o Postgres e o Redis. Confirme o resultado combinado antes de iniciar qualquer serviço:

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

Os routers, o resolvedor de certificados e o redirecionamento de HTTP para HTTPS são iguais aos de qualquer outra aplicação. Por isso, siga o nosso guia de reverse proxy com Traefik para executar várias aplicações num único VPS em vez de escrever aqui uma nova configuração TLS. Encaminhe um hostname para frontend na porta 3000 e um segundo hostname para livecontext na porta 8080.

O segundo hostname não é opcional. A interface Web chama o backend a partir do browser, por isso o backend precisa do seu próprio origin que possa ser alcançado pelo browser. Defina GATEWAY_PUBLIC_URL em docker/.env.ce com o URL desse backend, por exemplo https://lc-api.example.com. Se o omitir, a página carrega normalmente, mas todas as ações falham, porque a interface determinou o origin do backend a partir do endereço que abriu e está a chamar uma porta que o proxy nunca publicou.

Como a página de registo está aberta à primeira pessoa que a alcançar, é recomendável colocar autenticação forward no router do frontend. Assim, ninguém vê essa página sem se autenticar no proxy. É isso que executar o Authentik como a sua própria camada SSO acrescenta à mesma configuração do Traefik.

Onde fica a chave do modelo e por que uma instância ociosa ainda custa dinheiro

Os agentes são executados dentro da automação, o que altera a economia em comparação com uma ferramenta de workflows simples. A chave do provedor fica em docker/.env.ce como ANTHROPIC_API_KEY ou OPENAI_API_KEY, é lida pelo backend e pela bridge na inicialização e aplica-se à instância inteira. Ela não é definida por utilizador. Qualquer pessoa que tenha uma conta na sua instância e consiga criar um agente usa essa chave, e a primeira pessoa a registar-se é um administrador.

Três práticas ajudam a manter a fatura previsível. Crie uma chave de provedor separada para este VPS, para poder revogá-la sem afetar mais nada. Defina um limite máximo de gastos no console do provedor, porque esse limite é o único que fica fora da máquina que está a proteger. Depois, use os orçamentos de créditos por agente e as métricas por agente disponibilizadas pelo LiveContext, para que um único loop não esgote a chave antes de o detetar.

O custo de uma instância ociosa não é zero quando um agente é executado por agendamento. Um gatilho de agendamento é acionado independentemente de alguém estar a observar, e cada execução envia tokens. Um agendamento de cinco minutos corresponde a 288 execuções por dia, e um agente que lê uma página e decide não fazer nada continua a pagar pela leitura da página. Configure os primeiros agentes com um webhook ou um gatilho de chat, acompanhe os gastos reais durante uma semana e só depois passe para um agendamento, quando souber o custo por execução.

Faça backup do Postgres e do armazenamento de objetos

Existem dois armazenamentos de dados e um segredo. Perder qualquer um dos três causa a perda da sua instância. Faça o backup do banco de dados e do bucket na mesma janela, com o backend parado. Assim, nenhum arquivo poderá ser gravado depois que a respetiva linha do banco de dados for exportada.

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 o valor definido para DB_USERNAME no lugar de postgres se você o alterou. Em seguida, copie o volume do armazenamento de objetos usando o nome com prefixo exibido por 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)

Confirme que o dump não está vazio antes de confiar nele: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 deve mostrar instruções CREATE TABLE e DROP TABLE, e não um erro de uma única linha. Em seguida, copie os três arquivos para fora do servidor. Um backup que permanece apenas na máquina que protege não é um backup.

Para restaurar em um servidor novo, instale a mesma tag, coloque o docker/.env.ce salvo de volta para que a senha e o salt da encriptação das credenciais correspondam, inicie a stack uma vez para criar os volumes, pare o backend e carregue o 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

Atualizações e recuperação após uma falha

Faça um dump primeiro, sempre. O backend aplica as migrações do esquema durante o arranque, e as migrações só avançam. Por isso, depois de uma atualização mal sucedida, fazer checkout da tag anterior deixa o código antigo a funcionar com um esquema mais recente. O rollback significa restaurar o dump. É por isso que o dump vem primeiro.

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

Defina TAG como a tag escolhida na listagem apresentada pelo terceiro comando. Monitorize o log do backend até o endpoint de integridade voltar a responder. O seu docker-compose.override.yml não é monitorizado pelo Git, por isso um git checkout mantém-no no local. No entanto, leia as diferenças em docker-compose.yml entre as tags, porque um serviço novo ou a alteração do nome de um serviço pode tornar a sua substituição obsoleta sem apresentar qualquer mensagem de erro.

Modos de falha e as mensagens que verá

Um contentor reinicia continuamente e docker compose ps mostra exited (137). Esse é o mecanismo do kernel que termina processos quando a memória se esgota, e docker inspect livecontext-app confirma-o com "OOMKilled": true no bloco de estado. O backend atingiu o limite de 1536M ou o host ficou sem memória primeiro. Consulte free -m antes de aumentar qualquer limite, porque aumentar o limite de um contentor num host sem memória disponível apenas transfere a terminação para outro contentor.

A obtenção da imagem falha com no matching manifest for linux/arm64/v8 in the manifest list entries. As imagens foram publicadas apenas para linux/amd64. Um VPS Arm não consegue executar esta stack com as imagens publicadas, e a emulação através de QEMU é demasiado lenta para uma JVM com Chromium. Escolha um plano x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. Outro processo no host já está a utilizar essa porta. Altere FRONTEND_PORT em docker/.env.ce ou aplique a substituição indicada acima e não publique nenhuma porta.

A interface está disponível, mas o pedido de início de sessão falha depois de adicionar o proxy. O browser está a chamar o backend numa origem que o seu proxy não serve. Abra o separador de rede do browser e verifique o host do pedido que falhou. Defina GATEWAY_PUBLIC_URL como o URL público do backend e recrie o contentor frontend, porque esse valor é lido no arranque.

Tudo está saudável, mas os ficheiros carregados num workflow desaparecem. Confirme que minio-init mostra exited (0), em vez de um código diferente de zero. Se o bucket workflow-files nunca tiver sido criado, o backend não tem onde armazenar os objetos.

Escolha entre LiveContext e n8n

Escolha LiveContext quando o agente for o ponto central: pretende que o modelo crie e execute a automação e aceita uma máquina com 8 GB e um serviço Java como custo. Escolha n8n quando pretende fluxos de trabalho determinísticos, uma biblioteca extensa de nós e uma utilização de recursos que permita partilhar um VPS com outros serviços. Os números de versão apresentados aqui ainda são recentes, v0.2.11 em agosto de 2026, por isso fixe a sua tag e leia as notas de versão antes de cada atualização. Para conhecer melhor este conjunto de ferramentas, incluindo as que ocupam posições intermédias entre estas duas opções, consulte o nosso resumo das alternativas self-hosted ao n8n em vez de ler uma comparação limitada a estas duas.

FAQ

Quanta RAM o LiveContext autoalojado precisa?

Reserve 8 GB. O README do projeto indica 4 GB como mínimo e 8 GB como recomendação, e o ficheiro compose fornecido segue esses valores: só o backend está limitado a 1536 MB, e os cinco serviços base totalizam pouco menos de 3 GB antes de considerar o contentor frontend sem limite. Ativar o perfil do agente de browser acrescenta mais 2048 MB para o Chromium, além de um contentor SearXNG. A partir desse ponto, 8 GB deixa de ser opcional.

Posso executar o LiveContext numa VPS Arm?

Não. Todas as imagens publicadas são compiladas para linux/amd64, por isso docker compose up num plano Arm falha durante o pull com no matching manifest for linux/arm64/v8 in the manifest list entries. Em teoria, é possível executá-lo com emulação QEMU. Na prática, o desempenho é inutilizável para uma carga de trabalho JVM. Escolha um plano x86.

Onde devo colocar a chave da API do meu modelo?

Em docker/.env.ce, como ANTHROPIC_API_KEY, OPENAI_API_KEY ou GOOGLE_API_KEY, antes do primeiro arranque. O backend e a bridge leem esse valor no arranque, e ele aplica-se à instância inteira, não a um único utilizador. Mantenha o ficheiro com o modo 600, use uma chave criada apenas para este servidor para poder revogá-la de forma independente e defina um limite de gastos na consola do fornecedor, porque esse limite é a única restrição que fica fora da máquina.

Como faço backup do LiveContext?

São necessárias três coisas: um pg_dump da base de dados livecontext, uma cópia do volume MinIO e o ficheiro docker/.env.ce. Pare os serviços livecontext e frontend enquanto faz os dois primeiros backups, para que a base de dados e o armazenamento de objetos permaneçam consistentes entre si. O ficheiro env é importante porque as credenciais armazenadas nos seus workflows são encriptadas com CREDENTIAL_ENCRYPTION_PASSWORD e CREDENTIAL_ENCRYPTION_SALT. Sem esses valores, um restauro deixa linhas de credenciais que nada no novo servidor consegue ler.

Por que motivo o backend permanece em health: starting durante minutos depois do arranque?

O healthcheck do compose define start_period: 120s e consulta /actuator/health. Por isso, o Docker apresenta o serviço como estando a arrancar enquanto executa as migrações do esquema e o registo das ferramentas. Dois a três minutos no primeiro arranque é normal. Se nunca ficar saudável, leia docker compose logs -f livecontext. Uma stack que para na etapa de migração normalmente está a usar um volume de base de dados de uma release mais recente.