Registro do Domínio jedin.io e Infraestrutura DNS Multi-Produto Provisionada

Resumo Executivo

A plataforma JedIN concluiu o registro do domínio oficial jedin.io e provisionou toda a infraestrutura DNS, certificados SSL e identidade de e-mail transacional necessária para sustentar os cinco produtos da plataforma como ofertas comerciais independentes. A sessão também identificou e corrigiu hardcodes no código que poderiam quebrar o modelo multi-tenant em produção, além de coordenar com o programa de identidade centralizada (IAM) que está sendo implementado em paralelo.

O domínio foi registrado pelo período mínimo de um ano, com renovação automática habilitada e proteção de privacidade ativada para evitar exposição de dados pessoais no WHOIS público. A hosted zone que já existia desde o início de março de 2026 foi preservada, e os quatro servidores de nomes originais foram forçados no registrar para manter os registros DNS pré-configurados via Terraform.

Toda a estratégia foi desenhada considerando que cada um dos cinco produtos pode ser comercializado de forma independente. Clientes podem assinar apenas um produto, dois ou todos os cinco, e cada produto tem sua própria URL de acesso para suportar branding individual e futuras integrações white-label com domínios próprios dos clientes.

Por Que jedin.io e Não jedin.com.br

A plataforma JedIN tem ambições internacionais desde o desenho inicial, e o sufixo .io posiciona o produto como uma ferramenta de tecnologia moderna globalmente reconhecível. Apesar do custo anual ligeiramente maior comparado ao .com.br (cerca de 71 dólares contra 30 reais por ano), o .io foi escolhido pelos seguintes motivos.

Primeiro, o domínio jedin.io estava disponível no momento da decisão, o que não é trivial considerando a corrida por nomes curtos no espaço de tecnologia. Segundo, o sufixo .io é amplamente associado a plataformas SaaS B2B, ferramentas de desenvolvedor e produtos de tecnologia, alinhando com o posicionamento da JedIN como plataforma de integração empresarial. Terceiro, suporta naturalmente subdomínios por produto e por cliente sem soar regional demais.

O registro foi feito via Amazon Route 53 Domains, integrado nativamente com o restante da infraestrutura AWS onde a plataforma roda. Isso simplifica a gestão de DNS, certificados SSL e identidade de e-mail, todos no mesmo provedor.

Os Cinco Produtos da Plataforma

A JedIN é uma plataforma com cinco produtos que compartilham a base de identidade, autenticação, billing e infraestrutura, mas funcionam como ofertas comerciais independentes.

O primeiro produto é o JedIN Pages, um construtor de landing pages no estilo do RD Station Pages, voltado para times de marketing que precisam criar páginas de captura, formulários, popups, automações de e-mail e funis de conversão sem depender do time de desenvolvimento. Permite domínio customizado por cliente, integração com Google Analytics, Meta Pixel, Hotjar e webhooks customizados.

O segundo produto é o JedIN SRE (Supplier Relationship & e-Procurement), uma plataforma de gestão de fornecedores e ordens de compra. Inclui portal do fornecedor com fluxo de assinatura digital aderente à MP 2.200-2/2001, integração com SAP Ariba, S/4HANA e ECC, comunicação via WhatsApp Business API, armazenamento de documentos em SharePoint e análise de contratos com IA.

O terceiro produto é o JedIN Utilities (também conhecido como IS-U), voltado para concessionárias de energia elétrica e saneamento. Implementa portal do cliente final, backoffice de operação, integração nativa com SAP IS-U, geração de boletos e PIX, marketplace de energia solar P2P, automações de marketing por segmento e relatórios de conformidade ANEEL DEC/FEC.

O quarto produto é o JedIN Integration, o produto original da plataforma e sua espinha dorsal. Oferece um designer visual de fluxos de integração, mais de 300 conectores via Apache Camel K, paridade com SAP Cloud Platform Integration (CPI), webhook receivers públicos, execução em runtime escalável e ferramentas de observabilidade.

