PLATAFORMA/ Arquitetura para revisão do time técnico rascunho v1 · custos a definir
Proposta de arquitetura · devs & arquitetos

Arquitetura de plataforma multi-cliente:
VPS + Cloudflare

Uma plataforma que hospeda vários serviços por cliente, na borda com Cloudflare + Next.js e orquestrada na VPS com Coolify — sem Kubernetes. Dados dos clientes no Supabase, segredos no Infisical, LLM via OpenRouter e um back-office próprio como fonte de verdade do inventário cliente ↔ serviços.

Data
24/07/2026
Autor
<definir autor>
Público
Devs / Arquitetura
Status
Em discussão
Custo mensal e janelas de SLA são as questões abertas desta apresentação. 01 / 14
PLATAFORMA/Visão rascunho v1 · custos a definir
01 · O que estamos construindo

Uma plataforma multi-cliente, vários serviços por cliente, operável por um time enxuto

A borda entrega o front no Cloudflare + Next.js com renderização no servidor; a VPS roda os containers de cada cliente, orquestrados pelo Coolify. Os dados das aplicações vivem no Supabase, fora da VPS. Segredos, acesso a LLM e o inventário de quem-tem-o-quê são camadas transversais compartilhadas.

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.

Pilares da arquitetura — detalhados nos slides seguintes.02 / 14
PLATAFORMA/Arquitetura rascunho v1 · custos a definir
02 · Diagrama da arquitetura

Do usuário à VPS: borda no Cloudflare, orquestração no Coolify, dados no Supabase

Diagrama da arquitetura Do usuário ao Cloudflare, Next.js e camada de dados; a VPS com Coolify orquestra Evolution API, serviços por cliente e terceiros; Supabase fica fora da VPS; Infisical, OpenRouter e back-office atuam de forma transversal. Usuário web · app Cloudflare CDN · WAF · Workers Next.js SSR · RSC Data layer edge OU VPS API nunca exposta ao browser VPS · Coolify Coolify deploy · logs · orquestração Evolution API + DB no próprio container Serviços por cliente containers Terceiros outros softwares Supabase fora da VPS · DB das apps dos clientes Infisical injeta segredos OpenRouter acesso LLM Back-office lê inventário — fluxo ⇠ tracejado: segredos · LLM · inventário
O data layer roda no edge (Workers) OU na VPS, conforme o serviço. Supabase e as camadas transversais ficam fora da VPS.03 / 14
PLATAFORMA/Borda rascunho v1 · custos a definir
03 · Borda & front-end

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.

A escolha edge × VPS é por serviço — não há resposta única.04 / 14
PLATAFORMA/Orquestração rascunho v1 · custos a definir
04 · Orquestração na VPS · Coolify

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.

PapelPaaS self-hosted
Entregadeploy · logs
Roda emVPS
Coolify é o painel único de deploy/logs/orquestração dos containers da VPS.05 / 14
PLATAFORMA/Dados rascunho v1 · custos a definir
05 · Dados & persistência

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

ilustrativo
0 disco 1 cli. 3 cli. 6 cli. 10 cli.
Estado de serviço fica no container; dado de negócio vai para o Supabase, fora da VPS.06 / 14
PLATAFORMA/Deploy rascunho v1 · custos a definir
06 · Deploy & homologação

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: testes manuais + agentes de IA garantem que tudo funciona antes de qualquer deploy em produção.
  • 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.
  • Deploy na janela certa evita rodar no meio de uma demanda do cliente e gerar erro em produção. Conecta direto com o SLA (slide de questões).
Deploy e homologação Pipeline: dev, homologação (staging), gate de testes (manuais e agentes de IA), deploy agendado em janela de baixa do cliente e produção; se reprova, volta ao dev. Dev código Homologação staging Testes manuais + agentes de IA Deploy agendado janela de baixa do cliente Produção aprova reprova
Gate de testes antes do deploy; janela de deploy no horário de baixa de cada cliente.07 / 14
PLATAFORMA/Trade-off central rascunho v1 · custos a definir
07 · Por que NÃO Kubernetes

O trade-off central: complexidade que não pagamos para ter

