>_Talvera labs Newsletter →
Arquitetura 2026-04-20 12 min de leitura

Ollama local + Cloudflare Tunnel: arquitetura de IA para solo founders.

Como expor modelos Llama rodando na sua máquina residencial para uma aplicação web pública, sem abrir porta no roteador, sem depender de IP fixo, com fallback automático quando a máquina cai. Custo zero, setup em uma tarde.

Se você é solo founder construindo micro-SaaS com componente de IA em 2026, você está diante de uma falsa escolha: ou paga API comercial por token (Claude, GPT-4, Gemini) e vê a margem comer os primeiros anos, ou tenta rodar modelo próprio em uma GPU de nuvem cujo custo mensal parado já come o lucro das primeiras 50 transações.

Existe uma terceira opção que não aparece nos tutoriais de venture-capital: rodar o modelo na sua própria máquina — a mesma que você usa para desenvolver — e expô-lo de forma segura para o front da aplicação via Cloudflare Tunnel, com fallback para uma API comercial quando essa máquina estiver indisponível. Essa é a arquitetura que a Talvera Labs adotou, e esse texto explica por quê e como.

O problema concreto

Você tem um micro-SaaS. Uma das features dele chama um modelo de linguagem — por exemplo, para classificar a entrada do usuário em uma categoria, extrair dados estruturados de um texto livre, ou gerar uma explicação curta. Volume esperado: algumas centenas a alguns milhares de chamadas por mês no primeiro ano.

Opção A — API comercial: você paga por token. No volume inicial, o custo é baixo (10-50 reais por mês), mas escala linearmente. Se o produto pega, o custo sobe rápido. Margem comprometida desde o primeiro dia.

Opção B — GPU em nuvem: você aluga uma GPU (A10, L4, T4) em provedor como Runpod ou Vast.ai. Custo mensal fixo de 200 a 600 reais, independente de volume. No primeiro ano, com volume baixo, isso é caro demais por chamada.

Opção C — modelo local exposto: você já tem máquina com GPU consumer (RTX 3060 12GB, 4060 Ti, 4070) que você usa pra desenvolver. O custo marginal de rodar Ollama nela é zero — já está ligada, já está paga. Falta só expor para a aplicação web.

O bloqueio técnico da Opção C sempre foi: como expor um serviço local numa rede residencial? NAT bloqueia conexão de entrada, IP residencial muda periodicamente, abrir porta no roteador é risco de segurança, e nem sempre o provedor de internet permite.

Cloudflare Tunnel resolve o bloqueio

Cloudflare Tunnel é um serviço gratuito (plano Free da Cloudflare) que cria uma conexão reversa entre a sua máquina local e a borda da rede Cloudflare. A máquina local inicia a conexão (não recebe conexão), o que contorna completamente o problema de NAT e porta fechada. A Cloudflare atribui um subdomínio (no seu próprio domínio) que aponta para o tunnel, e qualquer requisição que chegue nesse subdomínio é encaminhada pelo tunnel criptografado até a sua máquina.

Arquitetura resultante: 

[Navegador do usuário]
       │
       ▼
[Seu domínio · ai.talvera.com.br]
       │  (HTTPS, gerenciado pela Cloudflare)
       ▼
[Cloudflare Edge]
       │  (autenticação + rate limit + WAF antes do tunnel)
       ▼
[Tunnel criptografado]
       │
       ▼
[Sua máquina local]
  ├── cloudflared (cliente do tunnel)
  └── Ollama em localhost:11434

Nada de abrir porta. Nada de IP fixo. Nada de expor a máquina pública na internet. O IP real do seu computador nunca aparece para o usuário final — ele vê só o endereço Cloudflare.

O problema da máquina cair

A principal objeção contra expor IA local é: "e se minha máquina cair?". Windows reiniciar pra atualização. Luz cair. Internet da casa oscilar. Você sair de viagem. A aplicação web não pode quebrar quando isso acontecer.

A solução é fallback automático no gateway. A aplicação web não chama o Ollama diretamente — ela chama um Cloudflare Worker (função serverless, plano Free), e é o Worker que tenta o Ollama local primeiro (com timeout curto, 5 segundos) e, em caso de falha ou timeout, cai automaticamente para uma API comercial como Claude Haiku.

Pseudocódigo do Worker: 

export default {
  async fetch(request, env) {
    const body = await request.json();

    try {
      // Tenta Ollama local (timeout 5s)
      const local = await Promise.race([
        fetch('https://ai.talvera.com.br/api/generate', {
          method: 'POST',
          headers: { 'X-Api-Key': env.OLLAMA_KEY },
          body: JSON.stringify(body),
        }),
        new Promise((_, rej) => setTimeout(() => rej('timeout'), 5000))
      ]);

      if (local.ok) return local;
    } catch (err) {
      console.warn('Ollama local indisponível, caindo pra Haiku');
    }

    // Fallback: Claude Haiku
    return fetch('https://api.anthropic.com/v1/messages', {
      method: 'POST',
      headers: {
        'x-api-key': env.ANTHROPIC_KEY,
        'content-type': 'application/json',
      },
      body: JSON.stringify({
        model: 'claude-haiku-4-5-20251001',
        max_tokens: 500,
        messages: body.messages,
      }),
    });
  }
}

