Case principalBetaOnlineProjeto privado

Neexus Deployment Platform

Plataforma multi-tenant de cloud, CI/CD, gateway e edge distribuído com agente próprio em Go

Plataforma de infraestrutura que unifica provisionamento de servidores, deploy CI/CD, publicação via gateway, observabilidade e segurança em um ambiente multi-tenant, com agente Go multiplataforma para operação remota.

Falar comigo

TypeScriptNode.jsExpressPrismaPostgreSQLRedisReactViteGoDockerWebSocketSocket.IOWireGuardTURN

Visão geral

O Neexus é uma plataforma de infraestrutura cloud e on-premise construída para operar aplicações, servidores, túneis, gateway, observabilidade e segurança em um modelo multi-tenant. O sistema combina um backend Express/Prisma com PostgreSQL e Redis, um frontend React/Vite, um backoffice separado para administração global de tenants e um agente Go que roda nos hosts gerenciados. O agente é o componente central da operação remota: mantém conexão WebSocket persistente, executa comandos, coleta métricas, gerencia containers Docker, faz deploy de projetos, atua como edge de entrada de tráfego e implementa funções de RMM e EDR. A comunicação é autenticada por token de enrollment e o agente se auto-atualiza sem reinstalação. A plataforma organiza o trabalho em módulos habilitáveis por tenant — CI/CD, Cloud, Gateway, Monitoramento, Segurança, Drive, Financeiro — e cada tenant tem dados isolados. O backoffice controla o catálogo de módulos, o status das organizações e a criação de convites, separando a operação administrativa da experiência do cliente. O gateway publica aplicações em domínios Neexus com namespace por tenant, suporta upstream local via agente, rotas externas redirecionadas e telemetria de requests, latência e erros. Uma camada de DNS autoritativo e edges distribuídos seleciona o ponto de entrada com base em região, latência e carga, com fallback para a central.

A dor

Equipes que operam múltiplos ambientes enfrentam ferramentas fragmentadas para deploy, monitoramento, segurança e publicação de aplicações, cada uma com seu próprio modelo de acesso e sem isolamento consistente entre organizações. A falta de um agente unificado dificulta operar hosts cloud e on-premise com a mesma visibilidade e o mesmo controle.

A solução

Uma plataforma multi-tenant que integra CI/CD, gateway, observabilidade e segurança sobre um agente Go único, com módulos habilitáveis por organização e um backoffice separado para administração global. O agente expõe uma superfície operacional comum para hosts Linux e Windows, permitindo deploy, métricas, console remoto e edge de tráfego a partir do mesmo binário.

Abordagem de engenharia

Modelo de dados multi-tenant

O schema Prisma foi estruturado com migrações incrementais para tenants, memberships, perfis de acesso, módulos e recursos isolados por organização. Cada migração acompanha a evolução de uma capacidade específica, como gateway, EDR, drive ou billing.

Agente como plano de execução

O agente Go concentra a comunicação com o host: conexão WebSocket, execução de comandos, Docker, métricas, RMM, EDR e edge. A separação em pacotes internos permite testar cada capacidade isoladamente e manter comportamento consistente entre Linux e Windows.

Control plane e backoffice separados

O backend Express expõe rotas modulares com middlewares de autenticação, RBAC, contexto de tenant e limite de taxa. O backoffice é um serviço independente com seu próprio frontend e API, responsável por tenants, módulos e convites.

Gateway e edge distribuído

O gateway publica rotas por domínio com namespace por tenant e telemetria de acesso. Uma camada de DNS autoritativo e edges regionais seleciona o ponto de entrada com base em latência e carga, mantendo fallback para a central.

Entrega e atualização do agente

O agente é distribuído como binário com instaladores para Linux e Windows, incluindo pacote MSI. O mecanismo de atualização remota verifica assinatura com chave pública antes de aplicar a nova versão, sem reinstalação manual.

O que o projeto entrega

Agente Go multiplataforma com conexão WebSocket persistente, reconexão automática e atualização remota assinada
Backend modular com isolamento por tenant, RBAC, perfis de acesso customizados e limite de taxa por contexto
Gateway com namespace por tenant, upstream local via agente e telemetria de requests, latência e erros
Camada de DNS autoritativo e edges distribuídos com seleção por região, latência e carga
Módulos habilitáveis por tenant, incluindo CI/CD, Cloud, Monitoramento, Segurança, Drive e Financeiro
Backoffice separado para administração global de tenants, catálogo de módulos e convites

Arquitetura e desafios técnicos

Neexus: control plane multi-tenant, backoffice e agente Go como plano de execução