O quinto produto é o R2-CX, uma workspace para analistas de SAP Customer Experience com 14 servidores MCP integrados, automação de navegador via Playwright, geração de código ABSL, análise de qualidade de dados e operações cross-system com 19 ferramentas C4C nativas.

Estratégia de Subdomínios

A decisão arquitetural mais importante da sessão foi adotar subdomínio por produto em vez de path por produto sob um único subdomínio. A diferença entre pages.jedin.io e app.jedin.io/pages parece cosmética, mas tem implicações comerciais significativas.

Subdomínio por produto permite branding individual, suporta white-label via CNAME (cliente pode apontar lp.empresa.com.br para pages.jedin.io), separa cookies de sessão por produto evitando vazamento entre contextos, facilita métricas analíticas por produto e permite escalonamento independente de capacidade no futuro caso um produto cresça mais que outro.

A estrutura final ficou assim. Para o ambiente de teste atual, que compartilha um único load balancer:

Subdomínio	Função
`jedin.io` (apex)	Site institucional e landing page comercial
`dev.jedin.io`	Painel unificado para staff interno
`dev-api.jedin.io`	API REST e WebSocket
`pages.dev.jedin.io`	Acesso dedicado ao produto Pages
`sre.dev.jedin.io`	Acesso dedicado ao produto SRE
`utilities.dev.jedin.io`	Acesso dedicado ao produto Utilities
`flows.dev.jedin.io`	Acesso dedicado ao produto Integration
`r2cx.dev.jedin.io`	Acesso dedicado ao produto R2-CX
`webhooks.dev.jedin.io`	Endpoint para receber webhooks de terceiros (Stripe, SAP, WhatsApp Meta)
`portal.dev.jedin.io`	Portal específico para fluxos de reset de senha em Utilities

Para o ambiente de produção futuro, a estrutura mantém o mesmo padrão removendo apenas o prefixo .dev. O domínio apex jedin.io será o site institucional, app.jedin.io será o painel unificado, api.jedin.io será a API e cada produto terá seu próprio subdomínio: pages.jedin.io, sre.jedin.io, utilities.jedin.io, flows.jedin.io e r2cx.jedin.io.

A hosted zone Route 53 que já existia desde 2 de março de 2026 (criada via Terraform como preparação) foi preservada com seus 21 registros, incluindo dois CNAMEs de validação ACM que ficaram pendentes esperando o domínio entrar no ar. Adicionamos 13 novos registros nesta sessão: oito alias A para os subdomínios de produto apontando ao load balancer, três CNAMEs DKIM do Amazon SES, um TXT SPF no apex e um TXT DMARC.

Certificados SSL Wildcard

A plataforma usa dois certificados wildcard para cobrir todos os subdomínios atuais e futuros sem precisar emitir um certificado por subdomínio.

O primeiro certificado cobre *.dev.jedin.io e dev.jedin.io, ficando responsável por todo o ambiente de teste. O segundo certificado cobre *.jedin.io e jedin.io, ficando responsável pelo ambiente de produção futuro. Ambos foram solicitados via AWS Certificate Manager com validação DNS, que valida automaticamente assim que os CNAMEs de validação resolvem publicamente.

Dois certificados antigos que estavam em estado FAILED foram identificados e deletados. Eles tinham sido criados em fevereiro e março, mas a validação nunca completou porque o domínio ainda não tinha sido registrado. Como certificados em FAILED não podem ser recuperados (estado terminal no ACM), a única opção foi deletar e re-emitir.

O certificado do ambiente de teste foi validado em menos de uma hora após a propagação dos servidores de nomes do registrar para o DNS público, e está em status ISSUED. O certificado de produção segue em PENDING_VALIDATION e deve completar a validação no mesmo período.

Existe ainda um terceiro certificado que será necessário no futuro: um certificado adicional para auth.jedin.io precisa ser emitido especificamente na região us-east-1 para suportar o domínio customizado do hosted UI do Cognito (limitação documentada da AWS). Esse certificado faz parte da fase de hardening do programa IAM e não foi emitido nesta sessão.

Identidade de E-mail Transacional via SES