Com isso, a aplicação web nunca sabe se a resposta veio da sua máquina ou do Claude. E o custo do Haiku só aparece quando a sua máquina estiver indisponível — no volume esperado, é centavos por mês.

Setup passo a passo

1. Instalar e configurar Ollama

Baixe de ollama.com e instale. Por padrão, ele escuta apenas em 127.0.0.1. Para aceitar conexão do cloudflared rodando na mesma máquina, ajuste a variável de ambiente OLLAMA_HOST=0.0.0.0:11434 e reinicie o serviço.

Baixe os modelos que vai usar. Na stack Labs, usamos llama3.1:8b-instruct-q4_K_M para tarefas rápidas (classificação, extração, triagem — cabe inteiro na VRAM de 12 GB e responde em 2-4 segundos) e llama3.3:70b-instruct-q4_K_M para geração editorial (offload parcial pra RAM, responde em 8-15 segundos — aceitável para uma chamada que acontece 1x ao final do fluxo).

2. Configurar Cloudflare Tunnel

Instale cloudflared (cloudflared.exe no Windows). Rode cloudflared tunnel login, autentique no navegador, depois cloudflared tunnel create labs-ia. Isso gera um ID de tunnel e um arquivo de credencial JSON.

Crie um arquivo de config (config.yml em %USERPROFILE%/.cloudflared/): 

tunnel: labs-ia
credentials-file: C:/Users/User/.cloudflared/labs-ia.json

ingress:
  - hostname: ai.talvera.com.br
    service: http://localhost:8080
  - service: http_status:404

Aponte o subdomínio: cloudflared tunnel route dns labs-ia ai.talvera.com.br. Isso cria um registro CNAME no seu DNS Cloudflare automaticamente.

3. Adicionar autenticação via nginx

Antes do tunnel chegar no Ollama, passe por um nginx local que valida uma API key customizada. Isso evita que qualquer pessoa que descubra o subdomínio consiga fazer chamadas direto. 

server {
  listen 8080;

  location /api/ {
    if ($http_x_api_key != "sua-chave-longa-aqui") {
      return 401;
    }

    proxy_pass http://localhost:11434/api/;
    proxy_set_header Host $host;
    proxy_read_timeout 60s;
  }
}

4. Rodar como serviço de boot

Em produção (mesmo que seja sua casa), o tunnel e o Ollama precisam subir com a máquina. No Windows, use cloudflared service install. Ollama já sobe como serviço por padrão. nginx pode ser empacotado num compose Docker que roda em autostart.

5. Criar o Worker Cloudflare

O Worker é a peça que roda no edge e faz a decisão de chamar Ollama local ou cair no Haiku. Deploy com wrangler deploy. Configure os secrets OLLAMA_KEY e ANTHROPIC_KEY via wrangler secret put.

6. Front consome o Worker

A aplicação web nunca fala com Ollama direto nem com a Anthropic direto. Ela fala com o Worker — um endpoint único, autenticado por tenant. Toda a lógica de "tenta local, cai remoto" fica encapsulada ali.

O que essa arquitetura destrava

Quando você tem essa infraestrutura rodando, três coisas mudam no seu modelo de produto:

1. Custo de IA cai para zero marginal. 95% das chamadas processam na sua máquina, que já está paga. Os 5% de fallback custam centavos por mês.

2. Privacidade por design. Dados sensíveis do cliente não saem da sua infraestrutura — só caem no Haiku quando a máquina local está indisponível. Para contexto brasileiro com LGPD, isso é diferencial real, não marketing.

3. Você pode experimentar sem culpa. Trocar de modelo, testar um fine-tuning, ver se um modelo menor resolve — tudo sem custo adicional. A arquitetura libera iteração.

O que fica em aberto

Essa arquitetura tem limites claros. Se você precisa de disponibilidade garantida em 99.9% com latência baixa consistente, precisa de GPU em nuvem mesmo. Se você tem volume de milhões de chamadas por mês, o fallback vai ficar ativado demais. Se sua aplicação exige modelo grande (Llama 70B ou maior) com latência baixa, GPU consumer de 12GB não dá conta do recado.

Para micro-SaaS de solo founder brasileiro, no primeiro e segundo ano, operando no volume que costuma operar, essa arquitetura resolve com folga. E o que mais importa: resolve com custo de infraestrutura próximo de zero — exatamente o que o ritmo solo precisa.

Publicado em 2026-04-20. Próximo texto: Kill criteria antes de começar (em breve).
Os e-books complementares estão na biblioteca.
Receba por e-mail: newsletter →