Plataforma multi-tenant que separa control plane (Express/Prisma/PostgreSQL/Redis), backoffice administrativo e plano de execução (agente Go) para operar deploy, gateway, observabilidade e segurança sobre hosts cloud e on-premise.

Renderizando diagrama...

Desafios técnicos

Agente próprio em Go em vez de ferramentas externas

Contexto

Operar hosts cloud e on-premise com a mesma visibilidade e controle exigia um componente que unificasse deploy, métricas, console remoto e edge de tráfego, sem depender de múltiplas ferramentas com modelos de acesso distintos.

Decisão

Construir um agente Go único, multiplataforma (Linux e Windows, incluindo MSI), com conexão WebSocket persistente, execução de comandos, Docker, métricas, RMM, EDR e edge, distribuído como binário com auto-atualização assinada.

Trade-off

Assumir o ciclo de vida completo do agente — enrollment, reconexão, atualização e compatibilidade entre sistemas — em vez de delegar a ferramentas de terceiros. Mitigado pela separação em pacotes internos testáveis isoladamente e pela verificação de assinatura com chave pública antes de aplicar atualizações.

Separação entre control plane e backoffice

Contexto

A administração global de tenants, catálogo de módulos e convites não deveria compartilhar fronteiras com a experiência do cliente, para reduzir risco de mistura de contextos e permissões.

Decisão

Manter o backoffice como serviço independente, com frontend e API próprios, enquanto o backend Express expõe rotas modulares com autenticação, RBAC, contexto de tenant e rate limit.

Trade-off

Maior custo operacional e de duplicação de infraestrutura para manter dois serviços. Mitigado pela separação clara de responsabilidades e pelo uso do mesmo modelo de dados multi-tenant no PostgreSQL via Prisma.

Multi-tenancy com módulos habilitáveis por organização

Contexto

Cada tenant precisa de dados isolados e de um conjunto próprio de módulos ativos (CI/CD, Cloud, Gateway, Monitoramento, Segurança, Drive, Financeiro), sem que a evolução de um módulo quebre os demais.

Decisão

Estruturar o schema Prisma com migrações incrementais por capacidade, incluindo tenants, memberships, perfis de acesso, módulos e recursos isolados por organização, com middlewares de contexto de tenant e RBAC no control plane.

Trade-off

Migrações incrementais e isolamento por tenant aumentam a complexidade do modelo e o esforço de evolução do schema. Mitigado pelo versionamento por capacidade e pela validação de acesso em camadas (RBAC + contexto de tenant).

Gateway com edge distribuído e fallback para a central

Contexto

Publicar aplicações em domínios Neexus com namespace por tenant exigia selecionar o ponto de entrada com base em região, latência e carga, sem perder disponibilidade quando um edge regional falha.

Decisão

Combinar DNS autoritativo, edges regionais e gateway com upstream local via agente, rotas externas redirecionadas e telemetria de requests, latência e erros, mantendo fallback para a central.

Trade-off

A distribuição de edges adiciona complexidade de roteamento e consistência de configuração entre regiões. Mitigado pelo fallback para a central e pela telemetria por endpoint, que permite observar o comportamento de cada rota.

Comunicação persistente e atualização segura do agente

Contexto

O agente precisa manter conexão contínua com o control plane para receber comandos e enviar métricas, além de se atualizar remotamente sem reinstalação manual, em hosts Linux e Windows.

Decisão

Usar WebSocket persistente com autenticação por token de enrollment e um mecanismo de atualização remota que verifica assinatura com chave pública antes de aplicar a nova versão.

Trade-off

Conexões persistentes e atualizações remotas ampliam a superfície de segurança e exigem tratamento de reconexão e compatibilidade de versões. Mitigado pelo enrollment autenticado, pela verificação de assinatura e pela distribuição como binário único multiplataforma.

Resultados

Hosts cloud e on-premise gerenciados pelo mesmo agente, com deploy, métricas e console remoto

Operação unificada

Dados e recursos separados por organização, com perfis de acesso e módulos habilitáveis

Isolamento multi-tenant

Gateway com rotas por domínio e métricas de acesso por endpoint

Publicação com telemetria

Backoffice independente para gestão global de tenants e módulos

Administração separada

Stack

TypeScriptNode.jsExpressPrismaPostgreSQLRedisReactViteGoDockerWebSocketSocket.IOWireGuardTURN

Temas

#multi-tenant#cloud#ci-cd#gateway#edge#observabilidade#segurança#go#typescript

Vamos conversar sobre a próxima oportunidade.

Infraestrutura, IA aplicada, mobile/edge ou integrações críticas — se o desafio exige profundidade, me conte o contexto.

Enviar e-mail Ver outros projetos