Sua marca por fora. Sua infraestrutura por dentro.
Cada comunidade recebe um Postgres e dois containers próprios, com senha, chave de sessão e chaves de push geradas na hora — não um espaço reservado dentro do servidor de outra pessoa. A marca vai do domínio ao remetente do e-mail.
Esta página desce a camada da marca na ordem em que ela é percebida: o endereço, a superfície, o remetente. Depois lista, com o caminho do arquivo, o que é compartilhado entre clientes. E fecha com o que ela se recusa a prometer.
Um banco de dados para você. Não um lugar reservado no banco de outra pessoa.
Quando o pagamento confirma, o provisionamento executa nove passos.
O passo 3 cria um Postgres exclusivo da sua comunidade, com senha gerada na hora: 24 bytes aleatórios que nenhuma pessoa digitou nem guardou num documento. O passo 6 sobe o container da sua API com o seu DATABASE_URL, um JWT_SECRET de 32 bytes só seu e um par de chaves VAPID gerado para a sua comunidade naquele instante — as notificações push dos seus membros são assinadas por uma chave que não existe em nenhum outro cliente. O passo 7 sobe o container do site, com o seu domínio. O passo 8 faz o deploy dos dois e acompanha o status de cada um até responder healthy: doze checagens de dez segundos, com até dois redeploys automáticos se algum subir quebrado.
O banco do cliente ao lado é outro processo, outro volume, outra senha. Uma consulta pesada dele acontece no Postgres dele.
O provisionamento também é retomável: passos já concluídos são pulados, e um passo isolado pode ser reexecutado sem refazer os anteriores.
O isolamento aqui é de infraestrutura, não de coluna. O que está separado é o deploy — banco, containers e segredos —, não a modelagem do dado.
O endereço é seu. E o certificado é conferido antes de o link sair.
O domínio próprio se resolve dentro do painel, em /admin/domain, sem abrir chamado. A tela mostra os dois CNAMEs que você precisa criar — o seu domínio e api.seudominio — e o destino de cada um. Você salva e o provisioning troca o domínio dos dois containers, reescreve API_URL e NEXT_PUBLIC_API_URL no site, CORS_ORIGINS e APP_URL na API, e reinicia os dois.
No primeiro provisionamento existe uma etapa a mais. Antes de marcar a sua comunidade como pronta, o sistema faz um GET real em https:// no domínio do site e no da API. Certificado ainda não emitido, ou o self-signed padrão, derruba o handshake — e ele tenta de novo a cada cinco segundos, até 36 vezes, por endereço.
Na prática, essa etapa existe para você não receber uma URL que abre com aviso de conexão não privada na primeira vez que um aluno clica.
É uma verificação, não uma trava. Esgotadas as tentativas sem certificado válido, o código registra um aviso e segue em frente em vez de falhar o provisionamento inteiro — ela reduz a chance do erro, não garante que ele nunca aconteça.
De três cores a quinze. Você escolhe onde parar.
Modo simples: três cores e acabou. Modo avançado: quinze cores nomeadas — primária, secundária, acento, sucesso, aviso, erro, informação, três de fundo, três de texto e duas de borda — com um conjunto separado para o tema escuro. Mais tipografia: fonte principal, fonte de título e monoespaçada, com 25 famílias para texto, 8 para título e 9 monoespaçadas, além de tamanho-base, escala tipográfica, pesos e altura de linha. Mais layout: escala de raio de borda e de sombra.
A identidade fica na mesma tela: nome da comunidade, tagline, logo, favicon, banner, e se o logo aparece com ou sem o nome ao lado.
O favicon e a imagem de OpenGraph não param no preview. O servidor do Next consulta a aparência da comunidade e monta o ícone da aba, o título, a descrição e o card do link compartilhado. Quem recebe o link do seu curso no WhatsApp vê a sua imagem.
Cada estado vira uma versão nomeada que você restaura depois, e o tema inteiro exporta e importa em JSON. A tela de login e cadastro tem customização própria: fundo, textura, imagem lateral, textos e cartão.
A customização da tela de login para em dois layouts, centralizado e dividido. Não existe um terceiro no painel.
O e-mail sai com o seu nome. O domínio, depois que você ligar o seu SMTP.
Aqui vale ser exato, porque é o ponto em que quase toda plataforma exagera.
Por padrão, o e-mail transacional funciona desde o primeiro minuto, sem você configurar nada. Ele sai pela plataforma, com o nome da sua comunidade no remetente e o endereço no domínio mail.mentorflix.io usando o seu slug, com reply-to no e-mail do dono da comunidade. O nome que o aluno lê é o seu. O domínio, nesse estágio, não é.
Quando você preenche host, porta, credenciais e o campo “De” e liga o envio próprio nas configurações, a cascata muda: o envio passa inteiro pelo seu servidor SMTP, com o remetente que você escreveu.
Onze tipos de e-mail são editáveis por você: convite, boas-vindas, redefinição de senha, digest semanal, badge conquistado, RSVP e lembrete de evento, resumo de notificações, comunicado, início de desafio e menção. Cada um traz as variáveis disponíveis documentadas, guarda versões, restaura uma versão anterior, volta ao padrão e dispara um teste antes de você publicar.
O campo “De” importa. Deixado em branco, o envio cai num remetente genérico da plataforma em vez do seu domínio.
O que é compartilhado entre clientes. Com o caminho do arquivo.
A primeira seção desta página listou o que roda só para você. Esta lista o resto, porque uma lista sem a segunda metade não vale nada.
A mídia é compartilhada. Imagem e vídeo vão para uma storage zone e uma biblioteca de vídeo da plataforma no Bunny, as mesmas para todos os clientes, com os arquivos separados em pasta pelo seu slug, em comunidades/seu-slug/.
O envio padrão de e-mail usa uma conta Resend da plataforma até você ligar o seu SMTP, como a seção anterior descreveu.
E o marketplace entre membros liquida pela conta Stripe da plataforma, via Connect.
Se alguém afirmar que tudo é dedicado, peça o caminho do arquivo.
É nesses três pontos que o isolamento da primeira seção para. O que é seu na mídia é o caminho da pasta, não a zona.
O que esta página não vai te prometer.
Quatro afirmações comuns no mercado que não conseguimos sustentar com o código na mão, então não fazemos.
A primeira é backup. Não existe rotina de backup no repositório. Se ela existe, vive na configuração do servidor, fora daqui — e não vamos vender uma política que não está escrita em lugar nenhum que você possa auditar.
A segunda é monitoramento e alerta. Também não há código de observabilidade nem de alerta no produto.
A terceira é LGPD. Não existe fluxo de consentimento, portabilidade ou exclusão a pedido do titular dentro da plataforma.
A quarta é exportação. O que sai hoje é analytics em CSV, por lente: crescimento, engajamento, retenção, conteúdo e gamificação. Não há exportação de membros nem de conteúdo. Prometer que não existe aprisionamento com isso na mão seria mentira.
Mais quatro detalhes pequenos e reais: a checagem de HTTPS roda no provisionamento inicial, não na troca de domínio posterior; as esperas por container e por certificado degradam em aviso no log em vez de falhar; o campo de componentes da aparência existe no banco mas não tem editor no painel; e as métricas de CPU e memória do seu container existem como endpoint na sua própria API, sem tela que as mostre.
Nenhum número de disponibilidade aparece nesta página porque nenhum foi medido.
Continua em
Preço fixo por estrutura dedicada só fecha a conta se ninguém tirar percentual da sua venda. Como a venda funciona: 01 · Vendas →
A marca aparece no convite, no espaço e na lista de membros. Como cada um deles é configurado: 03 · Comunidades →