Tutoriais de VPS
Criar uma base de conhecimento privada com AnythingLLM em VPS (2026): Docker, OpenAI/Ollama, perguntas e respostas sobre documentos com RAG e guia de implantação com HTTPS
Este tutorial explica como auto-hospedar o AnythingLLM em um VPS e criar uma base de conhecimento de IA privada que permite enviar PDFs, Markdown e conteúdo web e responder perguntas sobre documentos com RAG. Abrange a escolha da configuração do VPS, a implantação com Docker, o armazenamento persistente, a conexão dos modelos OpenAI e Ollama, HTTPS com Caddy, as permissões dos workspaces, backup e atualização, o reforço de segurança e as falhas de conexão mais comuns.
Ultimamente tenho visto muita gente querendo montar "perguntas e respostas com IA sobre a base de conhecimento interna da empresa", mas escolhe a ferramenta errada logo no primeiro passo.
Algumas pessoas simplesmente jogam os PDFs no ChatGPT. É realmente prático, mas contratos, dados de clientes e SOPs internos precisam ser enviados a uma plataforma de terceiros. Outras implantam o Dify, que é bem completo, mas se só querem que algumas pessoas consultem documentos, o fluxo parece pesado. Outras ainda instalam o Open WebUI, que tem uma boa experiência de chat, mas na parte de base de conhecimento documental não é necessariamente a entrada mais prática.
Se a sua necessidade é bem específica:
Enviar um lote de documentos e depois deixar a IA responder perguntas com base nesses materiais.
O AnythingLLM se encaixa bem.
Ele não é apenas uma casca de chat, nem uma plataforma complexa de desenvolvimento de aplicações de IA. É mais como um "backend privado de perguntas e respostas sobre documentos": você cria Workspaces, envia PDFs, Markdown, TXT e conteúdo web, configura modelos e recuperação vetorial, e então pode conversar em torno desses materiais.
Este artigo aborda a auto-hospedagem em VPS: como implantar, qual tamanho de VPS usar, como escolher entre OpenAI e Ollama, quais dados você precisa obrigatoriamente fazer backup e quais armadilhas evitar.
Não instale só porque uma ferramenta de IA está em alta.
Eu avaliaria assim:
| Necessidade | Adequado para o AnythingLLM | Ferramenta mais adequada |
|---|---|---|
| Perguntas e respostas sobre documentos privados | Adequado | AnythingLLM |
| Base de conhecimento compartilhada entre várias pessoas | Adequado | AnythingLLM Docker |
| Fluxos de trabalho de IA complexos | Razoável | Dify / n8n |
| Apenas conversar com modelos locais | Razoável | Open WebUI |
| Unificar várias APIs de modelos | Não adequado | One-API / New-API / LiteLLM |
| Atendimento ao cliente incorporado no site | Possível | AnythingLLM Chat Widget |
Em uma frase: os pontos fortes do AnythingLLM são documentos, Workspaces, RAG e acesso em equipe.
Se você só quer pedir a um modelo "me ajude a escrever um texto", o Open WebUI é mais direto. Se você quer orquestrar uma aplicação de IA inteira, o Dify é mais uma plataforma. Se você quer colocar materiais da empresa, documentação de produtos, tutoriais e modelos de contrato e consultá-los, o AnythingLLM atende melhor à necessidade.
Aqui há dois casos.
Essa opção economiza mais recursos do VPS. A inferência do modelo não roda no seu VPS; o VPS só cuida de:
- Backend web do AnythingLLM
- Upload e divisão de documentos
- Indexação vetorial
- Login de usuários e workspaces
- Comunicação com APIs de LLM externas
Configuração recomendada:
| Uso | Configuração do VPS |
|---|---|
| Teste pessoal | 1 núcleo / 2GB / 20GB SSD |
| Equipe pequena de 2-5 pessoas | 2 núcleos / 4GB / 40GB SSD |
| Muitos documentos, vários usuários | 4 núcleos / 8GB / 80GB SSD |
Se você só se conecta à API da OpenAI, não precisa de GPU.
Muita gente, ao ouvir "ferramenta de IA", já procura um VPS com GPU, mas isso não é necessário. Quando você usa modelos na nuvem, o que realmente custa dinheiro são as chamadas de API, não a capacidade de processamento do VPS.
Isso é completamente diferente.
O Ollama com um modelo pequeno de 7B já consome bastante memória. Também funciona na CPU, mas não será rápido; sem GPU, a velocidade de geração pode ser tão lenta que você vai suspeitar que o serviço quebrou.
Minha recomendação:
| Abordagem de modelo | Configuração recomendada |
|---|---|
| Apenas AnythingLLM + modelos na nuvem | 2 núcleos 4GB já é confortável o suficiente |
| AnythingLLM + modelo pequeno do Ollama | A partir de 4 núcleos 16GB |
| Querer rodar modelos locais maiores | Servidor com GPU ou máquina local com placa de vídeo |
Então não force um VPS pequeno de 1C1G a rodar modelos locais grandes. Conseguir iniciar não significa que é utilizável; conseguir responder não significa que a experiência é boa.
Este artigo usa como exemplo um VPS com Ubuntu / Debian.
Primeiro faça login via SSH:
ssh root@your_server_ip
Atualize o sistema:
apt update && apt upgrade -y
Instale as ferramentas básicas:
apt install -y ca-certificates curl gnupg ufw
Verifique os recursos do sistema:
free -h
df -h
O AnythingLLM escuta por padrão na porta 3001. Primeiro confirme que ela não está ocupada:
ss -tlnp | grep 3001
Se não houver saída, a porta está livre.
Se o VPS ainda não tem Docker, você pode instalá-lo pelo repositório oficial.
Adicione a chave GPG do Docker:
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg
Adicione o repositório do Docker:
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" > /etc/apt/sources.list.d/docker.list
Instale o Docker:
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Confirme a versão:
docker --version
docker compose version
A abordagem oficial de implantação com Docker é bem direta: prepare um diretório persistente e monte-o no /app/server/storage do contêiner.
Recomendo colocar os dados em /opt/anythingllm:
mkdir -p /opt/anythingllm
cd /opt/anythingllm
touch .env
Execute o contêiner:
docker run -d \
--name anythingllm \
--restart unless-stopped \
-p 3001:3001 \
--cap-add SYS_ADMIN \
-v /opt/anythingllm:/app/server/storage \
-v /opt/anythingllm/.env:/app/server/.env \
-e STORAGE_DIR="/app/server/storage" \
mintplexlabs/anythingllm:latest
Verifique o status do contêiner:
docker ps --filter "name=anythingllm"
Veja os logs:
docker logs anythingllm --tail=100
Acesse pelo navegador:
http://your_server_ip:3001
No primeiro acesso, você passa pelo assistente de inicialização, cria a conta de administrador e depois escolhe o LLM Provider, o Embedding Provider e o banco de dados vetorial.
Se você está mais acostumado com o Compose, pode escrever assim.
Crie o diretório:
mkdir -p /opt/anythingllm
cd /opt/anythingllm
touch .env
Crie o docker-compose.yml:
services:
anythingllm:
image: mintplexlabs/anythingllm:latest
container_name: anythingllm
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
cap_add:
- SYS_ADMIN
environment:
STORAGE_DIR: /app/server/storage
JWT_SECRET: "replace-with-a-long-random-string-at-least-32-chars"
PASSWORDMINCHAR: "10"
DISABLE_TELEMETRY: "true"
volumes:
- /opt/anythingllm:/app/server/storage
- /opt/anythingllm/.env:/app/server/.env
Inicie:
docker compose up -d
Aqui eu escrevi a porta como:
127.0.0.1:3001:3001
Isso significa que apenas a máquina local pode acessar a 3001, sem expô-la diretamente à internet. Depois, use o Caddy como proxy reverso para um domínio HTTPS.
Isso é mais seguro do que abrir o 3001 para toda a internet.
Suponha que seu domínio seja:
ai.example.com
Adicione um registro A no DNS:
ai.example.com -> your_server_ip
Instale o Caddy:
apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' > /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install -y caddy
Edite o Caddyfile:
nano /etc/caddy/Caddyfile
Escreva:
ai.example.com {
reverse_proxy 127.0.0.1:3001
}
Verifique a configuração:
caddy validate --config /etc/caddy/Caddyfile
Recarregue:
systemctl reload caddy
Agora acesse:
https://ai.example.com
O Caddy solicita e renova automaticamente os certificados HTTPS.
Se você usa o Caddy como proxy reverso, na internet só é preciso abrir SSH, 80 e 443.
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status
Não exponha o 3001 diretamente à internet:
ufw deny 3001/tcp
Se o seu Docker Compose anterior já estava vinculado a 127.0.0.1:3001:3001, mesmo que o grupo de segurança do provedor de nuvem abra a 3001 por engano, o acesso externo à porta do contêiner não funcionará.
O AnythingLLM é apenas o frontend e a base de conhecimento; ele ainda precisa se conectar a um modelo.
Essa opção serve para a maioria dos usuários de VPS.
Vantagens:
- Requisitos baixos de configuração do VPS
- Velocidade de resposta estável
- Não é preciso gerenciar modelos locais
- É a opção mais tranquila para implantações de equipes pequenas
Desvantagens:
- O conteúdo dos documentos é enviado ao provedor de API correspondente para processamento
- Há custos de API
- Depende da disponibilidade de serviços externos
Se os materiais não forem extremamente sensíveis, como documentação pública de produtos, FAQ de atendimento ao cliente, conteúdo de blog ou documentos internos de processos comuns, essa opção é mais realista.
Adequada para usuários que querem manter os dados na própria máquina o máximo possível.
Primeiro instale o Ollama:
curl -fsSL https://ollama.com/install.sh | sh
Baixe um modelo pequeno para testar:
ollama pull llama3.1:8b
Teste o endpoint:
curl http://127.0.0.1:11434/api/tags
Se o AnythingLLM estiver no Docker, o localhost dentro do contêiner se refere ao próprio contêiner, não ao host.
No Linux, você pode adicionar isto no Compose:
extra_hosts:
- "host.docker.internal:host-gateway"
Depois, no AnythingLLM, coloque o endereço do Ollama como:
http://host.docker.internal:11434
Se você usa Docker Run, precisa adicionar:
--add-host=host.docker.internal:host-gateway
Muita gente tropeça aqui: preenche http://localhost:11434 dentro do contêiner e a conexão falha o tempo todo.
O que mais confunde no AnythingLLM é isto.
Em resumo:
| Método | Cenário adequado | Alcance |
|---|---|---|
| Attach file | Perguntar temporariamente sobre um arquivo | Mais adequado para a conversa atual |
| Embed no Workspace | Base de conhecimento de longo prazo | Pode ser recuperado no workspace depois |
Se você só quer que a IA veja um PDF e responda algumas perguntas, o Attach é suficiente.
Se você quer fazer "perguntas e respostas sobre as políticas da empresa", "perguntas e respostas sobre o manual do produto" ou uma "base de conhecimento de atendimento ao cliente", deve incorporar os documentos ao Workspace para que se tornem uma base de conhecimento recuperável.
Meu conselho:
- Um Workspace por departamento
- Um Workspace por linha de produto
- Não misture materiais sensíveis com materiais públicos no mesmo Workspace
- Para arquivos dos quais você não tem certeza se usará a longo prazo, faça Attach primeiro, não tenha pressa em Embed
RAG não é jogar todos os arquivos de uma vez. Quanto mais claros forem os limites dos materiais, mais confiáveis serão as respostas.
A versão Docker do AnythingLLM oferece suporte a multiusuário e gerenciamento de permissões.
Mas multiusuário não é "ativar primeiro e ver depois". Você precisa pensar antes:
- Quem pode ver qual Workspace
- Quais documentos podem ser compartilhados
- Quem guarda a conta de administrador
- Como remover usuários que saíram
- Se um Chat Widget público é permitido
Se for só você testando, primeiro execute o fluxo como usuário único.
Quando confirmar que os workspaces, a classificação de documentos e as configurações de modelo estão estáveis, então considere o uso multiusuário. Abrir o acesso à equipe sem ter pensado bem no design de permissões costuma gerar confusão depois.
O que mais assusta em uma base de conhecimento auto-hospedada não é uma queda breve do serviço, mas perder os índices de documentos e a configuração.
Os dados principais do AnythingLLM ficam no diretório de armazenamento que você montou, por exemplo:
/opt/anythingllm
No mínimo, faça backup de:
.env- O banco de dados e a configuração no diretório storage
- Os documentos enviados
- Os dados relacionados ao índice vetorial
Primeiro você pode criar um pacote compactado local:
cd /opt
tar -czf anythingllm-backup-$(date +%F).tar.gz anythingllm
Depois sincronizar com o rclone para o armazenamento de objetos:
rclone copy /opt/anythingllm-backup-$(date +%F).tar.gz r2:backup-bucket/anythingllm/
Fazer backup sem restaurar é o mesmo que não ter terminado.
Encontre um horário de pouco movimento para ensaiar uma vez:
docker compose down
mv /opt/anythingllm /opt/anythingllm-old
mkdir -p /opt/anythingllm
tar -xzf /opt/anythingllm-backup-2026-07-12.tar.gz -C /opt
docker compose up -d
Confirme que as contas, os Workspaces, os documentos e o chat continuam funcionando.
Atualizar uma implantação com Docker é simples, mas em produção não atualize de olhos fechados.
Entre no diretório:
cd /opt/anythingllm
Faça backup primeiro:
tar -czf /opt/anythingllm-before-upgrade-$(date +%F).tar.gz /opt/anythingllm
Baixe a nova imagem:
docker compose pull
Reinicie:
docker compose up -d
Veja os logs:
docker logs anythingllm --tail=100
Após atualizar, verifique principalmente:
- Se consegue fazer login
- Se os Workspaces ainda estão lá
- Se os documentos podem ser recuperados
- Se o LLM Provider está funcionando
- Se o Embedding Provider está funcionando
- Se o HTTPS do Caddy está funcionando
Se encontrar anomalias, não apague os dados primeiro. Mantenha o diretório antigo e o backup, e só depois decida sobre o rollback.
Verifique se o contêiner está em execução:
docker ps --filter "name=anythingllm"
Veja os logs:
docker logs anythingllm --tail=100
Verifique a porta:
ss -tlnp | grep 3001
Se você usa o Caddy, continue verificando:
systemctl status caddy --no-pager -l
journalctl -u caddy -n 100 --no-pager
Normalmente é que o AnythingLLM não subiu, ou o Caddyfile aponta para o lugar errado.
Confirme que a máquina local consegue acessar:
curl -I http://127.0.0.1:3001
Se a máquina local também não consegue acessar, corrija o Docker primeiro; se a máquina local consegue acessar, então corrija o Caddy.
Primeiro teste no host:
curl http://127.0.0.1:11434/api/tags
Se o host funciona mas o contêiner não, provavelmente o endereço está errado.
Quando o AnythingLLM no Docker acessa o Ollama do host, normalmente não se deve escrever:
http://localhost:11434
Troque para:
http://host.docker.internal:11434
E garanta que no Compose haja:
extra_hosts:
- "host.docker.internal:host-gateway"
Normalmente não é um problema do servidor, mas do design da base de conhecimento.
Verifique primeiro:
- Se os documentos estão muito antigos
- Se materiais não relacionados foram misturados no mesmo Workspace
- Se a pergunta é ampla demais
- Se o Embedder está configurado corretamente
- Se, após a divisão dos documentos, é possível recuperar trechos relevantes
Não espere que o RAG entenda tudo automaticamente. Se você der um monte de arquivos bagunçados, ele vai procurar respostas nos arquivos bagunçados.
Verifique a memória:
free -h
Verifique o OOM:
journalctl -k | grep -i "out of memory"
Se você roda AnythingLLM e Ollama ao mesmo tempo, é normal faltar memória.
A curto prazo, você pode adicionar swap:
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
Mas o swap só serve para emergências; não transforma um VPS pequeno de 2GB em um servidor de IA.
Assim que o AnythingLLM estiver na internet, no mínimo faça estas coisas:
- Acesse apenas por domínio HTTPS
- Não exponha diretamente a porta 3001
- Use uma senha de administrador forte
- Não escreva as API Keys em repositórios públicos
- Separe os materiais de equipes diferentes em Workspaces diferentes
- Faça backup regular de
/opt/anythingllm - Desative a tempo as contas de pessoas que saíram
- Antes de enviar materiais sensíveis, confirme os requisitos de conformidade
Se for só para uso próprio, você também pode adicionar uma camada de Cloudflare Access ou Tailscale para permitir o acesso apenas dos seus próprios dispositivos.
Essas três ferramentas costumam ser perguntadas juntas.
| Ferramenta | Mais adequada para |
|---|---|
| AnythingLLM | Perguntas e respostas sobre documentos, base de conhecimento privada, RAG para equipes pequenas |
| Dify | Aplicações de IA, fluxos de trabalho, Agent, orquestração de serviços externos |
| Open WebUI | Interface de chat tipo ChatGPT, chat com modelos locais, entrada para vários modelos |
Minha escolha é simples:
- Querer "enviar documentos e depois fazer perguntas": AnythingLLM
- Querer "criar uma aplicação de IA para outras pessoas usarem": Dify
- Querer "dar ao Ollama um bom frontend de chat": Open WebUI
Essas três não substituem totalmente umas às outras; são apenas entradas diferentes.
Se fosse para fazer perguntas e respostas sobre documentos internos para uma equipe pequena de 3-5 pessoas, eu configuraria assim:
- VPS: a partir de 2 núcleos 4GB
- Modelo: conectar primeiro à OpenAI / OpenRouter, sem pressa para rodar localmente
- Implantação: Docker Compose + Caddy HTTPS
- Portas: abrir apenas 80/443, não abrir a 3001
- Documentos: criar Workspaces por departamento ou linha de produto
- Backup: fazer backup diário de
/opt/anythingllmpara o armazenamento de objetos - Permissões: testar primeiro como usuário único e ativar o multiusuário quando o fluxo estiver estável
Quando você realmente confirmar que os materiais não podem sair da rede, então considere opções mais pesadas como Ollama, embedding local e servidores com GPU.
O valor do AnythingLLM não é "ter instalado uma ferramenta de IA", mas transformar documentos dispersos em uma base de conhecimento que você pode perguntar, consultar e compartilhar. O VPS é apenas o suporte; o que realmente precisa de manutenção a longo prazo são os limites dos materiais, as permissões e os backups.