Como hospedar Ollama em VPS com segurança

O que você está construindo

Um modelo de linguagem de pesos abertos rodando em um servidor próprio, acessível via API HTTP e, opcionalmente, por uma página de chat no navegador. O Ollama é o componente que baixa o modelo, carrega na memória e atende requisições na http://127.0.0.1:11434. A instalação consiste em apenas um comando. A parte complexa reside em outros fatores: escolher um modelo que o seu VPS consiga manter na RAM e não publicar acidentalmente um servidor de inferência sem autenticação para toda a internet.

Dois avisos importantes. Um VPS apenas com CPU executa modelos pequenos de forma lenta, e a API não possui autenticação nativa. Ambos os pontos são detalhados abaixo, pois são os principais pontos de erro.

Verificação de realidade de dimensionamento, em números reais

O consumo de memória de um modelo é aproximadamente o tamanho do seu arquivo, somado a cerca de um gigabyte de overhead de runtime, mais um adicional para a janela de contexto. Os modelos padrão do Ollama são quantizados em 4-bit (etiquetados como Q4), o que consome cerca de meio gigabyte de RAM para cada bilhão de parâmetros. O cálculo é simples e define tudo.

Um modelo 3B como o llama3.2:3b tem um download de ~2 GB e requer cerca de 4 GB de RAM livre para rodar. Um modelo 7B ou 8B como o mistral:7b ou llama3.1:8b ocupa ~5 GB em disco e requer cerca de 8 GB de RAM, sendo 16 GB para maior conforto. Um modelo 13B ou 14B requer aproximadamente 16 GB. Qualquer modelo na faixa de 30B a 70B exige uma máquina com muita RAM ou, realisticamente, uma GPU — em um VPS com CPU, o modelo não caberá ou responderá tão lentamente que será inútil.

Agora, a velocidade, pois esta é a parte que as pessoas subestimam. A inferência em CPU é limitada pela largura de banda da memória, não pela velocidade de clock, e um VPS com vCPU compartilhada possui largura de banda modesta. Espere de um dígito a pouco mais de dez tokens por segundo: um modelo 7-8B Q4 pode atingir de 4 a 10 tokens por segundo, e um modelo 3B de 10 a 25. Uma GPU é aproximadamente uma ordem de magnitude mais rápida. Estes são valores aproximados de propósito — o procedimento correto é medir seu próprio hardware, conforme mostrado no passo de execução abaixo. Confie no seu eval rate, não em números de artigos, inclusive este.

Conclusão prática: modelos quantizados pequenos em CPU são genuinamente úteis para rascunhos, resumos e classificação, se você aceitar o ritmo. Para qualquer coisa maior ou mais rápida, reserve orçamento para uma instância com GPU.

Para comparar um modelo específico contra um hardware específico, estime o consumo de memória aqui:

Instalar Ollama

Existem duas formas limpas. O script oficial é a mais simples para um VPS limpo:

curl -fsSL https://ollama.com/install.sh | sh

Isso cria um usuário de sistema chamado ollama, instala o binário em /usr/local/bin/ollama e registra um serviço systemd chamado ollama.service que inicia no boot e vincula 127.0.0.1:11434. Confirme se está funcionando:

systemctl status ollama
ollama --version

Se você já utiliza Docker, use o container:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Observe o prefixo 127.0.0.1: no mapeamento de porta. Isso vincula a porta apenas ao localhost. Usar -p 11434:11434 em vez disso publica a porta em todas as interfaces, que é o erro mencionado na seção de segurança. Escolha apenas um método de instalação; não execute o script e o container ao mesmo tempo, caso contrário dois processos disputarão a porta.

Baixe e execute seu primeiro modelo

ollama pull llama3.2:3b
ollama run llama3.2:3b

O pull baixa as camadas do modelo para o disco (cerca de 2 GB para este). O run as carrega na memória e abre um prompt >>>. Digite uma pergunta. O primeiro token pode demorar alguns segundos enquanto os pesos são carregados do disco para a RAM; depois, a resposta é transmitida. Digite /bye para sair do chat; o Ollama continua rodando em segundo plano.

Veja o que está carregado e como o modelo se comporta:

ollama ps

A coluna PROCESSOR indica o uso real. 100% CPU significa que nenhuma GPU está sendo utilizada, o que causa a lentidão. Meça a velocidade real usando a flag verbose:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

