Configuración de dominio personalizado para apps web con pasos claros de registros DNS, emisión de SSL, redirecciones y un plan de corte de bajo riesgo para evitar caídas y problemas con cookies.
Un dominio personalizado es más que una URL más bonita. En el momento en que pasas de una dirección de plataforma (por ejemplo, una app que construiste en Koder.ai bajo un subdominio de la plataforma) a tu propio dominio, los navegadores y las redes lo tratan como un sitio distinto. Eso afecta el enrutamiento, la seguridad y cómo se comportan las sesiones de usuario.
Una vez que cambias a un dominio personalizado, algunas cosas cambian de inmediato:
www o en el dominio raíz, y necesitas reglas consistentes de HTTP a HTTPS.old-platform.example no funcionará automáticamente en app.yourdomain.com.Las interrupciones cortas suelen venir por el tiempo. El DNS puede empezar a enviar tráfico al nuevo host antes de que el certificado SSL esté listo, lo que provoca advertencias del navegador. O al revés: el SSL está listo, pero muchos usuarios siguen golpeando el sitio antiguo porque su caché DNS no ha caducado.
Las redirecciones también pueden romper los inicios de sesión de forma sutil. Una redirección que cambia el hostname (de apex a www, o viceversa) puede hacer que se pierdan cookies si se configuraron para el otro host. Los proveedores de autenticación pueden fallar si su URL de callback sigue apuntando al dominio antiguo.
Un corte de bajo riesgo significa planear un solapamiento: mantener la URL antigua funcionando, poner el nuevo dominio en paralelo, cambiar el tráfico en un momento predecible y hacer que el rollback sea tan simple como cambiar el DNS de vuelta.
Antes de cambiar nada, anota exactamente qué nombres quieres que los usuarios escriban y cuáles deberían redirigir silenciosamente. La mayoría de los problemas de “¿por qué funciona a medias?” vienen de equipos que nunca se pusieron de acuerdo en un único hostname verdadero.
Empieza con la gran decisión: apex (example.com) o www (www.example.com) como primario. Cualquiera puede funcionar, pero elige uno y trata al otro como una redirección. Esto importa después también para las cookies: las sesiones suelen ser más fáciles cuando la app vive en un host consistente.
Después, decide qué subdominios necesitas ahora y cuáles pueden esperar. Un patrón común es app.example.com para la app web y api.example.com para APIs, con admin.example.com o assets.example.com añadidos más tarde. Si estás configurando un dominio personalizado en una plataforma como Koder.ai, estas elecciones se mapean directamente a lo que validarás para SSL y a lo que apuntarás en DNS.
Mucha gente compra un dominio en un registrador, pero el DNS puede estar alojado en otro sitio. Confirma dónde se editan los registros hoy, quién tiene acceso y si alguna automatización gestiona cambios (TI de la empresa, una agencia o un proveedor de DNS gestionado). Si no puedes entrar y ver los registros actuales, detente y arregla eso primero.
También audita qué ya usa el dominio. El correo es la trampa clásica: puedes romper la entrega de emails borrando o sobrescribiendo registros.
Antes de seguir, captura estas decisiones por escrito:
www) y la dirección de redirecciónSi marketing ya gestiona correo en example.com, no toques los registros de mail mientras solo añades lo que necesita la app.
Gran parte del riesgo en una mudanza de dominio personalizado no es la app en sí. Es un cambio DNS equivocado que envía tráfico al vacío, rompe el correo o hace fallar la validación SSL.
Un registro A apunta un nombre a una dirección IP. En términos sencillos: “envía a la gente a este servidor”. Es común para el apex (example.com) cuando tu proveedor te da una IP fija.
Un registro CNAME apunta un nombre a otro nombre. En términos sencillos: “trata este nombre como un alias de ese hostname”. Es común para www.example.com apuntando a un hostname de la plataforma.
Muchos proveedores DNS también ofrecen ALIAS/ANAME en el apex. Se comporta como un CNAME pero funciona para example.com. Si tu proveedor lo soporta, puede ser más fácil de gestionar porque el objetivo puede moverse sin que tengas que tocar IPs.
Un modelo mental simple:
A menudo añadirás TXT para comprobaciones de propiedad de dominio (verificación de plataforma) y para la validación de certificados SSL (algunas CA validan mediante un token TXT). TXT también se usa para políticas de correo como SPF. Borrar o reemplazar un SPF existente puede romper la entrega de mail.
TTL controla cuánto tiempo otros sistemas cachean la respuesta DNS. Un día antes del corte, baja el TTL en los registros que planeas cambiar (comúnmente 300 a 600 segundos). Después de que todo esté estable, súbelo otra vez para reducir la carga de consultas.
Antes de editar, exporta o haz una captura de pantalla de la zona actual. Anota cada registro que vas a cambiar, su valor antiguo, nuevo y TTL. Si algo falla, el rollback es restaurar los valores previos.
Esto es especialmente importante cuando tu dominio ya tiene MX, DKIM u otros TXT para correo.
SSL (el icono de candado) cifra el tráfico entre el navegador y tu app. Los navegadores modernos y muchas APIs esperan HTTPS por defecto. Sin él, puedes tener advertencias, peticiones bloqueadas y funciones como service workers, geolocalización o algunos flujos de pago pueden dejar de funcionar.
Para emitir un certificado, la autoridad certificadora debe verificar que controlas el dominio. Los métodos comunes de validación son validación HTTP y validación mediante TXT en DNS:
La validación DNS suele ser más sencilla cuando usas un CDN o cuando tu app aún no es accesible en el nuevo dominio.
Dónde se emite el certificado depende de tu arquitectura. Algunos equipos emiten certificados directamente en su stack de hosting, otros lo hacen en el CDN, y algunas plataformas que soportan dominios personalizados lo gestionan por ti (por ejemplo, Koder.ai puede gestionar el certificado durante la configuración del dominio). Lo importante es saber quién posee el ciclo de vida del certificado, incluidas las renovaciones.
La emisión de certificados no siempre es instantánea. La propagación DNS, las comprobaciones de validación y los límites de tasa pueden retrasarla. Planifica reintentos y evita programar el corte para el último minuto.
Un plan práctico de tiempos:
Un certificado debe cubrir todos los hostnames a los que los usuarios accederán. Revisa la lista SAN (Subject Alternative Names). Si tu app estará disponible en example.com y www.example.com, el certificado debe incluir ambos.
Los comodines (como *.example.com) ayudan para muchos subdominios, pero no cubren el dominio apex (example.com).
Ejemplo concreto: si solo emites un certificado para www.example.com, los usuarios que escriban example.com verán advertencias a menos que hagas una redirección en una capa que ya tenga un certificado válido para example.com.
Las redirecciones parecen simples, pero aquí aparecen la mayoría de los problemas de dominio: bucles, contenido mixto y usuarios que pierden la sesión porque rebotaron entre hostnames.
Elige un host canónico y apégate a él: www.example.com o example.com (apex). El otro punto de entrada debe redirigir a tu host canónico para mantener consistencia en cookies, sesiones y señales SEO.
Valores seguros por defecto:
http:// a https:// para cada peticiónPara HTTP a HTTPS, evita reglas que hagan rebotar a los usuarios. La forma más fácil de prevenir bucles es basar la decisión en lo que la petición realmente fue. Si tu app está detrás de un proxy o CDN, configúralo para respetar los encabezados reenviados (por ejemplo, un header que diga que el esquema original fue HTTP). De lo contrario, tu app puede pensar que cada petición es HTTP y seguir redirigiendo para siempre.
Durante una mudanza, mantiene las rutas antiguas vivas. Si cambias rutas (por ejemplo /login a /sign-in), añade redirecciones explícitas para esas rutas. No confíes en una redirección general hacia la página principal; eso rompe marcadores y enlaces compartidos.
Evita activar HSTS al principio. Si lo activas demasiado pronto y después necesitas servir HTTP para validación o solución de problemas, los navegadores podrían negarse. Espera hasta que HTTPS esté estable y hayas confirmado la cobertura de subdominios.
Para probar redirecciones sin afectar a todos, usa un hostname de prueba temporal, prueba enlaces profundos reales (incluyendo páginas de autenticación) y ejecuta una petición por línea de comandos que muestre cada paso de redirección y el destino final.
Un corte seguro es mayormente cuestión de tiempos. Quieres que tu nuevo dominio esté listo y probado antes de que cualquier usuario real lo vea, y quieres que los cambios DNS se propaguen rápido para no quedarte esperando durante un incidente.
Baja el TTL de DNS (de los registros que cambiarás) con suficiente antelación. Hazlo el día antes si puedes y espera la ventana del TTL antiguo para que las caches cojan el valor más bajo.
Luego, añade el dominio personalizado en tu hosting/proveedor y completa la verificación que pidan. Si usas una plataforma como Koder.ai, añade el dominio allí primero para que la plataforma confirme propiedad y prepare el enrutamiento.
Emite SSL con antelación. Los certificados pueden tardar minutos o más según la validación, y no quieres ese retraso durante el cambio.
Antes de hacer público el dominio, haz una prueba privada: accede al nuevo endpoint de una forma que no dependa del DNS público (por ejemplo, usando una entrada temporal en el host de tu máquina) y confirma que el sitio carga por HTTPS con el certificado correcto.
Usa un enfoque por etapas para poder parar rápido si algo falla:
www) antes de cambiar usuarios.Si no puedes hacer un canario real a nivel DNS, aún puedes escalonar cambiando solo un hostname primero (por ejemplo www) y dejando el apex intacto hasta tener confianza.
Anota exactamente qué revertirás (qué registros, qué valores) y quién lo hará. El rollback suele ser volver a poner el DNS como estaba.
Asegúrate de que la configuración antigua siga siendo válida (incluido SSL en el dominio antiguo) para que los usuarios puedan volver sin problemas mientras arreglas la nueva ruta.
Un cambio de dominio no es solo un cambio DNS. Para muchas apps, “estar logueado” depende de cookies que los navegadores atan a un hostname específico. Si cambias de hostname, el navegador puede dejar de enviar las cookies antiguas y tu app parecerá que ha cerrado sesión a todos.
Los ajustes de cookie suelen ser la razón:
app.old.com no se enviará a app.new.com. Una cookie puesta para .example.com puede funcionar entre app.example.com y www.example.com./api), la interfaz web puede no verla.Lax suele estar bien, pero algunos SSO o redirecciones de pago pueden necesitar None más Secure.Para reducir riesgos, planifica una transición corta donde ambos dominios funcionen. Mantén el hostname antiguo respondiendo y redirigiendo con cuidado, pero permite que las sesiones se refresquen en el nuevo dominio. Si puedes, usa un almacén de sesiones compartido para que un usuario que llegue a cualquiera de los hostnames pueda ser reconocido.
Si usas SSO u OAuth, actualiza las configuraciones antes del corte: URLs de callback, orígenes permitidos y cualquier allowlist de redirect URI. Si no lo haces, los inicios de sesión pueden tener éxito en el proveedor de identidad pero fallar al regresar a tu app.
Prueba primero los flujos que suelen romperse: registro (y verificación por email), inicio de sesión/cierre, restablecimiento de contraseña, checkout o retorno de pago, y sesiones con varias pestañas.
Ejemplo: si rediriges www.example.com a example.com, asegúrate de que las cookies se configuren para .example.com (o usa consistentemente un único hostname). Si no, los usuarios rebotan entre hostnames y pierden sesión.
La mayoría de los problemas de dominio no son “misteriosas fallas de internet”. Son pequeñas descoordinaciones entre DNS, certificados y reglas de redirección que solo aparecen cuando usuarios reales llegan al sitio.
Una trampa fácil es el dominio apex (example.com). Muchos proveedores DNS no permiten un CNAME verdadero en el apex. Si intentas forzar un CNAME en el apex puede fallar silenciosamente, resolverse de forma inconsistente o romperse solo en algunas redes. Usa lo que tu host DNS soporte (a menudo un registro A/AAAA, o un registro ALIAS/ANAME).
Otra causa frecuente de tiempo de inactividad es cambiar el DNS antes de que SSL esté listo en el nuevo endpoint. Los usuarios llegan, la app carga y luego el navegador lo bloquea porque falta el certificado o solo cubre parte de tus hostnames. En la práctica, normalmente quieres que el certificado cubra tanto example.com como www.example.com, incluso si planeas redirigir uno al otro.
Errores comunes que crean interrupciones o comportamiento extraño:
www al apex, luego apex de vuelta a www), o forzar HTTP en un lado y HTTPS en otrohttp://, lo que provoca advertencias y funciones rotasUna comprobación rápida: abre ambos hostnames (www y apex) por HTTPS, inicia sesión, refresca y confirma que la barra de direcciones nunca vuelve a HTTP.
Si haces esto en una plataforma como Koder.ai, confirma que los dominios personalizados están conectados y que SSL se emitió antes de tocar el DNS de producción, y mantén una opción de rollback para que una mala redirección o un cambio de registro no persista.
Un corte calmado es casi todo trabajo de preparación. El objetivo es simple: los usuarios deben seguir iniciando sesión, las cookies deben seguir funcionando y debes poder revertir rápido si algo va mal.
Haz esto mientras el tráfico sigue yendo al dominio antiguo. Date un día si puedes, para que los cambios DNS tengan tiempo de asentarse.
www, api, etc.) y elige tu método de validación SSL (DNS o HTTP).www al apex (o viceversa) y un host canónico.Cuando cambies el DNS, trata la primera hora como un ejercicio de incidente. Observa los flujos reales de usuarios, no solo los paneles de estado.
Aunque Koder.ai (u otra plataforma) gestione dominios personalizados y SSL por ti, esta lista sigue siendo importante. La mayoría de los problemas vienen de DNS y redirecciones, no del código de la app.
Tu app corre en una dirección temporal de plataforma como myapp.koder.ai. Funciona, pero quieres que los clientes usen example.com, con www.example.com redirigiendo al apex, y todo forzado a HTTPS.
Un plan DNS simple mantiene el riesgo bajo. Antes de cambiar nada, anota el estado actual que funciona (haz una captura si tu plataforma lo permite, como Koder.ai) y reduce el TTL a algo corto con 24 horas de antelación.
Añade los nuevos registros dejando la URL de la plataforma intacta:
example.com: registro A/ALIAS apuntando al objetivo de hosting que te proporcione la plataformawww.example.com: CNAME apuntando a example.com (o al objetivo de la plataforma, según el proveedor)myapp.koder.ai tal cual para tener siempre un fallback conocido y funcionalUna vez el DNS esté en su sitio, solicita SSL para ambos hostnames (example.com y www.example.com). No cambies el tráfico hasta que el certificado esté emitido y activo, de lo contrario los usuarios verán advertencias del navegador.
Cronograma de corte con puntos de control claros:
example.com en una ventana de incógnito (página principal, assets estáticos, llamadas a la API)www al apex)Después del cambio, valida el comportamiento de cookies. Inicia sesión, refresca y comprueba que sigues logueado en www y en el apex. Si las sesiones se rompen, suele deberse a configuración de dominio de cookie o SameSite que aún asume el host antiguo.
Después de que el corte funcione, el trabajo no termina. La mayoría de las mudanzas de dominio fallan más tarde porque nadie detecta un deterioro lento: un certificado cerca de expirar, un cambio DNS apresurado o una modificación de redirección que rompe un flujo de login.
Establece una pequeña rutina de monitorización que realmente mantendrás. No necesitas una herramienta empresarial para empezar, pero sí algunas señales fiables: checks de disponibilidad para páginas clave (inicio, login y una página autenticada), alertas de expiración de certificado (por ejemplo, a 30 días y de nuevo a 7 días), seguimiento de tasas de error (vigila picos de 4xx/5xx, no solo uptime) y validación ocasional de redirecciones (HTTP va a HTTPS y el hostname preferido gana).
Mantén una ventana corta de rollback, incluso si todo parece bien. Durante 24 a 72 horas, deja la configuración anterior lista (targets DNS antiguos, configuración de hosting antigua, ajustes TLS antiguos) para que puedas revertir rápido si aparece un problema oculto, como un callback de pago o un proveedor OAuth que aún apunta al dominio antiguo.
Cuando tengas confianza, sube de nuevo los valores TTL. Un TTL bajo es útil durante cambios, pero añade carga a los resolvers y aumenta el impacto de pequeños errores. Elige un TTL normal que coincida con la frecuencia esperada de cambios (muchos equipos eligen 1 a 4 horas).
Finalmente, documenta el estado final mientras aún está fresco: qué registros existen (tipo, nombre, valor, TTL), qué hostnames se soportan y las reglas exactas de redirección. Incluye dónde se emiten los certificados, qué cubren (apex, www, subdominios) y quién posee las renovaciones.
Si construyes y despliegas en una plataforma, ayuda que los dominios sean una función de primera clase y que el rollback sea sencillo. En Koder.ai, los dominios personalizados están junto a snapshots y rollback, lo que puede facilitar futuros cambios de dominio y redirección cuando haya que deshacer algo rápidamente.
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.