Como rodar Ollama e Open WebUI com Docker em VPS GPU sem expor seus dados

Para rodar Ollama e Open WebUI em uma VPS GPU sem expor a API do modelo, deixe apenas o proxy HTTPS acessível. O Ollama fica sem porta publicada. O Open WebUI escuta somente no loopback. Isso reduz a superfície de ataque, mas não elimina custo, backup, permissões ou responsabilidade operacional.

Ollama em VPS GPU resolve um problema real: executar modelos e manter conversas sob uma infraestrutura escolhida por você. Não resolve outro problema por mágica: custo. GPU ligada, domínio, certificado, atualizações, logs, volumes e incidentes continuam na conta.

A ideia central deste tutorial é privacidade por superfície mínima. Em vez de chamar uma instalação de “privada” só porque usa software self-hosted, reduza o que fica exposto: uma porta pública para HTTPS, uma interface atrás do proxy e a API do modelo somente na rede Docker.

Este guia serve para um endpoint privado de uso individual, time pequeno ou automação interna. Ele não promete latência, tokens por segundo ou economia. Esses resultados dependem do modelo, da quantização, do contexto, da concorrência e da GPU escolhida.

Antes do comando: LLM local não é IA grátis

Trocar uma API hospedada por Ollama muda a forma de pagar. A API cobra pelo uso. Uma GPU própria ou alugada cobra pela disponibilidade, mesmo quando ninguém envia prompt.

A página da Servla consultada em 3 de setembro de 2026 listava VPS GPU com 3 GB, 6 GB, 8 GB e 12 GB de VRAM por R$360, R$552, R$712 e R$1.032 mensais. Preço e disponibilidade podem mudar. Já a página de preços da RunPod mostrava RTX 4090 a partir de US$0,34 por hora e H100 a partir de US$1,99 por hora.

Se uma GPU por hora ficar ligada durante 730 horas, a conta estimada vira US$248,20 para a RTX 4090 e US$1.452,70 para a H100. Essa multiplicação não inclui armazenamento, tráfego, câmbio nem IOF. Ela só revela por que “barato por hora” não significa barato para uma instância sempre disponível.

A Hostinger, por exemplo, listava VPS KVM CPU a partir de R$29,99 mensais em promoção e R$59,99 na renovação para o KVM 1, na coleta desta pesquisa. Esses planos exibiam vCPU, RAM, NVMe e banda, não GPU dedicada. Portanto, são úteis para n8n, proxy ou serviços auxiliares. Não são substitutos de VRAM para inferência de LLM em produção.

Se você precisa de uma GPU persistente no Brasil, compare o cenário com calma na página do Runzos: ver opções de VPS/GPU para LLM local no Runzos. A decisão depende do padrão de uso, não do hype em torno de modelos locais.

Arquitetura privada mínima: o que fica público e o que fica interno

A arquitetura segura não começa no docker compose. Começa em decidir o que não deve aparecer na internet.

Neste tutorial, o navegador acessa o domínio por HTTPS na porta 443. Um proxy reverso encaminha a requisição para 127.0.0.1:3000. O Open WebUI conversa com o Ollama pelo nome do serviço, http://ollama:11434, na rede Docker interna. A porta 11434 não é publicada. A porta 3000 também não fica aberta para a internet.

A documentação de hardening do Open WebUI recomenda VPN, proxy zero-trust ou proxy reverso com autenticação e lista de IPs para ambientes sensíveis. Ela também orienta colocar limitação de taxa e proteção contra brute force na camada de proxy ou rede. Leia o guia de hardening do Open WebUI antes de transformar a instância em serviço compartilhado.

internal: true na rede Docker ajuda a impedir acesso externo direto àquela rede. Não substitui firewall, TLS, controle de acesso nem revisão de permissões. HTTPS também não decide quem pode entrar. Ele protege o transporte; a autorização precisa existir na borda e na aplicação.

Evite habilitar ferramentas, funções, MCP ou passthrough por conveniência em uma instalação compartilhada. A documentação informa que o passthrough de API OpenAI fica desabilitado por padrão, pois um usuário autenticado poderia alcançar endpoints upstream usando a credencial configurada pelo administrador.

