Open WebUI: Instalar ChatGPT Privado em 13 Passos [2026]

Quem quer um ChatGPT privado, sem enviar uma única mensagem para servidores de terceiros, tem hoje uma opção madura: o Open WebUI. A ferramenta open source passou de projeto de nicho a interface de referência para quem corre modelos de IA em casa ou na empresa, com lançamentos quase semanais ao longo de 2026. A versão mais recente, a v0.11.3, foi publicada a 31 de agosto de 2026, poucos dias depois da v0.11.1 ter introduzido aprovações de chamadas de ferramentas e um assistente que pergunta antes de agir. Neste tutorial mostramos, passo a passo, como instalar o Open WebUI com Docker, ligá-lo ao Ollama, proteger o acesso com OIDC e deixar tudo pronto para produção com HTTPS e backups automáticos.

O guia foi escrito para quem já usa a linha de comandos com alguma regularidade, mas não exige experiência prévia com Docker avançado. No final, vai ter um sistema completo, com interface de chat parecida com o ChatGPT, gestão de utilizadores, base de conhecimento própria (RAG) e ligação opcional a modelos na nuvem, tudo a correr na sua própria máquina ou servidor.

Cobrimos 13 passos práticos, do arranque do Docker até ao hardening final, mais uma secção dedicada a erros comuns, nove situações reais de resolução de problemas e um projeto completo de docker-compose que pode copiar diretamente. Reserve cerca de 60 minutos para seguir tudo do início ao fim, incluindo o tempo de download da primeira imagem e do primeiro modelo.

O que é o Open WebUI e porque está em alta em 2026

O Open WebUI é uma interface web de código aberto que coloca uma camada de chat, gestão e administração à frente de modelos de linguagem, locais ou remotos. Em vez de depender de uma app na nuvem, o utilizador instala o software no próprio computador ou servidor e mantém o controlo total sobre os dados, os registos de conversa e as chaves de acesso. O projeto está hospedado no GitHub, soma 170 lançamentos até final de agosto de 2026 e mantém um ritmo de atualização raro em software self-hosted: quatro versões só entre junho e julho (0.10.0, 0.10.1, 0.10.2 e 0.11.0).

Na prática, o projeto funciona como uma camada independente do motor de inferência. Isso significa que a mesma instalação de Open WebUI pode conversar com um modelo pequeno a correr localmente via Ollama, com um cluster de GPUs numa rede interna via vLLM, ou com um serviço na nuvem através de uma chave de API, sempre pela mesma interface e sob as mesmas regras de acesso. Essa flexibilidade é uma das razões pelas quais o projeto ultrapassou concorrentes mais simples: uma equipa pode começar com um portátil e crescer para um servidor dedicado sem trocar de ferramenta nem perder o histórico de conversas e documentos já carregados.

A procura pelo termo “open webui” cresceu de forma consistente em Portugal ao longo do último ano, com picos nos meses em que a equipa lançou funcionalidades maiores. Parte da atração explica-se pelo ângulo de segurança e privacidade: nenhuma mensagem sai da rede onde o Open WebUI está instalado, a autenticação pode ser ligada a um fornecedor de identidade corporativo via OIDC e os administradores decidem exatamente que modelos, plugins e integrações ficam disponíveis para cada equipa. Isto tornou a ferramenta popular tanto entre programadores individuais como em departamentos de TI que querem oferecer um “ChatGPT interno” sem mandar dados para fora da organização.

Vale destacar três mudanças recentes que tornam a v0.11.x especialmente relevante para quem está a instalar agora. Primeiro, a v0.11.1 (25 de agosto de 2026) trouxe aprovações de chamadas de ferramentas e um “ask_user” que permite ao modelo parar a meio de uma resposta para pedir esclarecimentos. Segundo, o streaming por delta reduziu drasticamente o tráfego de rede gerado por cada resposta, algo que ajuda em ligações mais lentas. Terceiro, a v0.9.6 trouxe sincronização de base de conhecimento e integrações com Azure AI Foundry, o que facilita cenários híbridos entre modelos locais e serviços na nuvem.

