Alternativas ao Open WebUI para um VPS

Qual alternativa ao Open WebUI deve ser instalada num VPS

As alternativas ao Open WebUI são quase sempre comparadas num portátil, onde a RAM é barata e nenhum serviço escuta num endereço público. Um VPS altera os dois fatores, e isso muda a classificação. O Open WebUI continua a ser a opção predefinida assim que uma segunda pessoa inicia sessão, porque inclui contas de utilizador reais e um painel de administração. Os projetos mais leves ganham quando a interface compete com o modelo pelo último gigabyte de RAM. O custo dessa vantagem é a autenticação: não têm nenhuma.

Tudo o que se segue baseia-se na documentação dos próprios projetos, consultada em agosto de 2026. Os quatro critérios são os que só se tornam relevantes quando o servidor está acessível a partir da Internet.

Quatro eixos que só importam num IP público

• Memória ao lado do modelo. O servidor do modelo é o processo que mais recursos consome no sistema. Cada megabyte que a interface mantém é um megabyte que o modelo não pode utilizar.
• Autenticação. Alguns destes projetos têm contas de utilizador e funções. Outros assumem que são a única aplicação em execução no seu portátil e não têm qualquer início de sessão.
• Inferência remota. Uma interface que só consegue aceder a 127.0.0.1:11434 obriga a executar o modelo no mesmo sistema que aloja a interface.
• Manutenção. Um contentor com um ficheiro SQLite é uma tarefa diferente de seis contentores com MongoDB e uma base de dados vetorial por trás.

Quanta RAM o modelo deixa para a interface

A interface não é o maior componente do sistema. O modelo é. Os tamanhos de transferência publicados indicam o mínimo, porque os pesos têm de permanecer residentes enquanto o modelo responde, e o consumo real de memória é superior ao tamanho transferido depois de a cache de contexto ser alocada.

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Estes são os valores apresentados nas páginas da biblioteca Ollama em agosto de 2026. São tamanhos publicados, não medições. Num VPS com 4 GB, qwen3:4b com 2.5 GB deixa menos de 1.5 GB para o sistema operativo e tudo o resto. A cache de contexto também consome memória à medida que a conversa cresce. Por isso, o num_ctx que define é uma decisão de memória tanto quanto de qualidade. qwen3:8b com 5.2 GB não cabe nesse sistema. Esta é uma limitação que as comparações de computadores portáteis nunca abordam. É também o ponto em que uma interface de chat que ocupa algumas centenas de megabytes determina se o modelo consegue executar. Se estiver a dimensionar um sistema para algo muito acima destas etiquetas, o cálculo para um modelo 27B num VPS apenas com CPU mostra como a interface deixa rapidamente de ser o valor determinante.

Faça medições em vez de confiar em qualquer valor de uma comparação, incluindo este. Execute docker stats --no-stream uma hora depois de iniciar a utilização real, não um minuto depois de o contentor arrancar, porque a memória relevante é alocada na primeira utilização. O Ollama também liberta os pesos após cinco minutos de inatividade. Por isso, uma leitura feita entre conversas subestima o pico, e a mensagem seguinte volta a pagar todo o carregamento, a menos que mantenha o modelo residente com keep_alive.

Open WebUI: continua a ser a opção predefinida para mais de um utilizador

O Open WebUI é executado a partir de uma imagem e mantém os dados num volume.

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

O comando no README do projeto publica -p 3000:8080, que escuta em todas as interfaces. O prefixo 127.0.0.1: mantém-no apenas na interface de loopback. Num VPS, esse prefixo é mais importante do que qualquer outra coisa nessa linha, porque o Docker escreve as suas próprias regras do iptables e uma porta publicada ignora as regras de negação do ufw.

Aceda à página através de um túnel ou de um proxy, ambos descritos abaixo, e crie a primeira conta. Essa conta torna-se a administradora. Os registos seguintes são criados com a função pending, o valor predefinido documentado em DEFAULT_USER_ROLE. Assim, um estranho que chegue à página continua sem poder usar o seu modelo até um administrador o aprovar.