No nosso porte, Kubernetes cobra caro na implementação e na gestão/operação contínua. Coolify entrega deploy + logs + orquestração com uma fração da complexidade. Abaixo, honestamente, o que ganhamos e o que abrimos mão.

A favor do Coolify (nosso porte)

  • Sem control plane para operar: K8s tipicamente pede control plane + 3+ nós (referência de mercado, não medição nossa).
  • Custo de implementação e de gestão/operação muito menores — um time enxuto opera sozinho.
  • Cobre o essencial: deploy, logs e ciclo de vida de container.
  • Menos peças móveis = menos superfície de falha e de manutenção.

O que abrimos mão

  • Autoscaling multi-nó e escalonamento horizontal automático entre máquinas.
  • Self-healing avançado (reschedule entre nós, drain, rolling em cluster).
  • Portabilidade multi-cloud e o ecossistema de ferramentas do k8s.
  • Se o porte crescer muito, essa decisão precisa ser reavaliada — não é permanente.

Resumo do trade-off: trocamos capacidades de escala/resiliência que ainda não precisamos por um custo de operação compatível com o time que temos hoje.

Decisão reavaliável se o porte crescer — não é permanente.08 / 14
PLATAFORMA/Segredos rascunho v1 · custos a definir
08 · Segredos · Infisical

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.

Injeção de segredos, não arquivos estáticos por container.09 / 14
PLATAFORMA/LLM rascunho v1 · custos a definir
09 · LLM · OpenRouter

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 13).

Papelgateway de LLM
Acessopor software
Billingcentralizado
Consumo de LLM por software alimenta o rateio de custo (slide 13).10 / 14
PLATAFORMA/Inventário rascunho v1 · custos a definir
10 · Back-office próprio

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 13): sem saber quem tem o quê, não há como atribuir consumo de VPS por cliente. Justifica cobrança, suporte e rateio.

Sem inventário central, não há rateio de custo por cliente.11 / 14
PLATAFORMA/Questões em aberto rascunho v1 · custos a definir
11 · Questões em aberto para decidir

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-tenant

Custo 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 · rateio

SLA / 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 · SLA

Enquadramento

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.

Decisões abertas: modelo de VPS, método de custo e SLA/janelas.12 / 14
PLATAFORMA/Custo · método rascunho v1 · custos a definir
12 · Custo mensal · método

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 apurar
VPS base CPU/RAM Storage
VPS base ~30% CPU/RAM por ferramenta ~22% Storage ~14% Egress/rede ~8% Horas de manutenção ~18% Tokens LLM (OpenRouter) ~8%

Método — rateio de recursos

  • Métricas por container (CPU/RAM/disco/rede) via Coolify / cAdvisor.
  • Rateio proporcional do custo da VPS pelo consumo medido de cada container.
  • Cruzar com o inventário do back-office para agregar por cliente.

Método — externos & manutenção

  • Somar Supabase e OpenRouter por cliente/software.
  • Registrar horas de operação/manutenção e um custo/hora de referência.
  • Traduzir SLA (plantão, redundância) em custo e refletir no preço.

Entregável desta discussão: acordar as variáveis a medir e o método de rateio — não um total. As cifras entram quando a medição existir.

Sem valores fabricados: o total só entra depois da medição.13 / 14
PLATAFORMA/Decisão rascunho v1 · custos a definir
13 · Próximos passos & o que decidir hoje

O que precisa de aval do time nesta reunião

Decisões que precisam de aval hoje

Fechar a base da arquitetura e destravar o método de custo.

  1. Coolify como base de orquestração (sem Kubernetes).
  2. Onde roda o server do Next — critério edge (Workers) × VPS por serviço.
  3. Adotar Supabase para as apps dos clientes (dado de negócio fora da VPS).
  4. Infisical como camada central de segredos.
  1. VPS por cliente × compartilhada — critério de decisão por conta.
  2. Método de rateio de custo (as variáveis a medir, não o total).
  3. Janelas de SLA/deploy por cliente e homologação padrão antes de todo deploy.

Pedido: fechar hoje 1–5 e aprovar o método de custo e as janelas de SLA — o número por cliente entra depois da medição.

Objetivo da reunião: fechar decisões, o método de custo e as janelas de SLA — não um número.14 / 14