Como colocar uma API de IA em produção numa VPS?

Que estrutura uma API de IA precisa em produção?

• A aplicação: FastAPI (Python) ou Express e Fastify (Node.js), servida por um servidor de produção (Uvicorn ou Gunicorn no Python).
• Proxy reverso: Caddy, Traefik ou Nginx, que recebe a internet na porta 443, emite o certificado HTTPS (Let's Encrypt) e repassa à aplicação.
• Banco e cache: PostgreSQL para dados, Redis para fila e limites de uso.
• Segredos: chaves de provedores de IA e senhas fora do código.

Por que usar Docker e versões fixas?

O contêiner leva o código e as dependências exatas. A mesma imagem que passou nos testes é a que roda no servidor. Dê a cada versão uma tag única (data e hora, por exemplo) em vez de latest: assim você sabe o que está no ar e volta para a versão anterior com um comando se algo der errado.

Como proteger as chaves de API?

• Variáveis de ambiente declaradas no arquivo de implantação, com os valores num cofre ou num arquivo fora do repositório.
• Um verificador de segredos no git (hook de pre-commit) para barrar chave antes do commit.
• Chaves diferentes por ambiente (teste e produção) e por aplicação, para saber quem gastou e revogar sem derrubar o resto.
• Nunca devolva a chave do provedor ao navegador do cliente: o navegador fala com a sua API, e só a sua API fala com o provedor.

Como limitar o uso para o custo não explodir?

Cada chamada ao modelo custa tokens. Um cliente com erro em loop, ou um robô na internet, pode gerar milhares de chamadas numa noite. Coloque:

1. autenticação em toda rota (chave por cliente ou sessão);
2. limite de requisições por minuto por chave (rate limit, com Redis);
3. limite de tokens por requisição e de gasto por dia, com alerta;
4. timeout na chamada ao modelo, para não acumular conexões penduradas.

O que monitorar depois que a API está no ar?

• Disponibilidade: uma rota /health verificada de fora a cada minuto.
• Erros do provedor de IA: limites de taxa, chave inválida e quedas aparecem como erro 429 ou 5xx.
• Tempo de resposta por etapa (veja por que o chatbot demora).
• Consumo de tokens por cliente e por dia.
• Memória e disco da VPS, com alerta antes de encher.

Como atualizar sem derrubar o serviço?

1. Construa a imagem nova com tag nova.
2. Suba o contêiner novo ao lado do antigo; o proxy só manda tráfego quando o /health responder.
3. Confira em produção que a versão nova é a que responde.
4. Guarde a tag anterior para voltar em um comando.

Para escrever e testar a API com agentes de IA antes de publicar, veja vibe coding em servidor remoto; para dimensionar a máquina, que servidor um agente de IA precisa.

Qual a estrutura mínima de arquivos de um deploy?

• Dockerfile: imagem enxuta (base python:3.12-slim ou node:22-slim), dependências com versão fixa e usuário sem privilégio.
• docker-compose.yml: a API, o PostgreSQL, o Redis e o proxy, cada um com volume próprio e só o proxy publicando portas.
• .env.example: a lista das variáveis necessárias, sem valores reais; o .env verdadeiro fica fora do git.
• .gitignore criado antes do primeiro commit, com .env, dados e logs.
• Um script de implantação que constrói a imagem com tag nova, sobe, testa o /health e registra a tag no ar.

Com isso no repositório, qualquer pessoa da equipe (ou um agente de IA) reconstrói o ambiente do zero numa VPS nova em minutos.

Onde guardar os logs da API?

Logs mostram o que aconteceu quando o cliente reclama. Grave em formato estruturado (uma linha JSON por requisição) com data, rota, cliente, tempo de resposta e erro, e configure rotação para o disco não encher. Não grave a chave de API nem dados pessoais completos no log: mascare CPF, telefone e e-mail. Logs com dados de clientes também entram na política de retenção da LGPD (veja IA e LGPD).