A linha eval rate impressa ao final indica os tokens por segundo no seu hardware. Use esse número para seu planejamento.

Onde os modelos ficam armazenados e quanto disco comprar

Instalados pelo script e executados como serviço, os modelos ficam no home do usuário ollama:

sudo du -sh /usr/share/ollama/.ollama/models

Ao rodar interativamente com seu próprio usuário, eles ficam em ~/.ollama/models. No container, eles ficam no volume nomeado ollama. Isso é importante porque pesos quantizados ocupam espaço rapidamente: um modelo de 3B tem ~2 GB, um de 7-8B tem ~5 GB e um de 14B tem ~9 GB. Se você baixar quatro modelos para comparação, terá gasto 20 GB sem perceber. Calcule o tamanho do disco com base nos modelos que pretende manter e delete o restante com ollama rm <model>.

Execute como um serviço controlado por você

O script de instalação já registrou o ollama.service, portanto ele reinicia no boot sem necessidade de intervenção. A configuração que vale a pena alterar é o tempo de permanência do modelo na memória e, em algumas configurações, o bind address — ambos devem ser inseridos em um drop-in do systemd para que uma atualização do Ollama não os sobrescreva:

sudo systemctl edit ollama.service

Adicione isto sob o cabeçalho [Service] exibido pelo editor:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE define quanto tempo um modelo permanece na memória após a última requisição (padrão de 5 minutos). Aumente este valor em máquinas com consultas constantes para evitar o recarregamento dos weights a cada chamada; defina como 0 em máquinas com pouca memória para liberar RAM assim que uma requisição terminar. O systemctl edit recarrega os arquivos da unit para você, então reinicie para aplicar a alteração:

sudo systemctl restart ollama

O ponto de segurança mais importante

Por padrão, o Ollama faz o bind em 127.0.0.1:11434, então apenas processos no próprio VPS podem acessá-lo. Esse padrão está correto. Mantenha-o.

A API não possui autenticação. Nenhuma. Não há chave de API, login, limite de taxa ou lista de permissões. Qualquer pessoa que alcance a porta 11434 pode executar qualquer modelo que você baixou, baixar novos modelos, deletá-los e manter sua CPU ou GPU em carga máxima indefinidamente. Scanners como o Shodan indexam milhares de instâncias do Ollama abertas; uma instância exposta é encontrada e abusada em poucas horas.

Portanto, aqui está o único erro que você nunca deve cometer: não defina OLLAMA_HOST=0.0.0.0 e não abra a porta 11434 no seu firewall. Isso publica um servidor de inferência sem autenticação para toda a internet. Nenhuma configuração torna o acesso direto via 11434 em 0.0.0.0 seguro, pois não há o que configurar no Ollama — a autenticação simplesmente não existe.

Existem três formas seguras de acessar o modelo de fora da máquina:

• Mantenha-o local. Se o único chamador for outro programa no mesmo VPS — um script cron, um bot ou um servidor MCP conectando suas ferramentas ao modelo — mantenha o bind em 127.0.0.1 e faça esse programa chamar http://127.0.0.1:11434. Nada fica exposto e nada mais é necessário.
• Acesse via túnel privado. Coloque o VPS em uma VPN WireGuard hospedada por você, defina OLLAMA_HOST para o endereço do túnel (por exemplo 10.8.0.1, não 0.0.0.0), e apenas peers da VPN poderão conectar. A internet pública continuará sem ver nada na porta 11434.
• Use um reverse proxy com autenticação na frente. Termine o TLS e exija uma senha ou token no nginx, Traefik ou Caddy, e então faça o proxy para 127.0.0.1:11434. O Ollama mantém seu bind em localhost; o proxy é o único elemento escutando na porta pública. Este é o mesmo modelo de colocar um certificado Let's Encrypt no nginx na frente de qualquer serviço local.

A opção de reverse proxy é exatamente o que a interface de chat oferece a seguir, com um login real integrado.

Adicione uma interface de chat com Open WebUI, via TLS

O Open WebUI é uma interface de chat self-hosted. Execute-o via Docker e aponte para o Ollama local:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

