Alternativas ao Open WebUI para um VPS

Qual alternativa ao Open WebUI deve ser usada num VPS

As alternativas ao Open WebUI quase sempre são comparadas num portátil, onde a RAM é barata e nenhum serviço escuta num endereço público. Um VPS altera os dois factos, 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 fornece contas de utilizador reais e um painel de administração. Os projetos mais leves vencem quando a interface compete com o modelo pelo último gigabyte de RAM. O preço dessa vantagem é a autenticação: não têm nenhuma.

Tudo o que se segue vem da 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 junto do modelo. O servidor do modelo é o processo mais dispendioso da máquina. Cada megabyte usado pela interface é um megabyte que fica indisponível para o modelo.
• Autenticação. Alguns destes projetos têm contas de utilizador e funções. Outros partem do princípio de 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 na mesma máquina que 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 disponível para a interface

A interface não é o componente maior do servidor. O modelo é. Os tamanhos de download publicados indicam o limite mínimo, porque os pesos têm de permanecer na memória enquanto o modelo responde. O uso real de memória é maior do que o tamanho do download 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 pelas 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 reduz ainda mais esse espaço à medida que a conversa cresce. qwen3:8b com 5.2 GB não cabe nesse servidor. Esta é a situação que as comparativas de portáteis nunca abordam. É também neste ponto que uma interface de chat que ocupa algumas centenas de megabytes determina se o modelo consegue ser executado.

Faça uma medição em vez de confiar em qualquer valor de uma comparativa, incluindo nesta. Execute docker stats --no-stream uma hora depois de iniciar o uso real, não um minuto depois de o contentor arrancar, porque a memória relevante é alocada na primeira utilização.

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 o serviço apenas na interface de loopback. Numa VPS, esse prefixo é mais importante do que qualquer outro elemento da linha, porque o Docker escreve as suas próprias regras de 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 o administrador. Os registos posteriores são criados com a função pending, o valor predefinido documentado de DEFAULT_USER_ROLE. Assim, alguém não autorizado que aceda à página continua sem poder usar o seu modelo até um administrador aprovar a conta.

O Open WebUI consome mais memória do que os projetos abaixo porque oferece mais funcionalidades, 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, com um consumo documentado de cerca de 500 MB por processo de trabalho. Definir RAG_EMBEDDING_ENGINE=ollama encaminha esse trabalho para o servidor de modelos que já executa. AUDIO_STT_ENGINE=webapi evita o carregamento de 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 mapeamento 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 indicada quando é necessário um sistema de identidades, e não apenas uma caixa de login: a documentação descreve logins LDAP e OAuth2 e 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. MongoDB e 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 de git, e é nessa parte que surgem mais erros.

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

git pull é interrompido com um conflito se tiver editado o docker-compose.yml controlado pelo repositório. Nesse caso, a atualização fica aplicada apenas parcialmente. 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 através de 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 respetivo valor, por isso pode usar um marcador. Se o LibreChat executar no Docker e o Ollama executar na mesma máquina, localhost dentro do contentor refere-se ao próprio contentor. Nesse caso, utilize host.docker.internal.

Hollama e OrionChat: o navegador faz o trabalho

O Hollama 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 apresentada 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 com 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 web server que já executa, ou abra index.html a partir do disco. As chaves da API são guardadas 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 portátil, isto não constitui um problema. Num VPS, significa que a página nunca deve ser publicada em 0.0.0.0. Também significa algo fácil de ignorar: é 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 alcançar diretamente o Ollama. Por isso, o Ollama tem de escutar para além do loopback e não tem qualquer tipo de autenticação. Daqui 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.. Uma chamada para qualquer outra origem é recusada com has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource até essa origem ser autorizada.

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 deverá agora apresentar 0.0.0.0:11434, onde antes apresentava 127.0.0.1:11434. Faça esta alteração apenas quando uma firewall ou um proxy com autenticação controlar quem pode alcançar a porta, porque um 11434 aberto é um servidor de modelos aberto e os scanners em massa alcançam rapidamente uma nova porta pública. O túnel SSH abaixo evita completamente esta questão: a página é então executada numa origem localhost, que o Ollama permite por predefinição, e a porta nunca sai do servidor.

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