Pré-requisitos: hardware, software e versões necessárias

Antes de avançar, confirme que tem os seguintes componentes instalados e atualizados. O Open WebUI corre em qualquer sistema operativo com suporte a Docker, incluindo Linux, macOS e Windows com WSL2.

Docker Engine na versão mais recente disponível, com o plugin Docker Compose v2 incluído
Ollama na versão mais recente publicada em ollama.com, para servir os modelos localmente
Pelo menos 9 a 10 GB de espaço livre em disco só para as imagens Docker, antes de contar com o espaço dos modelos
8 GB de RAM como mínimo para modelos pequenos (3B a 7B parâmetros), ou 16 GB ou mais para modelos de 13B a 20B
Uma GPU Nvidia com suporte a CUDA é opcional, mas acelera muito a inferência em modelos maiores
Uma conta de e-mail ou fornecedor OIDC (Google Workspace, Microsoft Entra ID, Okta) se planear autenticação centralizada
Um domínio próprio e acesso a um servidor DNS, caso queira expor o serviço com HTTPS fora da rede local

A tabela seguinte resume os requisitos por cenário de utilização, para ajudar a escolher o hardware certo antes de começar a instalação.

Cenário	RAM recomendada	GPU	Disco livre	Exemplo de modelo
Portátil pessoal, só CPU	8 GB	Não necessária	15 GB	Modelo de 3B a 7B parâmetros
Estação de trabalho com GPU de entrada	16 GB	8 GB VRAM	30 GB	Modelo de 7B a 13B parâmetros
Servidor para equipa pequena	32 GB	16 GB VRAM	60 GB	Modelo de 13B a 34B parâmetros
Servidor departamental multiutilizador	64 GB ou mais	24 GB VRAM ou mais	150 GB ou mais	Vários modelos em simultâneo

Passo 1: Preparar o Docker e a pasta do projeto

Comece por confirmar que o Docker está a correr corretamente e crie uma pasta dedicada ao projeto. Isto evita misturar ficheiros de configuração com outros projetos e facilita o backup mais tarde.

docker --version
docker compose version
mkdir -p ~/open-webui-stack
cd ~/open-webui-stack
mkdir -p ollama-data openwebui-data caddy-data

Se o comando docker --version falhar, instale o Docker Engine seguindo as instruções oficiais para a sua distribuição antes de continuar. Em Windows, confirme que o WSL2 está ativo e que o Docker Desktop está configurado para usar esse subsistema, caso contrário os contentores vão consumir muito mais memória do que o necessário.

Passo 2: Instalar o Ollama como motor local

O Open WebUI não faz inferência sozinho: precisa de um motor que carregue e execute os modelos. O Ollama é a escolha mais comum porque simplifica o download e a gestão de pesos de modelos com um único comando. Pode correr o Ollama fora do Docker (diretamente no sistema operativo) ou dentro de um contentor próprio, o que facilita manter tudo isolado.

# Instalação nativa em Linux
curl -fsSL https://ollama.com/install.sh | sh

# Confirmar que o serviço está ativo
ollama --version
ollama list

Em macOS ou Windows, descarregue o instalador diretamente do site oficial do Ollama. Depois de instalado, o serviço fica disponível na porta 11434 por omissão, que é exatamente a porta que o Open WebUI vai usar para comunicar com ele no passo seguinte.

Passo 3: Criar o docker-compose.yml do Open WebUI

Existem duas formas de lançar o Open WebUI: um comando único, útil para um teste rápido, ou um ficheiro de orquestração completo, recomendado para qualquer instalação que vá durar mais do que uma tarde. Cobrimos as duas.

Opção A: contentor único para um teste rápido

Se só quer confirmar que tudo funciona antes de investir tempo num ficheiro de configuração, este comando único basta. Assume que o Ollama já está a correr no sistema anfitrião, fora do Docker.

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart unless-stopped \
  ghcr.io/open-webui/open-webui:latest

