Configuração de domínio personalizado para apps web com passos claros de registros DNS, emissão de SSL, redirecionamentos e um plano de migração de baixo risco para evitar downtime e problemas com cookies.
Um domínio personalizado é mais que uma URL mais bonita. No momento em que você sai do endereço da plataforma (por exemplo, um app que você construiu no Koder.ai sob um subdomínio da plataforma) para o seu próprio domínio, navegadores e redes passam a tratar como um site diferente. Isso afeta roteamento, segurança e o comportamento de sessões de usuário.
Assim que você troca para um domínio personalizado, algumas coisas mudam imediatamente:
www ou no domínio apex, e precisa de regras consistentes de HTTP para HTTPS.old-platform.example não funcionará automaticamente em app.yourdomain.com.Quedas curtas geralmente vêm do tempo das mudanças. O DNS pode começar a encaminhar tráfego para o novo host antes do certificado SSL estar pronto, o que gera avisos do navegador. Ou o contrário: o SSL fica pronto, mas muitos usuários ainda entram no local antigo porque o cache DNS não expirou.
Redirecionamentos também podem quebrar logins de forma sutil. Um redirecionamento que troca o hostname (apex para www, ou o inverso) pode fazer cookies sumirem se foram definidos para o outro host. Provedores de autenticação podem falhar se a URL de callback continuar sendo o domínio antigo.
Uma migração de baixo risco significa planejar sobreposição: mantenha a URL antiga funcionando, leve o novo domínio no ar em paralelo, troque o tráfego em um momento previsível e torne o rollback tão simples quanto trocar o DNS de volta.
Antes de mudar qualquer coisa, escreva exatamente quais nomes você quer que usuários digitem e quais devem redirecionar silenciosamente. A maioria dos momentos de “por que isso está funcionando pela metade?” vem de equipes que nunca concordaram num único hostname verdadeiro.
Comece pela escolha principal: apex (example.com) ou www (www.example.com) como o primário. Ambos funcionam, mas escolha um e trate o outro como redirecionamento. Isso importa depois para cookies também: sessões geralmente são mais simples quando o app vive em um host consistente.
Depois, decida quais subdomínios você precisa agora e quais podem esperar. Um padrão comum é app.example.com para o web app e api.example.com para APIs, com admin.example.com ou assets.example.com adicionados depois. Se você está configurando um domínio personalizado em uma plataforma como o Koder.ai, essas escolhas mapeiam diretamente para o que você validará para SSL e para o que apontará no DNS.
Muita gente compra um domínio no registrador, mas o DNS pode ser hospedado em outro lugar. Confirme onde os registros são editados hoje, quem tem acesso e se há automação gerenciando mudanças (TI da empresa, uma agência ou um provedor DNS gerenciado). Se você não consegue entrar e ver os registros atuais, pare e resolva isso primeiro.
Audite também o que já usa o domínio. E‑mail é a armadilha clássica: você pode quebrar a entrega de emails deletando ou sobrescrevendo registros.
Antes de prosseguir, registre essas decisões por escrito:
www) e a direção do redirecionamentoSe o time de marketing já roda email em example.com, mantenha os registros de mail intactos enquanto adiciona apenas o que o app precisa.
A maior parte do risco em uma mudança de domínio personalizado não é o app em si. É uma alteração errada no DNS que manda o tráfego para lugar nenhum, quebra e‑mail ou faz a validação do SSL falhar.
Um A record aponta um nome para um endereço IP. Em termos simples: “mande as pessoas para este servidor.” É comum para o apex (example.com) quando seu provedor dá um IP fixo.
Um CNAME record aponta um nome para outro nome. Em termos simples: “trate este nome como um alias daquele hostname.” É comum para www.example.com apontando para um hostname da plataforma.
Muitos provedores DNS também oferecem ALIAS/ANAME no apex. Ele se comporta como um CNAME mas funciona para example.com. Se seu provedor suportar, pode ser mais fácil de gerenciar porque o alvo pode se mover sem você mexer em IPs.
Um modelo mental simples:
Você frequentemente adicionará TXT para checar propriedade (verificação de plataforma) e para validação de certificados SSL (algumas CAs validam via token TXT). TXT também é usado para políticas de email como SPF. Deletar ou substituir um SPF existente por engano pode quebrar entrega de email.
TTL controla por quanto tempo outros sistemas cacheiam sua resposta DNS. Um dia antes do corte, reduza o TTL nos registros que você planeja mudar (comum: 300 a 600 segundos). Depois que tudo estiver estável, aumente de novo para reduzir carga de consultas.
Antes de editar, exporte ou faça screenshots da zona atual. Anote cada registro que você vai mudar, o valor antigo, o novo valor e o TTL. Se algo der errado, o rollback é restaurar os valores anteriores.
Isso é especialmente importante quando seu domínio já tem MX, DKIM ou outros TXT para e‑mail.
SSL (o cadeado) criptografa o tráfego entre o navegador e seu app. Navegadores modernos e muitas APIs esperam HTTPS por padrão. Sem ele, há avisos, requisições bloqueadas e recursos como service workers, geolocalização e alguns fluxos de pagamento podem parar de funcionar.
Para emitir um certificado, a autoridade certificadora precisa verificar que você controla o domínio. Os métodos comuns são validação via HTTP e via TXT no DNS:
A validação via DNS costuma ser mais simples quando você usa um CDN ou quando seu app ainda não é alcançável pelo novo domínio.
Onde o certificado é emitido depende da sua arquitetura. Algumas equipes emitem certificados no próprio stack de hosting, outras no CDN, e algumas plataformas que suportam domínios personalizados cuidam disso para você (por exemplo, o Koder.ai pode gerenciar o certificado durante a configuração do domínio). O que importa é saber quem é responsável pelo ciclo de vida do certificado, incluindo renovações.
A emissão nem sempre é instantânea. Propagação DNS, checagens de validação e limites de taxa podem atrasar. Planeje tentativas repetidas e evite marcar o corte para o último minuto.
Um plano prático de tempo:
Um certificado precisa cobrir todo hostname que os usuários irão acessar. Verifique a lista SAN (Subject Alternative Names). Se seu app estará acessível em example.com e www.example.com, o certificado deve incluir ambos.
Curingas (como *.example.com) ajudam para muitos subdomínios, mas não cobrem o domínio apex (example.com).
Exemplo concreto: se você emitir um certificado apenas para www.example.com, usuários que digitarem example.com ainda verão avisos, a menos que você redirecione em uma camada que já tenha certificado válido para example.com.
Redirecionamentos parecem simples, mas é onde surgem a maioria dos problemas: loops, conteúdo misto e usuários sendo deslogados por pularem entre hosts.
Escolha um host canônico e mantenha‑se nele: www.example.com ou example.com (apex). O outro ponto de entrada deve redirecionar para o host canônico para que cookies, sessões e sinais de SEO se mantenham consistentes.
Defaults seguros:
http:// para https:// em todas as requisiçõesPara HTTP → HTTPS, evite regras que façam os usuários irem e voltarem. A forma mais fácil de prevenir loops é basear a decisão no que a requisição realmente foi. Se sua app está atrás de um proxy ou CDN, configure para respeitar headers encaminhados (por exemplo, um header que indica que o esquema original era HTTP). Caso contrário, sua app pode achar que toda requisição é HTTP e continuar redirecionando indefinidamente.
Durante uma migração, mantenha caminhos antigos ativos. Se você estiver mudando rotas (como /login para /sign-in), adicione redirecionamentos explícitos para essas rotas. Não conte com um redirecionamento genérico para a homepage — isso quebra bookmarks e links compartilhados.
Segure o uso de HSTS no início. Se habilitar cedo demais e depois precisar servir HTTP para validação ou troubleshooting, navegadores podem recusar. Espere até que o HTTPS esteja estável e você tenha confirmado a cobertura de subdomínios.
Para testar redirecionamentos sem impactar todos, use um hostname de teste temporário, experimente alguns deep links reais (incluindo páginas de autenticação) e rode uma requisição em linha de comando que mostre cada etapa de redirecionamento e o destino final.
Uma migração segura é principalmente sobre timing. Você quer que o novo domínio esteja pronto e testado antes que usuários reais sejam enviados para ele, e quer que mudanças DNS se espalhem rápido para não ficar esperando durante um incidente.
Reduza seu TTL (nos registros que irá mudar) com antecedência. Faça isso no dia anterior se possível, e espere a janela do TTL antigo expirar para que caches atualizem com o novo valor.
Em seguida, adicione o domínio no seu host/provedor e conclua a verificação que solicitarem. Se estiver usando uma plataforma como o Koder.ai, adicione o domínio lá primeiro para que a plataforma confirme propriedade e prepare o roteamento.
Emita o SSL cedo. Certificados podem levar minutos ou mais, dependendo da validação, e você não quer esse atraso no momento da troca.
Antes de tornar o domínio público, faça um teste privado: acesse o novo endpoint de modo que não dependa do DNS público (por exemplo, usando uma entrada temporária de hosts na sua máquina) e confirme que o site carrega via HTTPS com o certificado correto.
Use uma abordagem em etapas para poder parar rápido se algo parecer errado:
www) antes de mudar usuários.Se não for possível um canary verdadeiro no nível DNS, você ainda pode escalonar mudando apenas um hostname primeiro (por exemplo, www) e deixando o apex intacto até ganhar confiança.
Anote exatamente o que vai reverter (quais registros, quais valores) e quem fará isso. Rollback normalmente é restaurar o DNS como era.
Assegure que a configuração antiga ainda esteja válida (incluindo SSL no domínio antigo) para que usuários possam voltar limpo enquanto você corrige o novo caminho.
Uma troca de domínio não é só uma alteração de DNS. Para muitos apps, “estar logado” depende de cookies que navegadores amarram a um hostname específico. Se você muda de hostname, o navegador pode parar de enviar os cookies antigos e sua app parecerá ter deslogado todo mundo.
As configurações de cookie são geralmente a causa:
app.old.com não será enviado para app.new.com. Um cookie definido para .example.com pode funcionar entre app.example.com e www.example.com./api), a UI web pode não enxergá‑lo.Lax costuma ser suficiente, mas alguns SSO ou pagamentos podem precisar de None + Secure.Para reduzir risco, planeje uma transição curta onde ambos os domínios funcionem. Mantenha o hostname antigo respondendo e redirecionando com cuidado, mas permita que sessões sejam renovadas no novo domínio. Se possível, use um store de sessão compartilhado para que um usuário que chegue por qualquer hostname seja reconhecido.
Se você usa SSO ou OAuth, atualize configurações antes do corte: URLs de callback, origins permitidos e qualquer allowlist de redirect URIs. Caso contrário, logins podem ser bem sucedidos no provedor de identidade mas falhar ao retornar para sua app.
Teste os fluxos que costumam quebrar primeiro: cadastro (e verificação por e‑mail), login/logout, recuperação de senha, checkout ou retorno de pagamento, e sessões em múltiplas abas.
Exemplo: se você redireciona www.example.com para example.com, certifique‑se de definir cookies para .example.com (ou use um hostname consistente). Caso contrário, usuários pulam entre hosts e perdem a sessão.
A maioria dos problemas de domínio não é “misterioso”. São pequenas incompatibilidades entre DNS, certificados e regras de redirecionamento que só aparecem com usuários reais.
Uma armadilha fácil é o domínio apex (example.com). Muitos provedores DNS não permitem um CNAME verdadeiro no apex. Se você tentar forçar um CNAME no apex, pode falhar silenciosamente, resolver de forma inconsistente ou quebrar apenas em algumas redes. Use o que seu host DNS suporta (frequentemente um A/AAAA, ou um registro ALIAS/ANAME).
Outra causa frequente de downtime é trocar o DNS antes do SSL estar pronto no novo endpoint. Usuários chegam, a app carrega e o navegador bloqueia porque o certificado falta ou cobre apenas parte dos hostnames. Na prática, normalmente você quer o certificado cobrindo tanto example.com quanto www.example.com, mesmo se planejar redirecionar um para o outro.
Erros comuns que criam downtime ou comportamento estranho:
www → apex, então apex de volta para www) ou forçar HTTP em um lugar e HTTPS em outrohttp:// em assets, o que provoca avisos do navegador e recursos quebradosUm check rápido de sanidade: abra ambos os hostnames (www e apex) via HTTPS, faça login, atualize e confirme que a barra de endereço não volta para HTTP.
Se estiver fazendo isso em uma plataforma como o Koder.ai, confirme que domínios personalizados estão conectados e que o SSL foi emitido antes de mexer no DNS de produção, e mantenha uma opção de rollback pronta para que um redirecionamento ruim ou mudança de registro não fique pendente.
Uma migração calma é principalmente trabalho de preparação. O objetivo é simples: usuários devem continuar logando, cookies devem continuar funcionando e você precisa poder reverter rápido se algo estiver errado.
Faça isto enquanto o tráfego ainda vai para o domínio antigo. Dê pelo menos um dia se puder, para que mudanças DNS tenham tempo de assentar.
www, api, etc.) e escolha o método de validação SSL (DNS ou HTTP).www → apex (ou o inverso) e um host canônico.Quando você trocar o DNS, trate a primeira hora como um exercício de incidente. Observe fluxos reais de usuário, não só dashboards de status.
Mesmo que o Koder.ai (ou outra plataforma) trate domínios personalizados e SSL para você, essa checklist continua válida. A maioria dos problemas vem de DNS e redirecionamentos, não do código da app.
Seu app roda em um endereço temporário da plataforma como myapp.koder.ai. Está funcionando, mas você quer que clientes usem example.com, com www.example.com redirecionando para o apex, e tudo forçado para HTTPS.
Um plano DNS simples mantém o risco baixo. Antes de mudar qualquer coisa, registre o estado atual (tire snapshot se sua plataforma suportar, como o Koder.ai faz) e reduza o TTL para algo curto um dia antes.
Adicione os novos registros deixando a URL da plataforma intacta:
example.com: registro A/ALIAS apontando para o alvo de hosting que sua plataforma fornecewww.example.com: CNAME apontando para example.com (ou para o alvo da plataforma, dependendo do provedor)myapp.koder.ai como está para sempre ter um fallback conhecidoUma vez que o DNS esteja no lugar, solicite SSL para ambos os hostnames (example.com e www.example.com). Não mude o tráfego até que o certificado esteja emitido e ativo, caso contrário usuários verão avisos do navegador.
Linha do tempo de corte com checkpoints claros:
example.com em uma janela anônima (homepage, assets estáticos, chamadas de API)www → apex)Depois da mudança, valide comportamento de cookies. Faça login, atualize e verifique que permanece logado em www e no apex. Se sessões quebrarem, quase sempre é configuração de domínio do cookie ou SameSite ainda assumindo o host antigo.
Depois que a migração der certo, o trabalho não acabou. A maioria das mudanças falha depois porque ninguém percebe um desgaste: um certificado perto do vencimento, uma alteração DNS feita às pressas ou um ajuste de redirecionamento que quebra um fluxo de login.
Estabeleça uma rotina de monitoramento pequena que você realmente mantenha. Não precisa de ferramenta enterprise para começar, mas precisa de alguns sinais confiáveis: checagens de disponibilidade para páginas-chave (home, login e uma página autenticada), alertas de expiração de certificado (por exemplo, 30 dias e 7 dias), monitoramento de taxa de erro (observe picos de 4xx/5xx, não só uptime) e validações ocasionais de redirecionamento (HTTP vai para HTTPS e o hostname preferido vence).
Mantenha uma janela curta de rollback, mesmo que tudo pareça bem. Por 24–72 horas, deixe a configuração anterior pronta (alvos DNS antigos, configuração de hosting antiga, ajustes TLS antigos) para poder reverter rápido se aparecer um problema escondido, como um callback de pagamento ou um provedor OAuth ainda apontando para o domínio antigo.
Quando estiver confiante, aumente novamente os TTLs. TTL baixo é útil durante mudanças, mas adiciona carga aos resolvers e aumenta impacto de pequenos erros. Escolha um TTL normal que combine com a frequência de mudanças (muitos times escolhem 1 a 4 horas).
Por fim, documente o estado final enquanto ainda estiver fresco: quais registros existem (tipo, nome, valor, TTL), quais hostnames são suportados e as regras exatas de redirecionamento. Inclua onde os certificados são emitidos, o que cobrem (apex, www, subdomínios) e quem é responsável pelas renovações.
Se você constrói e deploya em uma plataforma, ajuda quando domínios são tratados como um recurso de primeira classe e o rollback é simples. No Koder.ai, domínios personalizados ficam ao lado de snapshots e rollback, o que pode tornar mudanças futuras menos estressantes quando algo precisar ser desfeito rapidamente.
Default para um hostname canônico e redirecione todo o resto para ele.
example.com (apex) ou www.example.com como o “principal”.Isso mantém cookies, sessões e favoritos consistentes e evita comportamentos parcialmente funcionais.
Diminua o TTL no dia anterior ao corte planejado e aguarde o tempo do TTL antigo expirar.
Diminua o TTL apenas nos registros que você realmente vai alterar.
Para muitas configurações de app:
www.example.com ou app.example.com quando apontar para um hostname de provedor.example.com.Não direcione tráfego de usuários até que HTTPS esteja válido nos novos hostnames.
Ordem prática:
Isso evita avisos do navegador e requisições bloqueadas justamente no corte.
A maior parte dos problemas com e‑mail vem de deletar ou sobrescrever MX e TXT.
Antes de alterar anything:
Cadeias e loops de redirecionamento geralmente vêm de regras conflitantes entre CDN/proxy e a aplicação.
Use estes padrões seguros:
http:// → https://Se estiver atrás de um proxy/CDN, faça a app respeitar os cabeçalhos de forwarded scheme; caso contrário, ela pode achar que toda requisição é HTTP e ficar redirecionando sem parar.
Sim — é comum se os cookies estiverem limitados ao hostname antigo.
Verifique:
old-host não serão enviados para new-hostAtualize as configurações de identidade antes do corte.
Itens típicos que precisam coincidir exatamente com o novo domínio:
Se isso ainda apontar para o domínio antigo, o login pode ocorrer no provedor mas falhar ao retornar para a app.
Rollback normalmente é só restaurar os valores DNS anteriores.
Mantenha simples:
Se sua plataforma oferecer snapshots/rollback (o Koder.ai faz), tire um antes do corte para poder desfazer mudanças de configuração relacionadas rapidamente.
Concentre‑se em caminhos reais de usuário, não só na homepage.
Teste isto tanto no host canônico quanto no host que redireciona:
Também verifique se a barra de endereço termina em e sempre em , sem avisos de conteúdo misto.
Evite tentar forçar um CNAME no apex se seu provedor DNS não oferecer um tipo de registro alias para o apex.
Uma medida rápida de segurança é exportar ou fazer screenshot da zona atual para restaurar rápido se necessário.
Uma abordagem de baixo risco é manter o hostname antigo respondendo durante a transição para que os usuários possam renovar sessões no novo domínio.