A plataforma envia e-mails transacionais para várias situações: solicitações de assinatura digital no fluxo SRE, alertas de dashboard agendados diariamente, notificações de cobrança em Utilities, redefinição de senha, confirmações de cadastro e mensagens automatizadas do programa IAM. Para garantir que esses e-mails cheguem nas caixas de entrada dos destinatários (e não no spam), foi configurada uma identidade de domínio completa no Amazon SES.

A configuração inclui três tokens DKIM publicados como CNAMEs no DNS, um registro SPF no apex permitindo o Amazon SES como remetente autorizado, um registro DMARC com política none (apenas observação por enquanto, sem rejeitar e-mails) e um subdomínio dedicado mail.jedin.io com seu próprio MX e SPF para o envelope sender padrão do SES.

O subdomínio mail.jedin.io usado como envelope sender já está com status SUCCESS no SES, o que significa que os e-mails enviados terão um envelope sender alinhado com o domínio jedin.io (importante para passar em verificações DMARC strict de provedores como Gmail). A verificação DKIM da identidade principal (jedin.io) está em PENDING e deve completar na próxima janela de propagação DNS.

Importante: o SES inicia em modo sandbox por padrão, o que significa que e-mails só podem ser enviados para destinatários verificados na própria conta. Para enviar para destinos arbitrários (clientes reais), é necessário solicitar saída do sandbox via AWS Support, justificando o caso de uso (e-mails transacionais), volumes esperados e práticas de gestão de bounces e reclamações. Esse passo será feito quando o programa IAM estiver pronto para enviar e-mails de boas-vindas e reset de senha em produção.

Auditoria dos Cinco Produtos

Antes de aplicar as mudanças de DNS, foi feita uma auditoria sistemática dos cinco produtos para identificar dependências de URL, hardcodes de domínio, callbacks OAuth e webhooks que poderiam quebrar com a migração. A auditoria foi paralela (cinco agentes investigando em simultâneo) e cobriu mais de cento e cinquenta arquivos.

Achados em Pages

O produto Pages tem arquitetura "public-first", com vários endpoints sem autenticação para servir landing pages, embed scripts, formulários e tracking de eventos. Praticamente todas as URLs públicas usam variáveis de ambiente com fallback para https://api.jedin.io, então a migração funciona sem mudanças no código exceto por um caso crítico.

A função que orienta clientes a apontar domínios próprios para o Pages estava retornando como instrução de CNAME um domínio que nunca existiu (jedin-pages.io, com hífen). Clientes que tentassem configurar custom domain seguindo essa instrução cairiam no nada. Foi corrigido para apontar para pages.jedin.io (configurável via variável de ambiente para flexibilidade futura).

O Pages também integra com Stripe para billing, e o webhook do Stripe precisa ser registrado externamente apontando para a URL pública do endpoint /pages/billing/stripe-webhook. Isso será configurado no painel do Stripe quando o billing entrar em uso.

Achados em SRE

O fluxo de assinatura digital do SRE depende de um portal público acessado via token único /sre/sign/[token], que foi auditado e funciona corretamente com URLs relativas (não tem dependência de domínio absoluto). Os e-mails de solicitação de assinatura, no entanto, tinham um link hardcoded para https://app.jedin.io/sre/dashboard, que foi corrigido para usar variável de ambiente com fallback para o subdomínio dedicado sre.dev.jedin.io.

A integração com SAP Ariba, ECC e S/4HANA já usa variáveis de ambiente para todas as URLs base. A integração com SharePoint segue o padrão OAuth do Microsoft Graph e o redirect URI é registrado no Azure AD App Registration (fora do código). O WhatsApp Business API só envia mensagens (não recebe), então não precisa de webhook receiver público.

O servidor MCP do SRE roda em porta interna 3361 dentro do cluster Kubernetes e não precisa de exposição pública. As 44 ferramentas disponíveis para o servidor MCP do SRE atendem fornecedores, operadores e administradores via filtro de escopo.

Achados em Utilities