O Open WebUI consome mais memória do que os projetos abaixo porque faz mais coisas, e a sua própria página de desempenho identifica os componentes responsáveis por esse consumo. O mecanismo de embeddings predefinido carrega um modelo sentence-transformers dentro do contentor, documentado com cerca de 500 MB por processo de trabalho. Definir RAG_EMBEDDING_ENGINE=ollama encaminha essa tarefa para o servidor de modelos que já executa. AUDIO_STT_ENGINE=webapi evita carregar um modelo local de conversão de voz em texto. Com SQLite e DATABASE_POOL_SIZE não definido, o pool recorre a um tamanho interno elevado, e cada ligação cria a sua própria cache de páginas e o seu próprio mapa de memória. Por isso, num servidor pequeno, defina DATABASE_POOL_SIZE=8 e DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False impede que a interface peça uma conclusão ao modelo enquanto o utilizador ainda está a escrever.

LibreChat: multiusuário, com uma stack por trás

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

A interface responde na porta 3080. O LibreChat é a opção certa quando precisa de um sistema de identidade, e não apenas de uma caixa de login: a documentação descreve logins LDAP e OAuth2, e a aplicação inclui um painel de administração para utilizadores e funções. Esta capacidade vem acompanhada de uma stack.

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

O ficheiro compose predefinido inicia 6 serviços: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Nenhum deles é o modelo. O MongoDB e o pgvector precisam de memória própria e, numa máquina com 4 GB, essa é memória que o modelo deixa de ter disponível.

As atualizações são uma operação git, e é aí que muitas pessoas cometem erros.

docker compose down
git pull
docker compose pull
docker compose up -d

git pull termina com um conflito se editar o docker-compose.yml controlado pelo repositório, deixando a atualização parcialmente aplicada. Coloque as suas alterações em docker-compose.override.yml, que o projeto fornece para este fim, e mantenha os segredos em .env. Ambos os ficheiros não são controlados pelo repositório, por isso git pull não os altera.

Aponte o LibreChat para o seu próprio servidor de modelos com um endpoint personalizado em librechat.yaml.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

Substitua model-host pelo endereço da máquina que executa o Ollama. O campo apiKey tem de estar presente, embora o Ollama ignore o seu valor, por isso pode usar um valor de placeholder. Se o LibreChat for executado no Docker e o Ollama estiver na mesma máquina, localhost dentro do contentor refere-se ao próprio contentor. Nesse caso, use host.docker.internal.

Hollama e OrionChat: o navegador faz o trabalho

Ollama disponibiliza uma aplicação web a partir de um único contentor pequeno. As conversas ficam no armazenamento do navegador, não no servidor.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

A versão deste comando no README usa --rm, que elimina o contentor quando este para. Por isso, a interface não volta a arrancar depois de um reboot. Atrás de um reverse proxy, adicione -e VITE_ALLOWED_HOSTS='chat.example.com', porque a imagem permite apenas o host localhost e responde a pedidos de qualquer outro hostname com um erro de host bloqueado, em vez de apresentar a aplicação.

O OrionChat vai mais longe e não tem qualquer componente no servidor. Clone o repositório e disponibilize a pasta com o servidor web que já utiliza, ou abra index.html a partir do disco. As API keys ficam armazenadas no localStorage do navegador, o histórico das conversas permanece no navegador e a aplicação elimina as conversas mais antigas quando a contagem ultrapassa 512.

Nenhum dos projetos tem login, porque nenhum tem um servidor que o possa validar. Num laptop, isso não é um problema. Num VPS, significa que a página nunca deve ser publicada em 0.0.0.0. Também significa algo que é fácil não notar: é o navegador que chama o modelo, não o servidor.

Esse facto determina onde estes dois projetos podem ser utilizados. O navegador tem de conseguir aceder diretamente ao Ollama. Por isso, o Ollama tem de escutar para além do loopback, e não tem qualquer tipo de autenticação. Daí resultam duas regras do navegador. Uma página servida por HTTPS não pode chamar um endpoint HTTP simples, e a consola apresenta Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked.. Um pedido para qualquer outra origem é recusado com has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource até permitir essa origem.