A flag --network=host é o detalhe importante em uma VPS Linux. Ela coloca o container no namespace de rede do host, então o 127.0.0.1 dentro do container é o próprio loopback do host e o container alcança o Ollama em 127.0.0.1:11434 sem que o Ollama precise escutar em outra interface. A configuração de bridge-network vista em outros lugares — --add-host=host.docker.internal:host-gateway com OLLAMA_BASE_URL=http://host.docker.internal:11434 — não funciona aqui: esse nome resolve para o gateway da bridge do Docker, e um serviço vinculado ao 127.0.0.1 no host não é alcançável através da bridge, fazendo com que o Open WebUI apenas exiba um erro de conexão com o Ollama.

A desvantagem do host networking é que o Open WebUI passa a escutar na porta 8080 do host em todas as interfaces; qualquer mapeamento de -p é descartado, e o Docker exibirá um aviso sobre isso. Portanto, feche a 8080 tanto no firewall do host quanto no do provedor e deixe o reverse proxy TLS como a única porta pública. No primeiro acesso, o Open WebUI solicitará a criação de uma conta de administrador — essa conta é sua camada de autenticação, então escolha uma senha forte.

Para abrir o chat do seu laptop via HTTPS, coloque um reverse proxy TLS à frente do 127.0.0.1:8080. Se você já roteia vários apps Docker na máquina, Traefik com TLS automático para vários apps é a opção mais limpa: um bloco de labels emite o certificado e roteia chat.example.com para o Open WebUI. A regra da seção de segurança permanece válida — o proxy detém a porta pública e o login, enquanto o Ollama permanece no localhost e a 8080 do próprio Open WebUI permanece protegida pelo firewall.

Use o endpoint compatível com OpenAI no seu código

O Ollama utiliza um subconjunto da API de chat da OpenAI em /v1, portanto a maioria das bibliotecas cliente da OpenAI funciona após alterar duas coisas: a base URL e uma chave temporária.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

A api_key é exigida pela biblioteca cliente, mas é ignorada pelo Ollama, então qualquer string funciona. model deve ser um nome que você já tenha baixado; um nome desconhecido retorna model "x" not found, try pulling it first. Uma chamada curl simples segue a mesma lógica:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

Esta é também a forma de integrar o modelo em ferramentas de agentes e editores. Se você já desenvolve no servidor, um modelo local pode dar suporte a scripts e plugins junto com o Claude Code rodando no VPS dentro do tmux, mantendo o rascunho privado e de baixo custo fora de uma API paga, enquanto o processamento pesado de raciocínio permanece em um modelo hospedado.

Modos de falha, com as strings exatas que você verá

O processo é "Killed" durante a geração. Você inicia um modelo grande e o terminal imprime Killed, ou o log do servidor mostra llama runner process has terminated: signal: killed. O OOM killer do Linux interrompeu o processo porque o modelo exigia mais RAM do que o servidor possui. Confirme a causa com sudo dmesg | grep -i oom, onde você verá uma linha como Out of memory: Killed process ... (ollama). A solução é um modelo menor ou com quantização mais agressiva — llama3.2:3b em vez de um 13B — ou adicionar swap para que uma carga que excede a RAM física sobreviva lentamente em vez de falhar. O swap transforma um crash instantâneo em uma resposta lenta; ele não torna um modelo 70B prático em 4 GB.

"Error: model requires more system memory". O Ollama recusa-se a iniciar o modelo e imprime Error: model requires more system memory (X GiB) than is available (Y GiB). Esta é a versão amigável do crash acima: o Ollama calculou a necessidade e parou antes que o OOM killer o fizesse. Ele até fornece os dois valores. Escolha um modelo cujo requisito seja menor que sua RAM livre (verifique com free -h), reduza o context length ou mude para um VPS maior. Nenhum flag fará o modelo caber — a memória é um recurso físico.

O primeiro token demora muito, depois funciona normalmente. Um modelo "cold" não imprime nada por cinco a trinta segundos e depois faz o streaming normalmente. Essa pausa é o carregamento dos weights do disco para a RAM pela primeira vez; armazenamento lento piora o cenário. Uma vez carregado, o modelo permanece residente durante OLLAMA_KEEP_ALIVE, então o segundo prompt responde instantaneamente. Aumente esse valor se os atrasos incomodarem e use ollama ps para verificar se um modelo está carregado no momento.