O Utilities tinha o problema mais grave da auditoria: dois pontos no código (linhas 251 e 342 do serviço de WhatsApp) faziam referência hardcoded a https://portal.cemig.com.br/negociacao. Isso significa que se a plataforma fosse demonstrada para qualquer cliente que não fosse a concessionária mineira em questão, os clientes finais receberiam por WhatsApp uma mensagem orientando a acessar o portal de uma concessionária terceira. Vazamento multi-tenant flagrante.

Foi corrigido para usar variável de ambiente UTILITIES_TENANT_PORTAL_URL com fallback para o subdomínio genérico portal.dev.jedin.io/utilities/negociacao. Para o longo prazo, foi anotada uma dívida técnica para tornar essa configuração tenant-specific via banco de dados, eliminando completamente o uso de variável de ambiente para um valor que naturalmente deveria ser dinâmico por concessionária.

A função de reset de senha do Utilities também tinha um fallback hardcoded para https://portal.jedin.io, um subdomínio que não estava na minha lista original de subdomínios planejados. Foi adicionado portal.dev.jedin.io como subdomínio dedicado para preservar essa funcionalidade.

A chave PIX hardcoded pagamentos@jedin.io ficou marcada como dívida técnica: precisa ser dinâmica por tenant (cada concessionária tem sua própria conta bancária), mas requer mais que um simples envvar.

Achados em Integration

O produto core JedIN tem cinco endpoints de webhook receivers públicos (GET, POST, PUT, PATCH, DELETE em /webhooks/:flowId) que aceitam triggers de fluxos disparados por sistemas terceiros. Eles precisam de exposição HTTPS pública, e a estratégia adotada foi criar um subdomínio dedicado webhooks.dev.jedin.io para isolar essa função do resto da API.

O endpoint genérico de OAuth callback /api/v1/connections/{id}/oauth2/callback é usado quando um usuário conecta sua conta SAP, Salesforce ou outro sistema OAuth via UI. A URL de callback é construída a partir da variável API_BASE_URL, que precisará apontar para dev-api.jedin.io no ambiente de teste.

Os servidores MCP (mcp-jedin com 79 ferramentas, mcp-cpi com 47 ferramentas, mcp-c4c com 17 ferramentas) rodam em portas internas e são consumidos via Claude Code ou via SSE. Não precisam de exposição pública direta.

A documentação Swagger/OpenAPI fica exposta em /api/docs e atende como referência para clientes que vão consumir a API JedIN programaticamente.

Achados em R2-CX

O R2-CX foi recentemente refeito para trabalhar sem o componente OpenClaw, que era usado anteriormente como gateway para automação de navegador. O resíduo desse componente ainda existe no cluster Kubernetes (deployment jedin-openclaw com 0 réplicas, nodegroup spot dedicado vazio) e em três arquivos do frontend que ainda referenciam a antiga taxonomia. Foi anotado para cleanup posterior, mas não bloqueia o registro do domínio.

O widget flutuante do R2-CX é incorporável em outros produtos: aparece no Pages, no SRE Workspace e no backoffice do Utilities. Quando incorporado, ele faz POST para /r2cx/chat com o parâmetro targetSystem indicando o contexto (pages, sre ou isu), permitindo que o consultor autônomo entenda em qual produto está atuando.

A comunicação em tempo real do R2-CX usa Server-Sent Events em vez de WebSocket, com keepalive de 25 segundos para evitar timeout do CloudFront (que é 60 segundos). Isso simplifica o atravessamento de proxies corporativos.

Correções de Código Aplicadas

Quatro arquivos foram corrigidos nesta sessão, todos com mudanças não-disruptivas (fallbacks via variável de ambiente). As mudanças foram empacotadas em um único commit assinado com mensagem feat(infra): jedin.io registered + dev subdomains live, que serviu de sinal verde para o terminal paralelo aplicar a configuração do Cognito.

A primeira correção foi no serviço de domínio do Pages, mudando o target do CNAME de jedin-pages.io (domínio inexistente) para process.env.PAGES_CUSTOM_DOMAIN_TARGET || 'pages.jedin.io'.

