Olá a todos!
Como já devem estar carecas de saber, sou um grande defensor de soluções self-hosted, especialmente quando falamos de IA e LLMs. Já vos falei sobre o Cline, LM Studio, Ollama, e toda a stack que permite ter controlo total sobre os nossos modelos de linguagem.
E hoje venho partilhar convosco uma implementação que resolveu um problema que andava a incomodar-me há meses: como aceder aos meus LLMs internos de forma segura quando não estou on-site, sem ter que andar sempre a ligar VPNs, ou a brincar com API gw’s feitas em apache reverse proxys?
A solução? KrakenD API Gateway. E antes que pensem “lá vem ele com mais uma ferramenta complicada”, garanto-vos que é exatamente o oposto. É simples, rápido, e incrivelmente poderoso.
O Problema Que Enfrentava
Vamos ser honestos – ter LLMs self-hosted em casa ou no datacenter da empresa é fantástico enquanto estamos na rede local. O problema surge quando estamos fora:
Estou num café a trabalhar remotamente, preciso de usar o meu Qwen3 Coder 30B que está no servidor de casa, e tenho três opções clássicas: ligar a VPN (que às vezes é lenta), expor diretamente o LM Studio ou Ollama à internet (péssima ideia de segurança), ou simplesmente não usar e recorrer a APIs pagas como OpenAI ou Claude (derrotando completamente o propósito do self-hosting).
Nenhuma destas opções me agradava. A VPN adiciona latência, consome bateria no portátil, e às vezes simplesmente não funciona bem em redes públicas. Expor serviços diretamente à internet é pedir problemas. E usar serviços cloud? Bem, isso vai contra tudo aquilo em que acredito sobre privacidade e controlo de dados.
Enter KrakenD: O API Gateway Que Faz Sentido
O KrakenD é um API Gateway open-source, stateless, e de alta performance que resolve este problema de uma forma elegante. E quando digo alta performance, não estou a exagerar – este bicho aguenta mais de 80.000 requests por segundo em hardware normal. Para contexto, isso é completamente overkill para o meu caso de uso, mas demonstra a qualidade da engenharia por trás.
Mas o que me atraiu ao KrakenD não foi apenas a performance, mas sim a simplicidade arquitetural. É um único binário. Não tem dependências complexas. A configuração é um ficheiro JSON. E funciona de forma stateless, o que significa que posso escalá-lo horizontalmente sem me preocupar com sessões ou estado partilhado.
Mas a verdadeira perola? A forma como ele me permite criar uma camada de segurança, autenticação, e controlo de acesso entre a internet pública e os meus LLMs privados, sem a complexidade de uma VPN e sem comprometer a segurança.
A Minha Implementação: Arquitetura Simples mas Poderosa
Deixem-me explicar como implementei isto no meu setup. A arquitetura é surpreendentemente simples:
Internet → KrakenD (exposto publicamente com TLS) → Rede Interna → LLMs (LM Studio, Ollama, etc.)
O KrakenD está numa DMZ ou numa máquina dedicada com acesso controlado à minha rede interna. Ele age como um reverse proxy inteligente, mas com esteróides. Aqui está o que acontece quando faço um request aos meus LLMs:
Primeiro, o KrakenD valida o meu token JWT. Sem token válido? Nem sequer chega aos backends. Segundo, ele aplica rate limiting específico para o meu utilizador – não quero que alguém que consiga roubar o meu token abuse do sistema. Terceiro, ele roteia o request para o backend apropriado baseado no endpoint que chamei. Quarto, ele pode agregar múltiplas chamadas se necessário (embora para LLMs isso seja menos comum).
O resultado? Posso fazer um simples curl ou chamada API de qualquer lugar do mundo, e acedo aos meus LLMs como se estivesse na rede local, mas com segurança enterprise-grade.
Configuração Prática: Do Zero ao Hero em 30 Minutos
A configuração do KrakenD para este caso de uso é surpreendentemente direta. Vou partilhar a essência do que implementei, sem entrar em todos os detalhes de produção (porque isso daria um post inteiro só por si).
Primeiro, a instalação. Como disse, é um único binário. No meu caso, uso Docker porque torna o deployment mais limpo, reproduzível e escalável. Quero mais capacidade? Meto um haproxy a frente com persistência de sessão, mais nós de krakend e está feito.
docker run -p 8080:8080 -v $PWD:/etc/krakend krakend/krakend run -c /etc/krakend/krakend.jsonSimples, não? Mas o truque está no ficheiro de configuração. O KrakenD usa um ficheiro JSON para definir tudo – endpoints, backends, autenticação, rate limiting, tudo.
Aqui está a estrutura básica que uso para expor os meus LLMs:
A configuração define um endpoint público (por exemplo, /llm/chat) que aceita requests POST. Este endpoint está protegido por JWT validation – o KrakenD verifica se o token é válido, se não expirou, e se tem as claims corretas. Se passar estas validações, o request é encaminhado para o backend interno (o meu LM Studio ou Ollama na rede privada).
O rate limiting é crucial. Configurei para permitir um máximo de 100 requests por minuto por utilizador. Isto previne abuse e garante que mesmo se alguém conseguir o meu token, não vai conseguir sobrecarregar o sistema. Para os meus casos de uso pessoais, 100 requests por minuto é mais que suficiente.
A parte do JWT é interessante. Gero os tokens usando uma chave privada que só eu tenho. O KrakenD só precisa da chave pública para validar os tokens. Isto significa que mesmo se alguém comprometer o KrakenD (improvável, mas nunca se sabe), não consegue gerar novos tokens válidos.
Segurança em Camadas: Viva a ceblola.
Uma das lições que aprendi ao longo dos anos é que segurança nunca deve depender de um único ponto de falha. O meu setup com KrakenD implementa segurança em múltiplas camadas:
- Primeira Camada: TLS/HTTPS Todo o tráfego entre os meus dispositivos e o KrakenD é encriptado. Uso Let’s Encrypt para certificados gratuitos e automáticos. Isto garante que ninguém pode fazer sniffing do tráfego, mesmo em redes públicas não confiáveis.
- Segunda Camada: JWT Authentication Cada request precisa de um token JWT válido. Estes tokens têm validade curta (24 horas no meu caso) e incluem claims específicas que o KrakenD valida. Sem token válido, nem sequer se chega aos backends.
- Terceira Camada: Rate Limiting Mesmo com token válido, há limites de quantos requests podem ser feitos. Isto previne abuse e ataques de DoS, mesmo por utilizadores autenticados.
- Quarta Camada: IP Filtering (Opcional) Para casos onde sei que só vou aceder de certas localizações, posso adicionar whitelist de IPs. Isto não é prático para trabalho verdadeiramente remoto, mas é uma opção para cenários específicos.
- Quinta Camada: Network Segmentation O KrakenD está numa zona de rede separada dos LLMs. Mesmo se alguém comprometesse o KrakenD, ainda teria que atravessar outra camada de segurança para chegar aos servidores internos.
Esta abordagem de defesa em profundidade significa que um atacante teria que comprometer múltiplas camadas para causar dano real. É overkill? Talvez. Mas durmo melhor à noite sabendo que os meus sistemas estão protegidos.
Performance: Zero Compromissos
Uma das minhas preocupações iniciais era se o KrakenD adicionaria latência significativa aos requests. Afinal, estamos a adicionar outra camada entre o cliente e o servidor. A resposta curta? A latência adicionada é negligível.
O KrakenD é escrito em Go e otimizado para performance. Na minha experiência prática, adiciona menos de 10ms de latência aos requests, o que é completamente imperceptível quando falamos de LLMs que podem demorar segundos a gerar respostas.
Mais importante, a performance do KrakenD escala linearmente. Se precisar de mais throughput, basta adicionar mais instâncias. Como é stateless, não há necessidade de coordenação complexa entre instâncias. Cada uma funciona de forma independente.
Para o o caso de uso pessoal, uma única instância do KrakenD num Raspberry Pi 4 seria mais que suficiente (embora eu use hardware ligeiramente melhor por outras razões). Isto demonstra quão eficiente o sistema é.
Casos de Uso Além dos LLMs
Embora tenha implementado o KrakenD especificamente para aceder aos meus LLMs, rapidamente percebi que podia fazer muito mais com ele. A arquitetura é genérica o suficiente para proteger e expor qualquer serviço interno.
- Home Assistant API Tenho Home Assistant a correr em casa para automação. Com o KrakenD, posso aceder à API de forma segura de qualquer lugar, sem expor diretamente o Home Assistant à internet.
- Media Servers Jellyfin, Plex, ou qualquer media server pode ser exposto através do KrakenD com autenticação adicional e rate limiting. Isto é especialmente útil se partilho acesso com família ou amigos.
- Development APIs Quando desenvolvo APIs para projetos pessoais, o KrakenD permite-me testá-las remotamente sem configurar VPNs ou expor portas diretamente.
- IoT Devices Dispositivos IoT em casa (câmaras, sensores, etc.) podem ter as suas APIs protegidas pelo KrakenD, adicionando uma camada de segurança que muitos destes dispositivos não têm nativamente.
A versatilidade é impressionante. Uma vez que o KrakenD está configurado e a funcionar, adicionar novos serviços é questão de adicionar algumas linhas ao ficheiro de configuração.
Podem ainda adicionar várias instancias por detrás de um haproxy caso tenham necessidade de crescer na horizontal a capacidade, ou de ganhar alta disponibilidade no serviço.
Comparação com Alternativas: Porque Não Uso X?
Sei que muitos vão perguntar: “Porque não usar Nginx/Traefik/Cloudflare Tunnel/outra solução?” É uma pergunta válida, e já experimentei várias alternativas.
Nginx Nginx é fantástico como reverse proxy, mas para atingir o nível de funcionalidade que tenho com KrakenD, teria que adicionar múltiplos módulos e configurações complexas. O KrakenD oferece tudo out-of-the-box: JWT validation, rate limiting, aggregation, circuit breakers, etc.
Traefik Traefik é excelente, especialmente se estás todo no ecosistema Kubernetes. Mas para o meu caso de uso, é mais complexo que necessário. O KrakenD é mais leve e mais focado.
Cloudflare Tunnel Cloudflare Tunnel (antigo Argo Tunnel) é uma solução interessante, mas coloca um terceiro entre mim e os meus serviços. Prefiro ter controlo total. Além disso, o Cloudflare tem acesso a todo o tráfego, o que para dados sensíveis como queries a LLMs não é ideal.
VPN Tradicional VPNs funcionam, mas são overhead desnecessário para este caso de uso. Consome bateria, adiciona latência, e às vezes simplesmente não funciona bem em certas redes (aeroportos, hotéis, etc.).
O KrakenD oferece o sweet spot: simplicidade de configuração, performance excelente, segurança robusta, e controlo total.
GitOps e Infrastructure as Code: Porque Importa
Uma das coisas que mais aprecio no KrakenD é como ele se integra perfeitamente numa workflow GitOps. A configuração é um ficheiro JSON que vive num repositório Git. Quero adicionar um novo endpoint? Edito o JSON, faço commit, e faço deploy. Simples.
Isto traz vantagens enormes:
Versionamento: Toda a história de mudanças está no Git. Se algo quebrar, posso fazer rollback para uma versão anterior em segundos.
Auditoria: Todas as mudanças estão documentadas no histórico do Git. Quem mudou o quê, quando, e porquê (se os commits forem bem escritos).
Reprodutibilidade: A configuração está toda em código. Se precisar de recriar o ambiente noutro servidor, é questão de copiar o ficheiro de configuração.
Testing: Posso ter múltiplos ambientes (dev, staging, production) com configurações ligeiramente diferentes, todas geridas através do Git.
Collaboration: Se trabalho em equipa (mesmo que seja uma “equipa” de uma pessoa em diferentes momentos do tempo), o Git facilita a gestão de mudanças.
Esta abordagem de Infrastructure as Code não é apenas uma buzzword – é genuinamente transformadora na forma como gerimos sistemas.
Monitorização e Observabilidade: Saber o Que Está a Acontecer
Um sistema que não monitorizamos é um sistema que não controlamos. O KrakenD integra-se bem com várias soluções de monitorização, mas para o meu caso de uso, uso uma stack relativamente simples.
O KrakenD expõe métricas Prometheus out-of-the-box. Configurei um Prometheus a fazer scrape destas métricas e um Grafana para visualização. Isto dá-me insights sobre:
- Request Rate: Quantos requests estou a fazer aos LLMs ao longo do tempo. Útil para identificar padrões de uso.
- Latency: Quanto tempo os requests demoram. Se a latência aumentar subitamente, sei que algo pode estar errado.
- Error Rate: Quantos requests falham. Idealmente este número deve estar perto de zero.
- Rate Limit Hits: Quantas vezes os rate limits são atingidos. Se for frequente, posso precisar de ajustar os limites.
Além das métricas, o KrakenD produz logs estruturados em JSON que posso ingerir com qualquer sistema de logging. No meu caso, uso um stack ELK simples (Elasticsearch, Logstash, Kibana) para análise de logs.
Esta observabilidade é crucial e já me salvou o pelo múltiplas vezes quando algo corria mal – consegui identificar e resolver problemas rapidamente porque tinha visibilidade total sobre o que estava a acontecer.
Custos: Praticamente Zero
Uma das grandes vantagens desta solução é o custo. O KrakenD Community Edition é open-source e gratuito. Para o meu caso de uso, é mais que suficiente.
O único custo real é o servidor onde corre o KrakenD caso optem por soluções em datacenter publico. O KrakenD consome recursos mínimos – menos de 100MB de RAM em idle e CPU negligível.
Comparem isto com soluções comerciais de API Gateway que cobram por request ou por throughput, e o valor é óbvio. Para o meu volume de uso (talvez alguns milhares de requests por mês), uma solução comercial custaria dezenas ou centenas de euros por mês.
Esta é mais uma razão porque adoro soluções open-source bem desenhadas. Oferecem valor enterprise sem o preço enterprise.
Lições Aprendidas e Pitfalls a Evitar
Como em qualquer implementação técnica, aprendi algumas lições pelo caminho. Aqui estão os principais pitfalls que encontrei e como os evitei:
- Gestão de Secrets: Inicialmente, tinha a chave JWT hardcoded na configuração. Má ideia. Agora uso variáveis de ambiente que são injetadas no container no arranque. As secrets nunca estão no repositório Git.
- Token Expiration: Os primeiros tokens que gerei tinham validade de 1 ano. Parecia conveniente, mas é péssimo para segurança. Agora uso tokens com validade de 24 horas e tenho um sistema simples para gerar novos tokens quando necessário.
- Backup da Configuração: Óbvio mas importante: fazer backup da configuração. O Git ajuda, mas ter backups fora do Git é sempre boa prática.
- Testing em Staging: Nunca faço mudanças diretamente em produção. Tenho um ambiente de staging onde testo alterações primeiro. Salvou-me de quebrar o sistema múltiplas vezes.
- Rate Limits Realistas: Os primeiros rate limits que configurei eram demasiado restritivos. Testava muito durante desenvolvimento e constantemente atingia os limites. Agora uso limites mais generosos mas ainda seguros.
O Futuro: Para Onde Vou Daqui?
Esta implementação do KrakenD está a funcionar tão bem que já estou a planear expandi-la. Algumas ideias para o futuro:
- Multi-Region: Eventualmente quero ter instâncias do KrakenD em múltiplas regiões geográficas, com load balancing entre elas. Isto melhoraria a latência para quando estou a viajar.
- Advanced Caching: O KrakenD suporta caching de responses. Para certos tipos de queries aos LLMs que são repetitivas, isto podia poupar tempo e recursos.
- API Composition: Uma funcionalidade poderosa do KrakenD é agregar múltiplas APIs numa única response. Ainda não explorei isto completamente, mas vejo potencial para casos de uso mais complexos.
- Custom Plugins: O KrakenD permite plugins custom em Go. Se precisar de funcionalidade muito específica que não existe, posso sempre desenvolver um plugin para o que necessito.
A flexibilidade do sistema significa que posso crescer com as minhas necessidades sem ter que mudar de solução.
Porque É Que Isto Importa no Grande Esquema das Coisas
Alguns podem pensar que isto é overkill. “Porque não usar simplesmente Claude ou ChatGPT e acabar com isto?” É uma pergunta válida, e a resposta resume a minha filosofia sobre tecnologia.
Primeiro, privacidade. Quando uso LLMs self-hosted através do meu próprio API Gateway, sei exatamente onde os meus dados estão e quem tem acesso a eles. Numa era onde dados são ouro, este controlo é inestimável.
Segundo, aprendizagem. Implementar e gerir sistemas como este ensina-nos sobre networking, segurança, APIs, e arquitetura de sistemas. Estas são skills transferíveis que se aplicam a qualquer área de tecnologia.
Terceiro, custo a longo prazo. Sim, há trabalho inicial em setup. Mas depois de configurado, o custo de operação é mínimo. Comparado com pagar por APIs comerciais indefinidamente, o ROI é claro.
Quarto, resiliência. Se a API do Claude ou OpenAI cair (e já caíram múltiplas vezes), estou bloqueado. Com a minha solução, tenho controlo total. Se algo falhar, posso consertá-lo.
Pensamentos Finais
O KrakenD provou ser exatamente o que precisava para resolver o problema de acesso remoto aos meus LLMs self-hosted. É rápido, seguro, simples de configurar, e praticamente gratuito. Mais importante, dá-me controlo total sobre como acedo aos meus serviços.
Para quem está no mundo do self-hosting, hosting on prem com serviços a serem consumidos desde a internet – ou se usarem LLMs – , recomendo vivamente que explorem o KrakenD. A curva de aprendizagem é suave, a documentação é excelente, e os benefícios são imediatos.
A combinação de LLMs self-hosted com um API Gateway robusto como o KrakenD representa, para mim, o futuro de como devemos pensar sobre IA pessoal. Controlo, privacidade, e performance, tudo num package coerente.
Como sempre, se tiverem dúvidas, sugestões, ou quiserem partilhar as vossas próprias experiências com API Gateways e self-hosting, já sabem onde me encontrar. Adoro estas discussões técnicas e aprender com a comunidade.
Até ao próximo post, e lembrem-se: self-hosting não é apenas sobre ter controlo dos vossos dados – é sobre ter controlo do vosso futuro digital.
Abraço, Nuno