Esta opção é rápida, mas mistura tudo num único contentor sem isolar o Ollama, o que dificulta a gestão a médio prazo. Para o resto deste tutorial, seguimos a opção B, que separa cada serviço e é a base recomendada para produção.

Opção B: Docker Compose completo (recomendado)

Com o Ollama pronto, o próximo passo é escrever o ficheiro de orquestração que vai lançar o Open WebUI e ligá-lo à rede local do Ollama, cada um no seu próprio contentor. Este ficheiro é o coração do projeto: guarda-o na pasta criada no passo 1.

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ./ollama-data:/root/.ollama
    ports:
      - "11434:11434"

  open-webui:
    image: ghcr.io/open-webui/open-webui:latest
    container_name: open-webui
    restart: unless-stopped
    depends_on:
      - ollama
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=troque-esta-chave-por-uma-aleatoria
    volumes:
      - ./openwebui-data:/app/backend/data
    ports:
      - "3000:8080"

Repare que o Open WebUI expõe a porta interna 8080 na porta externa 3000. Pode alterar este número se já tiver outro serviço a usar a porta 3000. A variável WEBUI_SECRET_KEY deve ser substituída por uma cadeia aleatória, gerada por exemplo com openssl rand -hex 32, para assinar as sessões de forma segura.

Passo 4: Lançar os contentores e confirmar que estão saudáveis

Com o ficheiro guardado, é hora de subir a stack e verificar os registos para confirmar que ambos os serviços arrancaram sem erros.

docker compose up -d
docker compose ps
docker compose logs -f open-webui

Espere ver uma linha semelhante a “Uvicorn running on http://0.0.0.0:8080” nos registos do Open WebUI. O primeiro arranque demora mais tempo porque o contentor descarrega dependências adicionais na primeira execução. Se o comando docker compose ps mostrar o estado “Restarting” em loop, avance para a secção de resolução de problemas mais abaixo antes de continuar.

Vale confirmar também que os dois contentores conseguem falar entre si antes de avançar para o navegador. Corra docker exec -it open-webui curl -s http://ollama:11434 e espere uma resposta com o texto “Ollama is running”. Se receber um erro de nome não resolvido, confirme que ambos os serviços estão definidos no mesmo docker-compose.yml, porque o Docker Compose cria automaticamente uma rede interna partilhada entre serviços do mesmo ficheiro, mas não entre stacks lançadas separadamente.

Passo 5: Primeiro acesso e conta de administrador

Abra o navegador e visite http://localhost:3000. Na primeira visita, o Open WebUI pede para criar a conta de administrador: introduza um nome, um e-mail e uma palavra-passe forte. Esta é a única conta com acesso ao painel de administração até criar outras, por isso guarde as credenciais num gestor de palavras-passe.

Depois do registo, entre no painel através do ícone de perfil no canto inferior esquerdo e confirme, em Definições de Administrador, que a opção “Permitir novos registos” está desativada se não quiser que qualquer pessoa com acesso à rede crie uma conta sozinha. Esta é uma das primeiras coisas a rever num deployment que vai ficar exposto a mais do que uma pessoa.

Passo 6: Escolher e testar modelos no Ollama

Com a interface a funcionar, falta ter pelo menos um modelo descarregado para conversar. Pode fazê-lo pela linha de comandos ou diretamente na interface do Open WebUI, em Definições de Administrador > Modelos.

# Descarregar um modelo pequeno para testes rápidos
docker exec -it ollama ollama pull llama3.2

# Confirmar que ficou disponível
docker exec -it ollama ollama list

Depois de descarregado, o modelo aparece automaticamente no seletor de modelos do Open WebUI, no topo da janela de conversa. Se quiser testar vários modelos lado a lado, o Open WebUI permite comparar respostas de dois ou mais modelos na mesma conversa, o que ajuda a escolher qual se ajusta melhor a cada tarefa antes de o disponibilizar à equipa toda.