A segunda correção foi no canal de e-mail do SRE, transformando o link hardcoded do dashboard em ${process.env.SRE_DASHBOARD_URL || process.env.APP_BASE_URL || 'https://sre.dev.jedin.io'}/sre/dashboard.

A terceira correção foi no serviço de WhatsApp do Utilities, removendo a URL hardcoded de uma concessionária terceira em duas linhas e substituindo por process.env.UTILITIES_TENANT_PORTAL_URL || 'https://portal.dev.jedin.io/utilities/negociacao'.

A quarta correção foi no arquivo principal da API, expandindo a lista de origens permitidas pelo CORS para incluir uma regex que aceita qualquer subdomínio HTTPS de jedin.io (/^https:\/\/([a-z0-9-]+\.)*jedin\.io$/), além das origens localhost e do load balancer já aceitas anteriormente.

Coordenação com o Programa IAM

Em paralelo a essa sessão de infraestrutura, está rodando o programa de identidade e acesso centralizado da JedIN. O programa visa unificar quatro silos de autenticação atualmente paralelos (User principal do JedIN, PagesUser do Pages, UtilityCustomer do Utilities e SreSupplierUser do SRE) através do AWS Cognito como provedor único de identidade.

A coordenação entre as duas sessões foi crítica porque o Cognito precisa de URLs de callback explícitas para cada subdomínio onde a aplicação web pode receber o redirect após autenticação. A lista final ficou com sete callbacks para o painel staff (dev.jedin.io mais os cinco subdomínios de produto mais o portal de Utilities), três callbacks para o portal de fornecedores SRE (incluindo o fluxo público de assinatura digital), três callbacks para o portal do cliente Utilities, e localhost para desenvolvimento local.

Foi entregue ao programa IAM um briefing completo contendo o arquivo terraform.tfvars pronto para uso em ambiente dev, instruções para staging e prod (substituindo dev.jedin.io por staging.jedin.io e app.jedin.io respectivamente), a configuração de envio de e-mail via SES quando a verificação DKIM completar, e a recomendação de não aplicar Terraform até confirmar que os subdomínios estão resolvendo publicamente.

O sinal verde para o programa IAM aplicar sua configuração foi entregue via mensagem de commit no Git, evitando dependência de canal externo de comunicação.

Pegadinhas Resolvidas

A sessão expôs várias pegadinhas que valem ser documentadas para evitar repetição em futuras operações similares.

Hosted Zone Duplicada Auto-Criada

Quando um domínio é registrado via AWS Route 53 Domains com uma hosted zone preexistente para o mesmo nome, a AWS cria automaticamente uma segunda hosted zone com servidores de nomes diferentes e configura o registrar para apontar para essa nova hosted zone. Isso quebra silenciosamente qualquer pré-configuração feita na hosted zone original.

A solução foi forçar a atualização dos servidores de nomes no registrar via comando update-domain-nameservers apontando para os servidores da hosted zone original (ns-1284.awsdns-32.org, ns-585.awsdns-09.net, ns-213.awsdns-26.com e ns-2037.awsdns-62.co.uk). Isso preservou os 21 registros pré-configurados (incluindo dois CNAMEs de validação ACM) e descartou a hosted zone duplicada.

A hosted zone duplicada (com apenas dois registros default NS+SOA) foi posteriormente deletada via comando delete-hosted-zone para evitar confusão futura ou cobrança desnecessária.

Banco de Dados sem Tabela de Controle de Migrations

O banco de dados PostgreSQL de desenvolvimento da plataforma foi historicamente mantido via comando prisma db push, que sincroniza o schema diretamente sem criar registros na tabela de controle _prisma_migrations. Isso significa que a primeira migration versionada do programa IAM não pôde ser aplicada via prisma migrate deploy (que esperaria a tabela existir).

A solução foi aplicar a migration via prisma db execute --file <migration.sql> diretamente no SQL. Para o futuro, foi anotado como dívida técnica criar uma migration baseline (capturando o estado atual do schema) e usar prisma migrate resolve --applied para registrar essa baseline na tabela de controle, permitindo que migrations futuras voltem a usar migrate deploy normalmente.