A forma documentada pelo Ollama para alterar qualquer uma destas definições é usar um override do systemd.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss deve agora apresentar 0.0.0.0:11434, onde antes apresentava 127.0.0.1:11434. Só faça esta alteração quando uma firewall ou um proxy com autenticação já controlar quem pode aceder à porta, porque um 11434 aberto é um servidor de modelos aberto, e os scanners em massa alcançam rapidamente uma porta pública nova. O túnel SSH abaixo evita completamente esta questão: a página passa a ser executada numa origem localhost, que o Ollama permite por predefinição, e a porta nunca sai da máquina.

Cada um pode usar um endpoint remoto do Ollama ou do vLLM

O Open WebUI pode, e a ligação é estabelecida no servidor. OLLAMA_BASE_URL=http://model-host:11434 aponta-o para o Ollama. Para vLLM ou qualquer outro servidor compatível com OpenAI, defina OPENAI_API_BASE_URL=http://model-host:8000/v1 com um OPENAI_API_KEY não vazio e mantenha o sufixo /v1, que é obrigatório. OPENAI_API_BASE_URLS aceita vários backends separados por ponto e vírgula.

O LibreChat também pode, através do baseURL do endpoint personalizado apresentado acima. Esse pedido também sai do servidor, portanto nenhuma regra do navegador se aplica. O mesmo URL base e a mesma chave de marcador funcionam fora de uma janela de chat, o que basta para apontar um agente de programação para o modelo que já aloja.

O Hollama e o OrionChat podem apontar para qualquer endpoint introduzido nas respetivas definições, mas o pedido sai do seu navegador. Tudo o que é indicado na secção acima se aplica a ambos, e a mais nenhum dos restantes casos.

Separar a interface do modelo é a principal vantagem de um endpoint remoto. Coloque a interface numa máquina pequena e o modelo onde existe memória suficiente. Este também é o momento de decidir se o Ollama ou o vLLM deve servir os pedidos, porque os dois comportam-se de forma muito diferente quando várias pessoas usam o modelo ao mesmo tempo. Se o servidor do modelo ainda não existir, comece por executar o Ollama numa VPS e, numa máquina apenas com CPU, leia como o Ollama se compara ao llama.cpp antes de escolher um runner.

Nunca publique uma interface de chat sem autenticação em 0.0.0.0

A página de hardening do Open WebUI afirma que o projeto foi "concebido para redes privadas e de confiança, à semelhança de outras infraestruturas autoalojadas, como bases de dados, registos de contentores e servidores de CI", e recomenda colocá-lo atrás de uma VPN ou de um reverse proxy com autenticação. Um projeto sem autenticação merece, no mínimo, o mesmo tratamento.

Verifique o que está a escutar antes de confiar em qualquer componente.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

Uma linha com 127.0.0.1:3000 é o resultado pretendido. Uma linha com 0.0.0.0:3000 significa que a sua interface de chat está acessível na Internet pública. A partir da sua própria máquina, curl -sI http://YOUR.VPS.IP:3000 a responder a HTTP/1.1 200 OK diz o mesmo de forma mais direta.

Desativar o login do Open WebUI com WEBUI_AUTH=False é uma configuração para um único utilizador, numa máquina que ninguém mais consegue alcançar. Além disso, a opção não é aplicada a uma instalação que já tenha contas. Nesse caso, é apresentada a mensagem You can't turn off authentication because there are existing users.

Padrão um: associar ao loopback e aceder através de SSH. Publique todas as portas em 127.0.0.1. Depois, encaminhe apenas o que precisar: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com e abra http://localhost:3000 no seu portátil. Nada é publicado, portanto nada pode ser pesquisado. No Hollama ou no OrionChat, encaminhe a porta do modelo no mesmo comando com -L 11434:127.0.0.1:11434 e mantenha o Ollama no loopback. Este padrão só é tão seguro quanto a sua configuração de SSH. Por isso, combine-o com SSH apenas com chaves e um sshd reforçado.

Padrão dois: um reverse proxy que autentica antes de a aplicação receber o pedido. Mantenha a aplicação no loopback, deixe o proxy gerir a porta 443 e coloque o início de sessão único à frente da aplicação. Traefik configurado através de labels do Docker Compose com Authentik como fornecedor de identidade fornece a todas as aplicações do servidor um único login e um único certificado. Com o Open WebUI atrás de TLS (transport layer security), defina WEBUI_SESSION_COOKIE_SECURE=true e WEBUI_SESSION_COOKIE_SAME_SITE=strict. Reduza também JWT_EXPIRES_IN em relação ao valor predefinido de quatro semanas, porque a documentação do Open WebUI indica que, sem Redis, terminar a sessão não invalida o token: este continua utilizável até expirar por si próprio.