Passo 7: Configurar OIDC para autenticação de equipa

Para uso individual, a conta local criada no passo 5 é suficiente. Mas em equipas, a autenticação centralizada via OIDC evita gerir palavras-passe duplicadas e permite revogar acesso de forma imediata quando alguém sai da organização. O Open WebUI suporta este fluxo desde a linha de lançamentos 0.8.x, com reforços de segurança nas versões seguintes.

environment:
  - ENABLE_OAUTH_SIGNUP=true
  - OAUTH_CLIENT_ID=id-da-aplicacao-registada
  - OAUTH_CLIENT_SECRET=segredo-da-aplicacao
  - OPENID_PROVIDER_URL=https://login.seu-fornecedor.com/.well-known/openid-configuration
  - OAUTH_PROVIDER_NAME=Entra ID
  - OAUTH_SCOPES=openid email profile

Registe primeiro uma aplicação no seu fornecedor de identidade (Microsoft Entra ID, Okta ou Google Workspace, por exemplo), definindo como URL de redirecionamento https://o-seu-dominio/oauth/oidc/callback. Depois de copiar o ID de cliente e o segredo para o bloco acima, reinicie a stack com docker compose up -d e teste o botão de início de sessão via SSO que passa a aparecer na página de login.

Passo 8: Ativar RAG com documentos próprios

Uma das razões para usar o Open WebUI em vez de um chat genérico é a possibilidade de o modelo responder com base em documentos internos, sem que esses ficheiros saiam da rede. A funcionalidade de RAG (geração aumentada por recuperação) já vem integrada e ganhou sincronização oficial de base de conhecimento e pastas aninhadas na versão 0.9.6.

Para ativar, aceda a Área de Trabalho > Conhecimento, crie uma nova coleção e arraste os ficheiros PDF, Markdown ou texto que quer disponibilizar. O Open WebUI divide o conteúdo em fragmentos, gera embeddings localmente e guarda tudo no volume openwebui-data definido no docker-compose.yml. Depois, basta referenciar a coleção com o símbolo “#” numa conversa para que o modelo passe a usar esses documentos como contexto antes de responder.

Passo 9: Tool-call approvals, ask_user e outras novidades da v0.11

A v0.11.1, lançada a 25 de agosto de 2026, introduziu um mecanismo de aprovação para chamadas de ferramentas: sempre que um modelo tenta executar uma ação externa (por exemplo, correr um comando ou consultar uma API), o Open WebUI pede confirmação explícita ao utilizador antes de avançar. Esta funcionalidade fica em Definições de Administrador > Ferramentas e é especialmente relevante para quem liga agentes autónomos a sistemas sensíveis.

A mesma versão trouxe o “ask_user”, um comando interno que permite ao modelo parar a meio de uma resposta para pedir um esclarecimento, em vez de assumir uma interpretação e seguir em frente. Combinado com o navegador de ficheiros no terminal, que mostra pré-visualizações de documentos diretamente na conversa, e o streaming por delta, que reduz o tráfego de rede gerado por cada resposta, o conjunto de novidades da v0.11.x torna o Open WebUI mais previsível para uso em equipa do que as versões anteriores a 2026.

Passo 10: Gerir utilizadores, grupos e permissões

Com o SSO configurado, o painel de administração passa a listar automaticamente cada pessoa que iniciou sessão pela primeira vez. Em Definições de Administrador > Utilizadores, atribua cada conta a um grupo (por exemplo, “Engenharia” ou “Suporte”) e defina, por grupo, que modelos, coleções de conhecimento e ferramentas ficam visíveis.

Esta segmentação evita que toda a organização tenha acesso ao mesmo conjunto de dados e modelos. Uma equipa jurídica, por exemplo, pode ter acesso apenas a um modelo mais conservador e a uma coleção de documentos legais, enquanto a equipa de engenharia usa um modelo maior com acesso ao repositório de código. Revise esta lista periodicamente, sobretudo depois de saídas de colaboradores, porque contas inativas com permissões largas são um dos riscos mais comuns em instalações self-hosted mal geridas.

