Plataforma multi-cliente:
escalar sem inflar custo e time
O caminho de hoje, do começo ao fim
Arquitetura & borda
Visão e pilares, diagrama do sistema, borda no Cloudflare + Next.js (SSR) e orquestração dos containers com Coolify.
Dados
Evolution no container × Supabase; bancos de usuários e de dados brutos, logs em NoSQL dedicado e arquivos no R2 + CDN.
Operação
Deploy & homologação (Cypress/Playwright, Workers × imagem Docker) e observabilidade & correção (Grafana, erro vira ticket).
Serviços da plataforma
Infisical, OpenRouter, back-office, integração de mídia (Meta/Google Ads · ETL), Design System + Segundo Cérebro e mensageria (Evolution × uazapi).
Decisão
Questões em aberto, custo (método) e o fecho: as 4 decisões de hoje.
Uma plataforma multi-cliente, vários serviços por cliente, operável por um time enxuto
Front no Cloudflare + Next.js (render no servidor); a VPS roda os containers de cada cliente via Coolify; dados no Supabase, fora da VPS. Segredos, LLM e inventário são camadas transversais.
Borda & front-end
Cloudflare na frente + Next.js com SSR / React Server Components. Consultas e CRUD rodam no servidor — a API nunca é exposta ao browser.
Orquestração na VPS
Coolify (PaaS self-hosted) gerencia deploy, logs de container e instala softwares que precisam viver em container, como a Evolution API.
Dados
Supabase como banco das aplicações dos clientes (backup / restore gerenciados). O DB do Evolution fica dentro do próprio container do serviço.
Segredos
Infisical como camada central de acesso a chaves/segredos, injetando nos serviços — no lugar de .env espalhados por container.
LLM
OpenRouter como ponto único de acesso a modelos. Cada software recebe acesso específico, com controle e billing centralizados.
Back-office próprio
Software à parte que mapeia quais serviços estão vinculados a cada cliente — a fonte de verdade do inventário cliente ↔ containers.
Observabilidade
Grafana para dashboards de recurso por container (CPU/RAM/disco/rede) e ingestão de erros. Erros viram tickets acionáveis — por nós ou por IA de correção.
Camada de dados
Bancos por finalidade — usuários × dados brutos —, logs em NoSQL dedicado e arquivos no Cloudflare R2 + CDN — backup, isolamento e entrega adequados a cada tipo de dado.
Integração de mídia
Meta e Google Ads via tech providers → ETL → banco → dashboards e agentes, para decisões de verba de campanha do cliente.
Conhecimento
Design System da marca + Segundo Cérebro (base de conhecimento) — fonte única para produção humana e da equipe de agentes 24/7.
Do usuário à VPS: borda no Cloudflare, orquestração no Coolify, dados no Supabase
Cloudflare + Next.js SSR/RSC — a API não chega ao browser
Por que renderizar no servidor
- Consultas e CRUD acontecem no servidor (SSR / React Server Components); o browser recebe HTML, não credenciais nem endpoints internos.
- A API nunca é exposta ao browser — o cliente não chama a API diretamente. Reduz superfície de ataque e evita expor chaves no front.
- Cloudflare na frente entrega CDN, WAF e TLS antes de qualquer request tocar a aplicação.
Flexibilidade: onde roda o "server"
O data layer do Next pode viver em dois lugares, e isso é uma decisão por serviço/stack, não global:
No edge — Cloudflare Workers
Baixa latência global, escala automática. Bom quando o serviço cabe nas restrições do runtime de edge.
Na VPS
Quando o serviço precisa de proximidade dos containers, libs nativas ou stack que não roda no edge.
Deixar essa escolha explícita evita padronizar cedo demais em um runtime que não serve para todos os serviços.
Deploy, logs e containers de terceiros sem operar um cluster
O que o Coolify resolve
- Deploy. Push-to-deploy dos serviços, com build e rollback, sem escrever pipeline do zero para cada app.
- Logs de container. Acesso centralizado aos logs de cada serviço rodando na VPS.
- Instalar software que precisa de container. Ex.: Evolution API (WhatsApp) e outros serviços de terceiros que exigem viver em container.
- Orquestração. Ciclo de vida dos containers (subir, reiniciar, variáveis, rede) por uma UI única.
Por que Coolify
Um PaaS self-hosted rodando na nossa VPS: entrega a experiência de "sobe o serviço e me dá os logs" que um dev espera de uma plataforma gerenciada, mas sob nosso controle e no nosso custo de VPS — sem a complexidade de operar Kubernetes.
É a peça que torna a plataforma multi-serviço por cliente operável por um time enxuto: cada software de cliente ou de terceiro vira um container gerenciado pelo mesmo painel.
Dois destinos de dados: dentro do container × fora da VPS, no Supabase
DB do Evolution — no container
O banco do Evolution fica dentro do próprio container do serviço, acoplado a ele. É estado do serviço de mensageria, gerenciado junto com o container que o Coolify sobe.
DB das apps dos clientes — Supabase
O banco das aplicações de cliente fica no Supabase, fora da VPS. É o dado de negócio que precisa de garantia de recuperação.
Por que Supabase, fora da VPS
- Disaster Recovery: backup e restore gerenciados que a VPS não entrega bem. Banco na VPS é mais vulnerável e o restore é mais custoso.
- Storage físico: o disco da VPS é consumido conforme o banco cresce — e escala com o nº de clientes na mesma VPS.
- Tirar o dado de negócio da VPS desacopla capacidade de disco do crescimento da base.
Disco da VPS × nº de clientes
ilustrativoSeparar por tipo de dado: bancos do core, logs em NoSQL, arquivos no R2
Cada tipo de dado tem exigência diferente de backup, escrita e entrega. Em vez de um destino único, separamos em três — cada um no armazenamento que melhor atende às suas restrições.
Bancos do core: usuários × dados brutos
No core, separamos o banco de usuários do banco de dados brutos — isolando o acesso do usuário do dado bruto. São bancos distintos, não schemas: backup e restore são por banco, com isolamento de blast-radius por finalidade.
Logs em NoSQL dedicado
Logs vão para um banco NoSQL separado do transacional. O padrão é append: escrita e leitura, sem update — por isso NoSQL encaixa, sem preocupação com update ou migração de schema de log.
Arquivos no Cloudflare R2
Arquivos e binários ficam no R2 (object storage da Cloudflare), aproveitando o CDN da Cloudflare para entrega. Tira o arquivo pesado de dentro da VPS e do banco.
Fechamento: separar por tipo de dado — bancos de usuários e de dados brutos · logs em NoSQL · arquivos no R2 — dá backup, isolamento e entrega adequados a cada um.
Todo deploy passa por homologação e por uma janela acordada com o cliente
O fluxo
- Homologação (staging): toda mudança sobe primeiro em ambiente de homologação.
- Gate de testes: suíte E2E + regressão com Cypress ou Playwright roda em homologação antes de qualquer deploy. A escolha Cypress × Playwright é uma decisão em aberto.
- Deploy agendado: só após a aprovação se agenda o deploy — em janela acordada por cliente, no horário de baixa/fora de acesso.
- Loop de ticket: se a suíte reprova, abre-se um ticket que vai para correção (dev/arquiteto ou AI de correção) e volta ao dev — nada sobe sem passar de novo pelo gate.
Dois caminhos de deploy — diferença importante
Server no edge
Cloudflare WorkersDeploy direto, sem imagem nem container: o código é publicado no edge. Sem build de Docker, sem registry — o Cloudflare hospeda e escala.
Server na VPS
Coolify · DockerBuild de imagem Docker → registry → o Coolify baixa a imagem e executa o container na VPS. Ciclo de vida gerido como container.
Tempo de deploy — ordem de grandeza
referência · ordens de grandeza (não medição nossa)O mindset "deploy = instantâneo" vale para o edge. Na VPS o ciclo build → push → pull → run é ordem de grandeza maior — planeje a janela, não subestime.
Grafana observa os recursos; todo erro vira ticket acionável — por nós ou por IA
Grafana — recursos
Dashboards de uso por container: CPU · RAM · disco · rede. Dupla função: (1) saúde operacional da VPS e (2) base de métricas para o rateio de custo — as mesmas medições alimentam o método do slide de custo.
Instrumentação & ingestão de erros
Erros de produção são instrumentados e ingeridos num ponto central, junto com falhas do gate E2E. Daí saem os tickets — nada de erro que só aparece no log de um container e some.
Fechamento: erros do Grafana e do E2E viram tickets acionáveis — hoje por nós, amanhã por uma AI de correção plugável no mesmo fluxo.
Uma camada central de segredos, não .env espalhados
Problema
- .env espalhados por container: cada serviço com sua cópia de chaves, sem fonte única.
- Rotacionar uma chave vira caça a arquivos por vários containers.
- Difícil auditar quem tem acesso a quê e revogar com segurança.
Solução — Infisical
- Camada central de acesso a chaves/segredos, com injeção nos serviços em vez de arquivos estáticos.
- Rotação e revogação num lugar só; os containers consomem do Infisical.
- Acesso por serviço, auditável — casa com o modelo multi-cliente.
O Infisical passa a ser a fonte única de segredos da plataforma; os serviços orquestrados pelo Coolify recebem os segredos injetados, não hardcoded.
Um ponto único de acesso a modelos, com controle e billing centralizados
Como funciona
- OpenRouter é o ponto único de acesso a modelos de LLM da plataforma.
- Cada software recebe acesso específico ao(s) modelo(s) que precisa — nem mais, nem menos.
- Controle e billing centralizados: consumo e custo de LLM ficam em um lugar só.
Por que centralizar
Evita chaves de provedores de LLM espalhadas por serviço e torna o custo de IA rastreável por software/cliente — insumo direto para o rateio de custo (slide 16).
A fonte de verdade de quem tem o quê
O que ele mapeia
- Software à parte que registra quais serviços estão vinculados a cada cliente: o inventário cliente ↔ serviços/containers.
- É a fonte de verdade de "quem tem o quê" na plataforma.
- Base para provisionar, desprovisionar e cobrar por cliente de forma consistente.
Por que é necessário
Numa plataforma com vários serviços por cliente, sem inventário central a informação vira conhecimento tribal. O back-office responde, a qualquer momento: quais containers pertencem a qual cliente, o que está ativo e o que deve ser cobrado.
É também a base do rateio de custo (slide 16): sem saber quem tem o quê, não há como atribuir consumo de VPS por cliente. Justifica cobrança, suporte e rateio.
Dados de campanha via tech providers, num pipeline até dashboards e agentes
O problema de permissão
O acesso a Meta Ads e Google Ads via MCP esbarra em permissão: o cliente pode não ter a permissão necessária para expor as contas de anúncio diretamente.
Solução — tech providers
Usamos tech providers (parceiros de mídia) que permitem à OCANA acessar Meta e Google Ads em nome do cliente, contornando a limitação de permissão.
Entrega: os dados passam por ETL, ficam num banco próprio e são consumidos por dashboards e agentes — fornecidos ao cliente para decisões: investir, aumentar ou realocar verba de campanha.
Duas fontes de verdade no setup: identidade da marca e conhecimento da empresa
Design System da marca
No setup, centralizamos cores, tipografia, identidade visual e as regras de design da marca — uma fonte única para produção, humana e de agentes.
Segundo Cérebro
Base de conhecimento da empresa: a fonte de verdade consultada por agentes e pessoas para saber exatamente o que fazer. Alimentada periodicamente e usada pela empresa toda — principalmente pela equipe de agentes 24/7.
Fragmentação por departamento (opcional)
Pode haver bases por departamento para evitar fuga de conhecimento entre áreas, mantendo um núcleo comum consultável por todos.
Fonte única de marca + conhecimento alimentado continuamente = produção consistente, por humanos e pela equipe de agentes 24/7.
Self-hosted que gerenciamos × serviço gerenciado 24/7 — tudo é custo
Evolution API — self-hosted na VPS
- Instalar e gerenciar na VPS; a operação é nossa responsabilidade.
- Preocupação forte com infraestrutura, que cresce com a quantidade de números vinculados.
- Pode servir um cliente ou vários — mas o custo de operação é contínuo e nosso.
uazapi — API de WhatsApp gerenciada
- Mesma categoria da Evolution — API não-oficial (conexão via QR code), mas quem opera a infra é o provedor, não nós.
- Custo fixo e gerenciado 24/7; escala e atualização são problema do fornecedor.
- Preço por dispositivo cai com volume (faixa abaixo). Mensagens ilimitadas, webhook, grupos.
uazapi — preço por dispositivo
fonte: uazapi.dev · planos Entry / LITE / PRO| Plano | Mensalidade | Dispositivos | Custo unitário |
|---|---|---|---|
| Entry | R$ 38 | 2 | R$ 19,00 / dispositivo |
| Servidor LITE | R$ 138 | até 100 | R$ 1,38 / dispositivo |
| Servidor PRO | R$ 195 | até 300 | R$ 0,65 / dispositivo |
Princípio — tudo é custo. Se a operação roda 24/7 com agentes (não conosco de plantão), quanto menos responsabilidade e infra do nosso lado e mais serviços gerenciados por terceiros — que já operam 24/7, com muitos usuários — melhor: reduz custo, tempo e nossa disponibilidade, liberando o time para os problemas mais críticos. Ecoa as escolhas de Supabase e "não Kubernetes".
Três decisões que precisam de aval — sem resposta fechada ainda
VPS por cliente × compartilhada
Cada caso é caso. Depende de recurso disponível, do isolamento exigido e de serviços em background / cronjobs que rodam periodicamente e competem por CPU/RAM na mesma VPS.
a decidir · multi-tenantCusto mensal real
Como ratear por ferramenta/cliente o consumo de CPU/RAM/disco/rede da VPS, mais manutenção e disponibilidade. Detalhado no próximo slide como método, não como total.
a decidir · rateioSLA / janelas de deploy
Disponibilidade prometida, horários de atuação e a janela de deploy de cada cliente (horário de baixa). Conecta com o fluxo de homologação e deploy agendado.
a decidir · SLAEnquadramento
São decisões, não pendências técnicas: cada uma tem trade-off e precisa de acordo do time e, onde couber, do cliente. Nenhuma tem resposta única — a escolha depende do porte e do perfil de cada conta.
Alugar a VPS é fácil de precificar; ratear o consumo por serviço/cliente, não
O problema, enquadrado
O aluguel da VPS tem preço de tabela. O difícil é atribuir quanto dos recursos (CPU/RAM/disco/rede) cada ferramenta ou cliente consome, somar horas de manutenção, o custo do Supabase e do OpenRouter, e a disponibilidade (SLA). Nenhum total é apresentado de propósito — é o que precisamos medir.
Composição a medir
proporções ilustrativas · valores a apurarComo ratear — o método
- Instrumentar recursos por serviço: CPU/RAM/disco/rede por container, via as métricas do Grafana.
- Registrar horas de operação/manutenção e um custo/hora de referência.
- Somar custos externos: Supabase e OpenRouter (tokens) atribuídos por cliente.
- Definir a chave de rateio por consumo medido — não por estimativa — e a janela de SLA por cliente.
O total só entra depois da medição — nada fabricado.
A base está definida — hoje fechamos 4 decisões
✓ Já definido
fechado- Coolify como orquestração (sem Kubernetes).
- Server do Next — critério por serviço: edge (Workers) ou VPS.
- Supabase para as apps dos clientes (dado de negócio fora da VPS).
- Infisical como camada central de segredos.
- OpenRouter para acesso a LLM.
- Grafana para observabilidade de recursos.
- Cypress/Playwright para E2E + regressão em homologação.
- Homologação padrão antes de todo deploy.
- Erros → ticket → correção (AI plugável depois).
- Back-office como inventário cliente ↔ serviços.
- Bancos de usuários e de dados brutos + logs NoSQL + arquivos no R2.
- Integração Meta/Google Ads via tech providers (ETL → agentes/dashboards).
- Design System + Segundo Cérebro (24/7 para agentes).
→ A decidir hoje
A arquitetura está fechada; faltam apenas estas 4 decisões para destravar custo e operação.