> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-docs/product-guide/configuracoes/rmm/custom-domain.md).

# Custom Domain

Sirva o RMM no domínio da própria organização — `mdm.acme.com` em vez do domínio compartilhado.

Aberta em `/custom-domain`.

## Como funciona

1. Você declara o domínio desejado
2. O RMM gera um **token de verificação** único
3. Você adiciona **2 registros DNS**:
   * `CNAME` — aponta o subdomínio pra hospedagem compartilhada
   * `TXT` — em `_datadike-verify.<seu-domínio>`, com o valor do token
4. Clica **Verify DNS ownership** — o RMM resolve os dois registros e libera
5. Configura o **certificado TLS** e o **reverse proxy** do seu lado (guia abaixo)

## Registros DNS que a página gera

Quando você salva o domínio, a página mostra a tabela pronta pra colar no seu provedor DNS:

| Host                            | Type  | Value                 |
| ------------------------------- | ----- | --------------------- |
| `mdm.acme.com`                  | CNAME | `mobile.datadike.com` |
| `_datadike-verify.mdm.acme.com` | TXT   | `ddvfy-<token único>` |

## Divisão de responsabilidades

O RMM controla apenas a **camada de aplicação** — dado um `Host: mdm.acme.com` entrante, ele resolve pra qual tenant pertence e serve as páginas corretas com branding, login e SSO daquele tenant.

A **camada de infra** (TLS + roteamento HTTP) é do cliente. Existem dois caminhos comuns:

### Caminho A — Cloudflare (mais rápido)

1. Adicione o domínio na Cloudflare
2. CNAME `mdm.acme.com` → `mobile.datadike.com`
3. SSL mode: **Full (strict)**
4. Cloudflare emite o certificado edge gratuitamente

O reverse-proxy DataDike aceita a requisição desde que o SNI/TLS bata com o certificado da Cloudflare. Não precisa configurar nada do nosso lado.

### Caminho B — reverse proxy próprio (mais controle)

1. Emita seu próprio certificado (ACM, Let's Encrypt, etc.)
2. Configure nginx / ALB / HAProxy fazendo `proxy_pass` pro nosso backend
3. **Preserve o header `Host`** — o RMM usa ele pra decidir qual tenant serve

Exemplo nginx:

```nginx
server {
    server_name mdm.acme.com;
    ssl_certificate     /etc/ssl/mdm.acme.com.crt;
    ssl_certificate_key /etc/ssl/mdm.acme.com.key;

    location / {
        proxy_set_header Host mdm.acme.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_pass https://mobile.datadike.com;
    }
}
```

## Multi-tenancy garantida

* Um domínio só pode ser reivindicado por um tenant. Se outro tentar reivindicar o mesmo, o RMM devolve 409 com mensagem explicando
* **Verificação DNS obrigatória** — nada é roteado antes do TXT confirmar
* O índice global de domínios mapeia `mdm.acme.com` → tenant específico. Se alguém subir Host header diferente, o RMM 404

## Página de login em custom domain

Quando o usuário entra em `mdm.acme.com`, a página de login chama `/api/v1/public/tenant-for-host` e:

* Descobre qual tenant é dono do domínio
* Pré-preenche a workspace para o botão "Sign in with SSO"
* Mostra o branding (logo + nome) do tenant

Domínio compartilhado (`mobile.datadike.com`) continua funcionando pra todos — não é obrigatório usar custom domain.

## O que quebra se você desativar

* Envio de convites: os links continuam usando o `PUBLIC_APP_URL` configurado (default `mobile.datadike.com`). Emails enviados enquanto o custom domain estava ativo continuam válidos, mas apontam pro custom domain — atenção se você desativar antes que os convites expirem
* SSO callback: precisa que a URL registrada no IdP bata com o domínio ativo

## Sem downtime

Ligar / desligar custom domain é atômico. Sessões ativas seguem funcionando; a mudança só afeta a próxima requisição.