Passo 11: Ligar modelos externos via API (OpenAI, Mistral, DeepSeek)

Nem sempre um modelo local chega para todas as tarefas. O Open WebUI permite adicionar chaves de API de fornecedores externos, para que os utilizadores escolham entre um modelo local e um modelo na nuvem a partir do mesmo seletor, sem trocar de aplicação.

Para configurar, aceda a Definições de Administrador > Conexões e adicione um novo ponto de acesso do tipo compatível com a API da OpenAI. A maioria dos fornecedores atuais, incluindo Mistral AI e DeepSeek, expõe endpoints compatíveis com este formato, o que significa que basta indicar o URL base do fornecedor e a respetiva chave de API para o modelo aparecer na lista. Isto é útil para comparar respostas entre um modelo local mais rápido e um modelo na nuvem mais capaz, mantendo o registo de qual foi usado em cada conversa.

Quando compensa usar um modelo local em vez de pagar por API

A escolha entre modelo local e modelo pago via API depende do volume de uso e da sensibilidade dos dados. Para tarefas com grandes volumes de texto repetitivo, como triagem de tickets de suporte ou resumo de documentos internos, um modelo local elimina custos por token e evita que conteúdo confidencial saia da rede. Para tarefas pontuais que exigem o desempenho máximo de um modelo de fronteira, a chamada a uma API paga continua a ser mais prática do que tentar correr um modelo equivalente em hardware próprio. Muitas equipas acabam com um modelo local como opção por omissão e uma ligação externa reservada para casos específicos, exatamente o cenário que o passo 11 configura.

Privacidade dos dados e superfície de ataque num deployment self-hosted

Instalar o Open WebUI resolve o problema de mandar conversas para servidores de terceiros, mas cria um novo perímetro que passa a ser da sua responsabilidade proteger. Cada documento carregado para RAG, cada conversa guardada e cada chave de API adicionada nas conexões externas fica armazenada no volume openwebui-data definido no docker-compose.yml. Se esse servidor for comprometido, o atacante ganha acesso a tudo isso de uma só vez, o que é diferente do risco disperso de usar vários serviços na nuvem separados.

Três frentes merecem atenção redobrada. A primeira é o controlo de acesso à rede: o Open WebUI não deve ficar acessível a partir de qualquer IP da internet sem uma camada de autenticação forte à frente, seja OIDC, seja uma VPN. A segunda é a gestão de segredos: chaves de API de fornecedores externos, configuradas no passo 11, ficam guardadas na base de dados interna e devem ser tratadas com o mesmo cuidado que credenciais de produção, nunca partilhadas em capturas de ecrã ou registos de suporte. A terceira é a superfície criada pelas ferramentas e agentes: com as aprovações de chamadas de ferramentas introduzidas na v0.11.1, cada ação que um modelo tenta executar fora da conversa passa a exigir confirmação humana, o que reduz consideravelmente o risco de um agente mal configurado apagar ficheiros ou chamar uma API sensível sem supervisão.

Trate o Open WebUI como trataria qualquer outra aplicação interna crítica: com atualizações regulares, registos de auditoria revistos periodicamente e um plano de resposta caso uma conta de administrador seja comprometida. Nenhuma destas medidas é exclusiva desta ferramenta, mas o facto de o software correr dentro da própria rede, em vez de num fornecedor externo com equipa de segurança dedicada, transfere para o administrador local a responsabilidade que normalmente seria partilhada com um fornecedor de nuvem.

Passo 12: HTTPS com proxy reverso Caddy

Se o Open WebUI vai ficar acessível fora da rede local, nunca o exponha diretamente na porta 3000 sem cifra. O Caddy é uma opção simples porque gera e renova certificados TLS automaticamente, sem configuração manual de certificados.

# Caddyfile
ia.o-seu-dominio.pt {
    reverse_proxy open-webui:8080
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
    }
}