O padrão dois não resolve o problema dos projetos que funcionam apenas no navegador. Um proxy à frente da página não protege o endpoint do modelo. Além disso, um pedido fetch dessa página para outro hostname não transporta o cookie da sua sessão. Por isso, o proxy que autentica à frente do Ollama responde com um redirecionamento para um formulário de login e o chat falha. Encaminhe o endpoint do modelo sob o mesmo hostname da página ou use o padrão um.

Qual escolher

Se outra pessoa além de si for utilizar o serviço, use o Open WebUI. Este produto tem contas reais, coloca os novos utilizadores numa fila de aprovação e os responsáveis publicam orientações de hardening que pode seguir. Se precisar de LDAP ou de um painel de administração, use o LibreChat e confirme com docker stats se os seus seis serviços, juntamente com o modelo, cabem efetivamente antes de depender dele. Se for uma única pessoa num servidor pequeno, onde o modelo já ocupa a maior parte da RAM, disponibilize o Hollama ou o OrionChat através de um túnel SSH e deixe o navegador manter o estado. A resposta errada num VPS é publicar qualquer um deles em 0.0.0.0 sem autenticação.

FAQ

A Open WebUI é segura para ser exposta diretamente num IP público?

A própria página de hardening descreve-a como software para redes privadas e de confiança, na mesma categoria de uma base de dados ou de um servidor de CI. Tem contas reais, e a primeira conta torna-se administradora, enquanto as seguintes permanecem pending até serem aprovadas. Por isso, é muito mais segura do que uma interface sem autenticação. Ainda assim, coloque-a atrás de um reverse proxy com TLS e, quando possível, single sign-on. Publique a porta do contentor como 127.0.0.1:3000:8080 para impedir que as próprias regras iptables do Docker a exponham à Internet sem o seu conhecimento.

Qual alternativa ao Open WebUI usa menos RAM numa VPS?

As alternativas baseadas no navegador, Hollama e OrionChat, porque a aplicação é executada no cliente. O servidor envia apenas ficheiros estáticos, e o OrionChat nem sequer precisa de um contentor de aplicação. O Open WebUI mantém um processo Python, uma base de dados e, por predefinição, um modelo local de embeddings em memória. A documentação indica cerca de 500 MB por worker apenas para o modelo de embeddings. Confirme os valores no seu próprio servidor com docker stats --no-stream, porque variam consoante as funcionalidades ativadas.

Estas interfaces de chat podem usar um servidor Ollama noutro host?

O Open WebUI e o LibreChat podem fazê-lo, e é o respetivo servidor que estabelece a ligação. Por isso, não se aplica nenhuma regra do navegador. Defina OLLAMA_BASE_URL para o Open WebUI ou baseURL num endpoint personalizado do LibreChat. Para o vLLM ou outro servidor compatível com OpenAI, use OPENAI_API_BASE_URL com o sufixo /v1 e uma API key não vazia. O Hollama e o OrionChat também podem apontar para qualquer endereço, mas o pedido é feito pelo seu navegador. Por isso, o endpoint também tem de estar acessível a partir do seu navegador.

Porque é que a minha interface de chat no navegador não consegue aceder ao Ollama?

Duas causas abrangem quase todos os casos. Por predefinição, o Ollama faz bind a 127.0.0.1:11434. Por isso, um navegador noutro computador nunca o consegue alcançar até OLLAMA_HOST ser alterada. Além disso, o Ollama aceita pedidos cross-origin apenas de localhost. Assim, uma página servida pelo seu próprio domínio é recusada com No 'Access-Control-Allow-Origin' header is present on the requested resource até essa origem ser listada em OLLAMA_ORIGINS. Se a página usar HTTPS e o endpoint usar HTTP, o navegador bloqueia o pedido como mixed content antes de o Ollama o receber. Defina ambas as variáveis numa substituição systemctl edit ollama.service, ou encaminhe a porta através de SSH. Nesse caso, o problema desaparece.