Escolha a infraestrutura antes de subir os containers

GPU não é requisito automático para experimentar Ollama. Ela é uma decisão de capacidade. A documentação do Ollama informa suporte a NVIDIA com compute capability 5.0 ou maior, driver 550 ou posterior e driver 570 ou posterior para GPUs entre capability 5.0 e 6.2.

Não existe uma resposta universal para “quantos GB de VRAM eu preciso?”. O encaixe depende da família do modelo, da quantização, do tamanho do contexto, da concorrência e de quanto trabalho vai para CPU. A documentação do Ollama aponta uma janela de contexto padrão de 4.096 tokens, alterável por OLLAMA_CONTEXT_LENGTH ou num_ctx por API ou modelo. Mais contexto é uma escolha que precisa entrar na sua conta de capacidade.

Use esta triagem antes de contratar:

vLLM pode servir quando o caso exige endpoint compatível com API OpenAI e maior foco em serving. Não é uma aceleração mágica para uma instalação Ollama. A qualidade e o desempenho continuam dependentes do hardware e do modelo testado.

Para GPU por hora, a rota comercial do Runzos para RunPod concentra a oferta sem vazar o clique de afiliado: avaliar GPU cloud por hora no Runzos.

Pré-requisitos: driver NVIDIA e Docker

A GPU precisa funcionar no host antes de entrar no Docker. O NVIDIA Container Toolkit exige driver NVIDIA no host. A recomendação da NVIDIA é instalar o driver pelo gerenciador de pacotes da distribuição.

Comece com dois testes. O primeiro confirma se o host enxerga a GPU. O segundo confirma se um container consegue usar a GPU.

nvidia-smi

docker run --rm --gpus all nvidia/cuda nvidia-smi

Se algum teste falhar, pare aqui. Não avance para o Open WebUI tentando compensar um driver ausente com variáveis do Compose. Consulte a documentação Docker do Ollama e o guia de instalação do NVIDIA Container Toolkit para conferir o ambiente.

Crie um diretório dedicado e um arquivo .env. Não versione o segredo.

mkdir -p ~/ollama-open-webui && cd ~/ollama-open-webui
openssl rand -base64 32

FQDN=llm.seudominio.com
WEBUI_SECRET_KEY=cole_a_saida_de_openssl_rand_base64_32

Depois, restrinja o arquivo:

chmod 600 .env

No firewall, libere SSH com chave. Se houver proxy público, libere 80 e 443 conforme sua estratégia de TLS. Não libere 11434 nem 3000.

Suba Ollama e Open WebUI sem publicar a API

Salve o conteúdo abaixo como compose.yaml. Ele usa volumes nomeados para os modelos do Ollama e para os dados persistentes do Open WebUI. A imagem do Open WebUI e as variáveis seguem o compose estruturalmente validado na pesquisa.

Limite de reprodução desta versão: o Runzos não executou este Compose em uma VPS GPU na validação de 3 de setembro de 2026. Portanto, o arquivo abaixo é um exemplo técnico a validar no seu servidor, não uma configuração reproduzida pelo Runzos. As tags ollama/ollama:latest e ghcr.io/open-webui/open-webui:main são mutáveis. Elas podem apontar para imagens diferentes depois dessa data. Só fixe uma versão ou digest depois de testar essa imagem específica; até lá, confira a documentação e rode a sequência de validação antes de usar o stack com dados de trabalho.

services:
ollama:
image: ollama/ollama:latest
restart: unless-stopped
volumes:
- ollama:/root/.ollama
networks: [llm_private]
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]

open-webui:
image: ghcr.io/open-webui/open-webui:main
restart: unless-stopped
depends_on: [ollama]
environment:
OLLAMA_BASE_URL: http://ollama:11434
WEBUI_SECRET_KEY: ${WEBUI_SECRET_KEY:?defina_no_arquivo_env}
WEBUI_URL: https://${FQDN:?defina_o_dominio_no_arquivo_env}
ENABLE_OPENAI_API_PASSTHROUGH: "false"
ENABLE_ADMIN_EXPORT: "false"
volumes:
- open_webui:/app/backend/data
ports:
- "127.0.0.1:3000:8080"
networks: [llm_private]