Adicione um serviço Caddy ao docker-compose.yml, montando este ficheiro e o volume caddy-data criado no passo 1, e aponte o registo DNS do domínio para o IP público do servidor antes de reiniciar a stack. Os cabeçalhos de segurança incluídos acima reduzem a superfície de ataque comum em painéis administrativos expostos à internet.

Passo 13: Backup, atualização e hardening de segurança

Uma instalação self-hosted só é segura se também for mantida atualizada e tiver cópias de segurança regulares. Automatize os dois processos desde o primeiro dia, em vez de deixar para depois de um incidente.

# Backup dos dados do Open WebUI e do Ollama
tar -czf backup-open-webui-$(hostname)-$(date +%F).tar.gz \
  openwebui-data ollama-data

# Atualizar para a versão mais recente
docker compose pull
docker compose up -d
docker image prune -f

Agende o comando de backup com uma tarefa cron semanal e guarde o ficheiro resultante fora do servidor, por exemplo num bucket de armazenamento cifrado. Para o hardening, desative o registo público de novas contas (passo 5), mantenha o Docker Engine atualizado, restrinja a porta 3000 a tráfego interno usando uma firewall e reveja periodicamente o changelog oficial antes de atualizar em produção, já que algumas versões alteram variáveis de ambiente obrigatórias.

Open WebUI vs LM Studio vs AnythingLLM: qual escolher

O Open WebUI não é a única forma de correr IA localmente. LM Studio e AnythingLLM são duas alternativas frequentemente comparadas, cada uma com um foco diferente. O LM Studio prioriza uma experiência de desktop simples, pensada para um único utilizador, enquanto o AnythingLLM foca-se em fluxos de RAG mais elaborados. O Open WebUI diferencia-se pelo desenho pensado para várias pessoas, com gestão de utilizadores, OIDC e um ecossistema de plugins mais ativo.

Ferramenta	Modelo de deployment	Multiutilizador	OIDC / SSO	RAG integrado	Licença
Open WebUI	Docker (self-hosted)	Sim, com grupos	Sim	Sim, com sincronização de conhecimento	Código aberto
LM Studio	Aplicação de desktop	Não	Não	Limitado	Gratuita, código fechado
AnythingLLM	Desktop ou Docker	Parcial	Parcial	Sim, foco principal	Código aberto
Jan.ai	Aplicação de desktop	Não	Não	Limitado	Código aberto

Para uso individual num único computador, o LM Studio ou o Jan.ai chegam para a maioria das pessoas. Para equipas que precisam de controlo de acesso, auditoria e uma interface partilhada, o Open WebUI é hoje a opção mais completa entre as ferramentas open source deste segmento.

O que mudou nas últimas versões do Open WebUI

Antes de instalar, vale a pena perceber o ritmo de evolução do projeto ao longo de 2026, porque algumas funcionalidades descritas neste tutorial só existem a partir de certas versões.

Versão	Data	Principais novidades
v0.8.12	27 março 2026	Renderização 25% mais rápida, payloads de administração 99% menores, autenticação OIDC empresarial
v0.9.6	junho 2026	Sincronização oficial de base de conhecimento, pastas aninhadas, integrações com Azure AI Foundry
v0.10.0 / v0.10.1	29 junho 2026	Correções e otimizações intermédias
v0.10.2	1 julho 2026	Ajustes de estabilidade
v0.11.0	27 julho 2026	Redesenho da interface, sub-agentes, páginas de pastas, navegação de conversas melhorada
v0.11.1	25 agosto 2026	Aprovações de chamadas de ferramentas, ask_user, navegador de ficheiros no terminal, streaming por delta
v0.11.3	31 agosto 2026	Correções e afinações sobre a v0.11.1, versão mais recente disponível

Se estiver a atualizar uma instalação antiga da linha 0.8.x diretamente para a v0.11.3, leia o changelog completo no repositório oficial antes de correr docker compose pull, porque o salto envolve várias mudanças de esquema de base de dados e algumas variáveis de ambiente foram renomeadas entre versões.

