Independência de Infraestrutura — Inkluee Edu

Contexto

Uma plataforma SaaS de governança escolar — matrículas, financeiro, notas, chamada, PEI, comunicação com famílias — foi construída inteiramente via Lovable, uma ferramenta de geração de código por IA. O produto funcionava. Mas a infraestrutura por trás dele era uma bomba-relógio.

O cenário é cada vez mais comum: empresas e empreendedores usam ferramentas low-code/no-code para criar um MVP funcional, mas herdam uma base técnica que não foi pensada para produção real. Quando o primeiro cliente pagante chega, os problemas aparecem.

Desafio

O diagnóstico revelou três camadas de risco que se acumulavam:

Auditoria de Segurança

A análise do código-fonte revelou 6 vulnerabilidades críticas que seriam inaceitáveis com dados reais de alunos:

• 18 Edge Functions completamente públicas (verify_jwt = false) — incluindo reset de senha, importação em massa de usuários e chamadas à OpenAI sem rate limiting
• JWT armazenado em localStorage — qualquer XSS na aplicação compromete a sessão do usuário
• innerHTML não sanitizado — upload de arquivos DOCX maliciosos podia executar JavaScript arbitrário
• Logout que não invalida a sessão — o timer de inatividade redirecionava sem chamar signOut()
• Isolamento multi-tenant quebrado — coordenadores de uma sede podiam ver dados de todas as sedes
• Instituições bloqueadas sem enforcement — a flag is_blocked era carregada mas nunca verificada na rota protegida

Solução

A estratégia foi migrar para uma infraestrutura completamente independente, usando apenas software open-source e serviços que permitem uso comercial — eliminando toda dependência de plataformas proprietárias.

Decisões Arquiteturais

Por que Supabase Self-Hosted e não PostgreSQL puro? O projeto tinha 84 migrations SQL, 18 Edge Functions em Deno, RLS policies complexas e autenticação integrada. Migrar para Postgres puro significaria reescrever as Edge Functions, reimplementar Auth e perder compatibilidade com o código existente. O Supabase self-hosted mantém 95% de compatibilidade com o cloud — incluindo a exportação dos hashes de senha, evitando forçar reset nos usuários.

Por que Cloudflare Pages? O frontend é uma SPA pura (React + Vite, CSR). Não precisa de SSR, não precisa de server functions. Cloudflare Pages entrega arquivos estáticos com CDN global, bandwidth ilimitado e — crucialmente — permite uso comercial no plano gratuito. A migração da Vercel foi uma única linha: substituir vercel.json por public/_redirects.

Por que Coolify? Gerenciar containers Docker manualmente em uma VPS é viável, mas o Coolify oferece deploy visual, SSL automático, logs centralizados e backups agendados — tudo open-source. Para um cliente não-técnico que precisa de autonomia mínima sobre o servidor, a interface visual faz diferença.

Resultado

O que mudou

• Zero dependência de plataformas proprietárias — código em repositório próprio, infraestrutura open-source, qualquer engenheiro pode dar continuidade
• Dados no Brasil — VPS brasileira, conformidade LGPD sem complicações jurídicas
• Custo fixo que escala — o mesmo servidor que atende 1 escola atende 10 sem mudança de plano
• 84 migrations migradas sem perda de dados e sem forçar reset de senha em nenhum usuário
• 6 vulnerabilidades críticas corrigidas antes do onboarding do primeiro cliente piloto com ~900 alunos

A Lição do Low-Code

Ferramentas como Lovable, Bolt e v0 são excelentes para validar ideias rapidamente. Mas o código que geram carrega decisões de infraestrutura que raramente são adequadas para produção: planos gratuitos com restrições comerciais, segurança configurada para conveniência e não para proteção, e dependências que criam vendor lock-in silencioso.

O momento ideal para corrigir isso é antes de ter usuários reais — quando a migração é técnica, não operacional. Cada dia com dados de produção em infraestrutura inadequada aumenta exponencialmente o risco e o custo da correção.