networks:
llm_private:
internal: true
volumes:
ollama:
open_webui:

O ponto importante é a ausência de ports: no serviço ollama. A porta 11434 permanece dentro da rede dos containers. Já o Open WebUI recebe um mapeamento explícito para o loopback: 127.0.0.1:3000:8080.

A variável OLLAMA_BASE_URL faz a interface encontrar o backend pelo nome do serviço Docker. A referência oficial de configuração de ambiente do Open WebUI documenta essa variável.

Valide a sintaxe e suba a stack:

docker compose config
docker compose up -d
docker compose ps

Baixe deliberadamente o modelo que pretende usar. A documentação do Ollama usa o comando abaixo com llama3.2; troque o nome apenas depois de avaliar seu caso.

docker compose exec ollama ollama run llama3.2
docker compose exec ollama ollama ps

ollama ps mostra se um modelo foi carregado inteiramente em GPU, inteiramente em CPU ou dividido entre ambos. Esse é o teste que substitui suposição sobre VRAM. Não publique números de throughput sem medir o seu ambiente. Neste artigo, o comando é uma etapa de validação recomendada, não uma saída obtida pelo Runzos.

Coloque domínio, HTTPS e acesso na borda

Para um domínio público, aponte o DNS ao IP da VPS e faça o proxy terminar o TLS. Um Caddyfile mínimo pode ser:

llm.seudominio.com {
reverse_proxy 127.0.0.1:3000
}

O Caddy expõe a borda; não o Ollama. Depois de configurar o proxy, abra https://FQDN. Segundo a documentação de hardening do Open WebUI, o primeiro usuário torna-se administrador e o signup é desabilitado automaticamente.

Para acesso individual, VPN, Tailscale ou um proxy zero-trust podem reduzir ainda mais a exposição. Em ambientes com mais de uma pessoa, complemente o login da aplicação com uma política de rede, autenticação no proxy ou allowlist de IP, conforme o risco.

Valide, monitore e faça backup

Deploy que sobe não é deploy validado. Faça uma checagem externa depois de configurar DNS, proxy e firewall. Os comandos abaixo são exemplos não executados pelo Runzos em VPS GPU nesta versão:

curl -I https://llm.seudominio.com
curl http://SEU_IP:11434
curl http://SEU_IP:3000

O primeiro comando deve responder pelo domínio HTTPS. Os dois últimos não devem oferecer acesso público. Execute-os de uma rede externa à VPS para testar a borda real, não apenas o loopback local. Registre a data, a versão ou digest das imagens, o modelo e a GPU usada. Esse registro é o que permite fixar imagens testadas sem confundir tags mutáveis com uma versão validada.

A persistência mora nos dois volumes nomeados. O volume ollama guarda os modelos. O volume open_webui guarda os dados persistentes da aplicação. O backup precisa considerar retenção, criptografia e teste de restauração. Copiar dados sem conseguir restaurá-los não fecha o ciclo operacional. Esta versão não inclui uma restauração executada pelo Runzos. Antes de usar o ambiente, faça backup, restaure-o em um volume ou ambiente de teste e registre se o Open WebUI volta a acessar seus dados e se o Ollama encontra os modelos esperados.

Use esta lista antes de colocar dados de trabalho na instância:

1. Confirmar que não há -p 11434:11434 no Compose.
2. Confirmar que o Open WebUI usa 127.0.0.1:3000:8080.
3. Guardar WEBUI_SECRET_KEY fora do Git e limitar o arquivo .env.
4. Revisar firewall, proxy e TLS antes de liberar acesso.
5. Restringir acesso com VPN, zero-trust, autenticação ou allowlist conforme o risco.
6. Conferir o processador do modelo com ollama ps.
7. Revisar extensões, funções e passthrough antes de habilitá-los.
8. Fazer backup dos volumes e testar uma restauração.
9. Registrar moeda, horas ligadas, storage e câmbio na planilha de custo.
10. Atualizar imagens e dependências com uma rotina planejada, não no meio de um incidente.