Este ritmo de lançamentos, com várias versões por mês em alguns períodos de 2026, tem um efeito prático na forma como uma equipa deve planear atualizações. Em vez de seguir cada versão assim que sai, muitas instalações de produção adotam uma janela de espera de uma a duas semanas antes de atualizar, tempo suficiente para que a comunidade reporte problemas no repositório oficial. Para instalações pessoais ou de teste, atualizar de imediato não traz grande risco. Já num servidor departamental com dezenas de utilizadores, vale mais a pena testar cada nova versão num ambiente separado antes de a aplicar ao serviço que a equipa usa diariamente, seguindo a mesma lógica de staging descrita na secção de dicas avançadas.

Erros comuns ao instalar o Open WebUI

Estes são os enganos mais frequentes de quem instala o Open WebUI pela primeira vez, reunidos a partir dos passos deste tutorial.

Deixar a chave secreta por omissão: não trocar o valor de WEBUI_SECRET_KEY invalida as sessões sempre que o contentor reinicia e é um risco de segurança em qualquer deployment partilhado
Expor a porta 3000 diretamente à internet: sem um proxy reverso com TLS, as credenciais e os documentos carregados circulam sem cifra
Não isolar os volumes de dados: guardar openwebui-data e ollama-data fora de uma pasta dedicada dificulta o backup e aumenta o risco de apagar dados por engano
Ignorar o tamanho do modelo face à RAM disponível: tentar correr um modelo de 34B numa máquina com 8 GB de RAM resulta em lentidão extrema ou falhas por falta de memória
Deixar o registo público ativo: manter “Permitir novos registos” ligado numa instalação exposta permite que qualquer pessoa com o URL crie uma conta
Atualizar em produção sem ler o changelog: saltar várias versões de uma vez pode quebrar integrações OIDC configuradas com variáveis de ambiente antigas

Resolução de problemas: 9 situações reais

Se algo correr mal durante ou depois da instalação, comece por aqui antes de procurar ajuda externa.

O contentor open-webui reinicia em loop: corra docker compose logs open-webui e procure erros de ligação à base de dados interna. Normalmente resolve-se apagando o volume openwebui-data e recriando, se ainda não tiver dados importantes
A interface carrega mas não aparece nenhum modelo: confirme que a variável OLLAMA_BASE_URL aponta para o nome do serviço definido no docker-compose.yml (ollama), não para localhost
Erro “connection refused” ao ligar ao Ollama: verifique se o contentor ollama está mesmo a correr com docker compose ps e se a porta 11434 não está ocupada por outra instalação nativa do Ollama no mesmo sistema
O login com OIDC falha com erro de redirecionamento: confirme que o URL de callback registado no fornecedor de identidade corresponde exatamente ao domínio e caminho usados pelo Open WebUI, incluindo o protocolo https
Os documentos de RAG não são encontrados nas respostas: confirme que referenciou a coleção com “#” na conversa e que o processamento de embeddings terminou, visível no ícone de estado junto ao nome da coleção
A resposta do modelo demora minutos a começar: sem GPU, modelos acima de 13B parâmetros podem ser lentos em CPU. Experimente um modelo mais pequeno ou ative aceleração por GPU se disponível
O upload de ficheiros falha silenciosamente: verifique o limite de tamanho de upload configurado e o espaço livre no volume openwebui-data
As aprovações de chamadas de ferramentas não aparecem: confirme que está a correr pelo menos a v0.11.1, já que esta funcionalidade não existe em versões anteriores
O certificado TLS do Caddy não é emitido: confirme que o registo DNS do domínio já aponta para o IP do servidor antes de reiniciar o Caddy, e que as portas 80 e 443 estão abertas na firewall

Dicas avançadas para produção

Depois de a instalação base estar estável, algumas práticas adicionais ajudam a manter o serviço fiável à medida que mais pessoas o usam. Separe o Ollama num servidor próprio com GPU dedicada quando o número de utilizadores simultâneos crescer, em vez de partilhar recursos com o contentor da interface. Use um serviço de monitorização simples, como um endpoint de verificação de saúde chamado a cada poucos minutos, para ser avisado se o Open WebUI parar de responder fora de horas.