O Open WebUI pode, e a ligação é feita no servidor. OLLAMA_BASE_URL=http://model-host:11434 aponta-o para o Ollama. Para o 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 de baseURL do endpoint personalizado mostrado acima. Esse pedido também sai do servidor, portanto nenhuma regra do browser se aplica.

O Hollama e o OrionChat podem apontar para qualquer endpoint introduzido nas respetivas definições, mas o pedido sai do browser. Tudo o que é referido na secção acima se aplica a eles e a mais nada neste caso.

Separar a interface do modelo é a principal vantagem de um endpoint remoto. Coloque a interface numa máquina pequena e o modelo onde houver memória disponível. Este também é o momento de decidir se o Ollama ou o vLLM deve processar os pedidos, porque os dois comportam-se de forma muito diferente quando várias pessoas usam o modelo em simultâneo. 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 com o llama.cpp antes de escolher um runner.

Nunca publique uma interface de chat sem login 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 qualquer login merece, no mínimo, o mesmo tratamento.

Verifique o que está a escutar antes de confiar no serviço.

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á 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 mostra o mesmo de forma ainda mais direta.

Desativar o login do Open WebUI com WEBUI_AUTH=False é uma configuração para um único utilizador, destinada a uma máquina à qual mais ninguém consegue aceder. Além disso, a opção recusa aplicar-se a uma instalação que já tenha contas e apresenta a mensagem You can't turn off authentication because there are existing users.

Padrão 1: associar ao loopback e aceder através de SSH. Publique todas as portas em 127.0.0.1 e encaminhe apenas o que for necessário: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, depois abra http://localhost:3000 no seu portátil. Nada é publicado, pelo que nada pode ser analisado externamente. 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 2: 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 2 não resolve o problema dos projetos que funcionam apenas no browser. Um proxy à frente da página não protege o endpoint do modelo, e um pedido fetch dessa página para um hostname diferente 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 através do mesmo hostname da página ou use o padrão 1.

Qual escolher

Se outra pessoa além de si for utilizar o serviço, execute o Open WebUI. Tem contas de utilizador reais, os novos utilizadores entram numa fila de aprovação e os responsáveis pelo projeto publicam orientações de hardening que pode seguir. Se precisar de LDAP ou de um painel de administração, execute o LibreChat e confirme com docker stats que os seus seis serviços, juntamente com o seu 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. Num VPS, a resposta errada é publicar qualquer um deles em 0.0.0.0 sem autenticação à frente.

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 confiáveis, 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 abram à Internet sem o seu conhecimento.

Qual alternativa ao Open WebUI utiliza menos RAM numa VPS?

As alternativas baseadas no browser, 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 conforme as funcionalidades ativadas.

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

O Open WebUI e o LibreChat podem fazê-lo, e a ligação é estabelecida pelo respetivo servidor, pelo que não se aplica nenhuma regra do browser. Defina OLLAMA_BASE_URL no 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 chave API não vazia. O Hollama e o OrionChat também podem apontar para qualquer endereço, mas o pedido é feito pelo seu browser. Por isso, o endpoint também tem de estar acessível a partir do browser.

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

Duas causas abrangem quase todos os casos. Por predefinição, o Ollama fica associado a 127.0.0.1:11434. Por isso, um browser noutro computador não consegue chegar até ele enquanto OLLAMA_HOST não for alterada. Além disso, o Ollama aceita pedidos de origem cruzada apenas a partir 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 utilizar HTTPS e o endpoint utilizar HTTP, o browser bloqueia o pedido como conteúdo misto antes de o Ollama o receber. Defina ambas as variáveis numa substituição systemctl edit ollama.service, ou reencaminhe a porta através de SSH para eliminar o problema.