Quando Ollama em VPS não é a melhor escolha

Use API hospedada quando a carga for imprevisível, quando precisar de vários modelos proprietários ou quando ninguém puder operar a infraestrutura. O custo por token pode ser menor que manter GPU ociosa. Nesse cenário, “ter controle” pode ser apenas uma forma cara de assumir trabalho operacional.

Use desktop com LM Studio quando o objetivo é experimentar localmente. Você evita domínio, TLS, proxy e operação remota. Use vLLM com GPU quando a necessidade for serving multiusuário e API compatível com OpenAI, mas trate a migração como uma nova arquitetura.

Uma VPS CPU barata pode continuar na composição. Ela pode hospedar proxy, automação, banco, monitoramento ou outros serviços auxiliares. Para essa camada, consulte a oferta de VPS para automações no Runzos ou a alternativa de VPS NVMe no Runzos. Não confunda essa função com uma GPU de inferência.

FAQ: Ollama e Open WebUI em VPS GPU

Preciso de GPU para rodar Ollama na VPS?

Não necessariamente. GPU é uma decisão de capacidade, não uma exigência para cada experimento. Antes de escolher VRAM, defina modelo, quantização, contexto e número de usuários. A documentação do Ollama permite verificar depois se o modelo ficou em GPU, CPU ou em ambos com ollama ps. Sem esse teste, prometer que um modelo específico “cabe” em determinada GPU seria suposição.

Posso deixar a porta 11434 do Ollama aberta na internet?

Não é o baseline deste tutorial. O Compose deixa o Ollama sem ports:, acessível apenas pela rede Docker interna. O risco não está em dizer que o Ollama abre a internet por padrão. Ele aparece quando um deploy publica a porta do host. Exponha somente a borda necessária e mantenha o serviço do modelo atrás da interface e do proxy.

Como o Open WebUI encontra o Ollama no Docker?

Os dois serviços usam a mesma rede Docker chamada llm_private. A variável OLLAMA_BASE_URL aponta para http://ollama:11434, usando o nome do serviço. Isso evita depender de IP fixo de container e mantém o tráfego entre a interface e o modelo na rede interna definida pelo Compose.

O que preciso salvar em backup?

Salve e teste a restauração dos volumes ollama e open_webui. O primeiro contém os modelos baixados. O segundo mantém dados persistentes do Open WebUI. A operação também precisa decidir onde o backup fica, por quanto tempo será retido e como será protegido. Backup criado, mas nunca restaurado, não é garantia operacional.

Quando RunPod sai mais barato que uma VPS GPU mensal?

Quando você consegue desligar a GPU fora dos períodos de uso, o pagamento por hora pode fazer sentido. A referência de preço consultada mostrava RTX 4090 a partir de US$0,34 por hora e H100 a partir de US$1,99 por hora. Multiplique pelas horas efetivamente ligadas e some storage, tráfego, câmbio e IOF. Se a GPU ficar disponível o mês inteiro, compare o resultado com uma mensalidade.

Quando uma API hospedada ainda é melhor?

Uma API hospedada costuma ser uma escolha mais simples para carga imprevisível, modelos proprietários e equipes sem rotina de infraestrutura. Ela reduz a operação de GPU, Docker, atualizações, certificados e incidentes. Avalie o custo real de manter capacidade ociosa antes de concluir que self-hosted é mais econômico.

A decisão prática: controle exige operação

Ollama e Open WebUI podem formar um endpoint útil para dados e automações internas. Mas privacidade não é uma etiqueta aplicada ao container. Ela depende de reduzir portas, controlar credenciais, proteger a borda e tratar backups como parte do sistema.

A leitura do Runzos é objetiva: use VPS GPU quando o ambiente persistente, o padrão de uso e a necessidade de controle justificarem a operação. Para uso irregular, compare GPU por hora. Para experimentação, mantenha o modelo no desktop. E, quando a infraestrutura virar distração, escolha uma API hospedada sem culpa.