Considere também limitar, por grupo de utilizadores, o acesso a modelos externos pagos, para evitar custos inesperados de API. Ative registos de auditoria para ações administrativas sensíveis, como alterações de permissões ou remoção de utilizadores, e exporte esses registos periodicamente para um sistema externo caso a instalação seja alvo de uma auditoria de segurança. Por fim, teste o processo de restauro do backup pelo menos uma vez antes de precisar dele a sério: um backup nunca testado é apenas uma suposição.

Se a instalação crescer para mais do que uma dezena de utilizadores simultâneos, vale a pena separar o tráfego por prioridade. Modelos usados em tarefas de produção, como assistentes voltados para clientes internos, devem correr num contentor Ollama isolado do contentor usado para experimentação por programadores, para que um teste pesado não deixe o serviço principal lento. Da mesma forma, mantenha um ambiente de staging com a mesma versão do docker-compose.yml usada em produção, para validar cada atualização antes de a aplicar ao serviço que a equipa usa todos os dias. Esta separação custa pouco tempo a configurar e evita que um erro de configuração afete todos os utilizadores ao mesmo tempo.

Perguntas frequentes

O Open WebUI é gratuito?
Sim, o software é código aberto e pode ser usado sem custo de licença. Os únicos custos são os do hardware onde o instala e, opcionalmente, das chamadas a APIs externas se ligar modelos na nuvem.

Preciso mesmo do Ollama, ou posso usar só modelos na nuvem?
Não é obrigatório. O Open WebUI funciona apenas com conexões a APIs externas, sem qualquer modelo local, mas nesse caso perde-se a vantagem de privacidade total que motiva a maioria das instalações self-hosted.

Quanto espaço em disco os modelos ocupam?
Varia muito consoante o tamanho: um modelo de 7B parâmetros ocupa tipicamente entre 4 e 5 GB, enquanto modelos acima de 30B podem ultrapassar os 20 GB cada.

Posso correr o Open WebUI num Raspberry Pi ou mini-PC?
A interface em si corre em hardware modesto, mas a inferência de modelos de linguagem exige RAM e processamento consideráveis. Um mini-PC com 16 GB de RAM consegue correr modelos pequenos com desempenho aceitável, mas não substitui uma GPU dedicada para uso intensivo.

É seguro expor o Open WebUI à internet pública?
Só com as proteções corretas: HTTPS via proxy reverso, autenticação OIDC ou palavras-passe fortes, registo de novas contas desativado e atualizações regulares. Sem estas camadas, um painel administrativo exposto é um alvo fácil.

Como faço a migração de uma instalação antiga para a versão mais recente?
Faça sempre um backup completo dos volumes de dados antes de atualizar, leia o changelog da versão de destino no repositório oficial e teste a atualização num ambiente separado se a instalação for crítica para o negócio.

O Open WebUI suporta múltiplos idiomas na interface?
Sim, a interface tem tradução comunitária para várias línguas, incluindo português, selecionável nas definições de conta de cada utilizador.

Que alternativa devo escolher se só preciso de uma app de desktop simples?
Para um único utilizador sem necessidade de gestão de equipa, o LM Studio ou o Jan.ai oferecem uma experiência mais direta, sem a complexidade de gerir contentores Docker.

O Open WebUI ajuda a cumprir o RGPD?
Ajuda a resolver a parte de localização dos dados, porque tudo fica armazenado no servidor escolhido pela organização, o que facilita provar onde os dados residem. Ainda assim, o cumprimento do RGPD depende de outras medidas que a ferramenta não garante sozinha, como políticas de retenção de conversas, contratos com fornecedores de modelos externos usados nas conexões e um registo formal de tratamento de dados pessoais.

Open WebUI: ChatGPT Privado em 13 Passos, 60 Min [2026]