Como o RDS não é publicamente acessível (só responde de dentro da VPC AWS), as migrations precisam ser executadas via kubectl exec em um pod que já roda no cluster e tem acesso de rede ao banco.

Cache de Build Stale Quebrando Pre-Push Hook

A primeira tentativa de push falhou no pre-push hook com dois erros de webpack reportando módulos não encontrados em arquivos do programa IAM. A investigação mostrou que o conteúdo real dos arquivos estava correto ('../../prisma/prisma.service'), mas o webpack estava reportando erro com um caminho diferente ('../prisma/prisma.service').

A causa raiz foi cache stale do turbo (em apps/api/.turbo/ e apps/api/dist/) deixado por uma execução anterior do build em outra sessão paralela. A solução foi limpar os caches (rm -rf apps/api/dist apps/api/.turbo) e re-executar o push, que então passou em todos os 14 pacotes do monorepo.

Terraform Aplicando na Região Errada

A configuração inicial do módulo Terraform do programa IAM não tinha um bloco provider "aws" explícito, o que fez o Terraform usar a região default do AWS CLI. Como a configuração local estava com us-east-1 como default, o User Pool do Cognito foi criado em N. Virginia em vez de São Paulo.

Foram criados 29 dos 30 recursos planejados em região errada antes do erro ser detectado. O destroy precisou ser feito com override de variável (TF_VAR_region=us-east-1 terraform destroy -auto-approve) porque o provider já tinha sido corrigido para sa-east-1 e tentaria destruir em São Paulo recursos que estavam em N. Virginia.

A correção definitiva foi adicionar um bloco provider "aws" { region = var.region } no Terraform, garantindo que toda execução futura use a região correta independente do ambiente do CLI.

Estado Final e Próximos Passos

Ao final da sessão, o domínio jedin.io está registrado e ativo, com os 4 servidores de nomes corretos publicados no DNS público globalmente. A hosted zone Route 53 contém 21 registros, cobrindo todos os subdomínios de produto, certificados ACM (validação) e identidade SES (DKIM, SPF, DMARC, Mail-From).

O certificado SSL wildcard para o ambiente de teste já está em status ISSUED. O certificado wildcard para produção está validando e deve completar em menos de uma hora. A identidade SES tem o subdomínio mail.jedin.io validado e está aguardando a verificação DKIM completar.

Todas as correções de código foram empacotadas em um único commit no branch principal, sem quebrar testes (passou em 145 suites com 3116 testes durante o pre-push hook). O programa IAM em paralelo já recebeu o sinal verde, aplicou a migration do banco de dados, ajustou seu Terraform para a região correta após a pegadinha inicial, e está em sequência para aplicar a configuração final do Cognito.

Os próximos passos pendentes incluem aguardar a validação completa de DKIM e do certificado wildcard de produção (10 a 30 minutos), fazer cleanup do resíduo OpenClaw no cluster Kubernetes (deployment com 0 réplicas, service órfão, nodegroup vazio), tratar dívidas técnicas anotadas (TENANT_ID hardcoded em vários services do SRE, ALB DNS em CORS, baseline de migrations Prisma), e quando o programa IAM completar a fase 7 de hardening, emitir certificado adicional na região us-east-1 para suportar o domínio customizado auth.jedin.io do hosted UI do Cognito.

Para sair do sandbox do SES e enviar e-mails para destinatários arbitrários em produção, será necessário abrir um ticket de aumento de limite no AWS Support, justificando o caso de uso transacional, volumes esperados e práticas de gestão de bounces. Esse passo deve ser feito quando o programa IAM estiver pronto para enviar e-mails de boas-vindas e reset de senha em produção real.

A infraestrutura está pronta. Os cinco produtos da plataforma JedIN agora podem ser comercializados de forma independente, com URLs próprias, branding individualizado, certificados SSL válidos e infraestrutura de e-mail transacional configurada conforme as melhores práticas de entregabilidade. A coordenação com o programa de identidade centralizada está alinhada para sustentar o modelo de cliente com múltiplos produtos contratados.