Tudo está simplesmente lento. Dez tokens por segundo ou menos, sem nenhum erro. Isso é a inferência via CPU operando normalmente. ollama ps mostra 100% CPU, o que significa que não há GPU. Isso não é um bug e nenhuma configuração resolve, pois o limite é a largura de banda da memória, não uma má configuração. Use um modelo menor, aceite a velocidade ou mude para uma instância com GPU — e meça sua taxa real com --verbose antes de decidir que algo está quebrado.

Connection refused de outra máquina. Do seu laptop, você recebe curl: (7) Failed to connect to <ip> port 11434: Connection refused. Isso funciona conforme o esperado: o Ollama faz bind apenas em localhost. Não tente "corrigir" isso fazendo bind em 0.0.0.0, que é exatamente o erro de exposição mencionado acima. Acesse o modelo via VPN ou através de um proxy com autenticação.

Você expôs a porta 11434 para a internet. Se você configurou OLLAMA_HOST=0.0.0.0, abriu o firewall e agora vê pulls de modelos que você nunca iniciou ou o CPU em 100% por clientes desconhecidos, você foi detectado e explorado. Este é o erro principal, não um caso isolado. Faça o rebind para 127.0.0.1 ou para o endereço da VPN, feche a porta 11434 no firewall e coloque autenticação na frente. Considere que qualquer coisa acessível nesse endereço enquanto estivesse aberto foi consultada por estranhos.

Backups e upgrades

Há pouco estado para ser perdido. Os modelos podem ser baixados novamente, portanto, os únicos itens que valem o backup são o volume de dados do Open WebUI — contas, histórico de chat, configurações — e qualquer drop-in do systemd que você tenha criado. Faça o backup do volume usando um container temporário:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Atualize o Ollama executando o script de instalação novamente; atualize o Open WebUI com docker pull ghcr.io/open-webui/open-webui:main seguido da recriação do container. Não congele versões a longo prazo: tanto a qualidade dos modelos quanto o runtime evoluem rápido, então leia as notas de lançamento e realize novos benchmarks em sua própria máquina em vez de confiar nos números do último trimestre.

FAQ

É possível rodar um LLM em um VPS apenas com CPU?

Sim, com limitações. Modelos quantizados pequenos entre 3B e 8B rodam em CPU e são úteis para rascunhos, resumos e classificação — porém de forma lenta, com uma taxa de um a dezenas de tokens por segundo em uma vCPU compartilhada. Modelos de 13B para cima são extremamente lentos ou não caberão na RAM. Para velocidade real ou modelos maiores, você precisa de uma instância com GPU.

Quanta RAM cada modelo exige?

Uma regra aproximada para modelos quantizados padrão de 4-bit: cerca de 0.5 GB de RAM por bilhão de parâmetros para os pesos, somado a aproximadamente 1 GB de overhead e um pouco mais para o contexto. Assim, um modelo 3B exige cerca de 4 GB livres, um modelo 7-8B cerca de 8 GB, e um modelo 14B cerca de 16 GB. Verifique sua margem de memória com free -h e deixe espaço para o sistema operacional e outros processos no servidor.

A API do Ollama é autenticada?

Não. O Ollama não possui autenticação nativa, chave de API ou limite de taxa (rate limit) — qualquer usuário que alcance a porta 11434 tem controle total. É por isso que ele faz o bind em 127.0.0.1 por padrão e por que você nunca deve expor a porta 11434 na 0.0.0.0 para a internet. Acesse-a localmente, via VPN privada ou através de um reverse proxy que adicione login.

Como adicionar uma interface de chat web?

Execute o Open WebUI no Docker com --network=host para que ele compartilhe o loopback do host e alcance o Ollama nativo em http://127.0.0.1:11434; em seguida, utilize um reverse proxy TLS antes da porta 8080 para acesso via seu laptop. Mantenha a 8080 fechada no firewall para que o proxy seja a única porta pública. O próprio sistema de conta admin do Open WebUI fornece o login, e você define a senha no primeiro acesso.

Como chamá-lo através da minha própria aplicação?

Use o endpoint compatível com OpenAI em http://127.0.0.1:11434/v1. Aponte qualquer SDK da OpenAI para essa URL base, passe qualquer string como chave de API (pois ela é ignorada) e defina model com o nome do modelo que você baixou. Códigos existentes da OpenAI geralmente rodam sem alterações, exceto pela URL base e pela chave.