Por qué el purge es la otra mitad del caché
Un CDN acelera tu sitio precisamente porque retiene contenido, pero ese mismo comportamiento hace que una edición sea invisible hasta que la copia cacheada expire, lo cual puede tomar horas. El purge es la válvula de escape: le dice al edge que descarte objetos específicos de inmediato para que la siguiente solicitud obtenga una copia fresca del origin. Sin un purge confiable, el caché agresivo se vuelve un pasivo porque no te atreves a cachear nada por mucho tiempo; con el, puedes definir TTLs generosos por velocidad y aun así lanzar cambios urgentes en vivo en segundos. Por eso purge y caché son dos mitades de la misma herramienta, no funciones separadas.
Purge quirúrgico frente a purge completo
Limpiar todo el caché después de una edición de texto de una línea funciona, pero descarta cada objeto ya calentado y obliga al edge a volver a obtener todo, elevando brevemente la carga del origin y ralentizando a los primeros visitantes. cdn.com.tr te permite purgar una sola URL o un conjunto de rutas para que invalides exactamente lo que cambio y dejes el resto del caché caliente. La regla práctica es purgar de forma acotada para ediciones de contenido y reservar el purge completo para releases que tocan assets compartidos como una hoja de estilos global o una plantilla usada en todas partes, y elegir el alcance correcto mantiene intactas tanto la corrección como el rendimiento.
Purge API para pipelines automatizados
El purge manual funciona hasta que se te olvida, y un purge olvidado significa usuarios viendo una página desactualizada mientras juras que el fix ya está desplegado. La purge API elimina el paso humano al dejar que tu pipeline de deploy llame la invalidación como parte del lanzamiento, de modo que un merge que dispara un build también puede limpiar las URLs exactas que ese build cambio. Esa es la diferencia entre un caché que tienes que vigilar y un caché que es una capa invisible que se mantiene correcta por sí sola, y es esencial para equipos que despliegan varias veces al día.
Logs en vivo cuando algo se rompe
Cuando una página devuelve un error o un deploy no se comporta como debe, adivinar sale caro, y el streaming de logs es como dejas de adivinar. Para apps en contenedores, cdn.com.tr transmite stdout y stderr para que puedas observar la salida propia de la aplicación casi en tiempo real y leer el stack trace real, la query fallida, o el error de arranque en lugar de inferirlo a partir de un 500 genérico. Mantener la vista de logs abierta durante un release significa que atrapas un rollout defectuoso en los primeros segundos, mientras el arreglo aún es barato, en lugar de enterarte por los usuarios después.
Status: saber que está realmente en vivo
Hay una brecha peligrosa entre haber desplegado una versión y que esa versión realmente sirva tráfico, y el status la cierra. El panel muestra que release es el actual, cuando se desplegó, y si el healthcheck está pasando, de modo que un estado verde es confirmación concreta de que el nuevo contenedor levantó y está respondiendo solicitudes. Esto importa más justo después de un rollout, cuando un build puede tener éxito y aun así la app puede fallar al iniciar por un valor de entorno erróneo o una dependencia faltante, y el healthcheck es lo que revela eso de inmediato.
Un solo lugar para lanzar y verificar
El valor de juntar purge, logs y status es que todo el ciclo de deploy-y-confirmación vive en una sola superficie en lugar de disperso entre herramientas. Lanzas un cambio, purgas el caché afectado, observas los logs en busca de errores, y lees el estado de salud para confirmar el éxito, todo sin salir del panel ni correlacionar tres dashboards distintos. Para equipos que hacen cambios frecuentes en producción, esta consolidación es lo que hace que operar el sitio se sienta controlado en lugar de ansioso, porque cada pregunta que tienes después de un deploy tiene una respuesta justo ahí.
Cómo configurarlo, paso a paso
Encuentra los controles de purge
Abre tu dominio o app en el panel y ve al area de caché/purge. Aquí puedes purgar una sola URL, un grupo de rutas, o todo el caché de la zona. El purge de una sola URL es la opción quirúrgica para una página cambiada; el purge completo es el instrumento contundente para un lanzamiento a nivel de sitio.
Purga después de cada cambio de contenido
Cuando edites una página, reemplaces una imagen, o lances un deploy, purga las URLs afectadas para que el edge obtenga copias frescas en la siguiente solicitud en lugar de servir versiones cacheadas hasta que expire el TTL. Convierte esto en un hábito para que los visitantes nunca vean el contenido de ayer.
Conecta el purge a tu pipeline
Usa la purge API para disparar la invalidación automáticamente desde tu CI/CD o script de deploy, de modo que en el momento en que un build se lanza, las entradas de caché relevantes se limpian sin que nadie abra el panel. Así mantienes la corrección del caché sin depender de la memoria humana.
Transmite los logs de tu app
Para apps en contenedores, abre la vista de logs para seguir stdout y stderr casi en tiempo real. Cuando una solicitud falla o un deploy se comporta mal, el stream de logs es donde ves el error real, así que mantenlo abierto durante y justo después de un release.
Lee el estado de deploy y salud
Revisa la vista de status para confirmar que release está en vivo, cuando se desplegó, y si el healthcheck está pasando. Un estado de salud verde después de un rollout es tu señal de que la nueva versión realmente está sirviendo tráfico, no solo subida.
Convierte esto en una rutina
Adopta un ciclo fijo post-deploy: lanzar, purgar, observar logs, confirmar salud. Seguir la misma lista corta cada vez es lo que convierte los deploys de una apuesta en una operación controlada y observable.
Escenarios de ejemplo
Un desarrollador lanza nuevo CSS y JavaScript, purga esas URLs de assets específicas desde el pipeline, y confirma que los visitantes cargan de inmediato el nuevo build en lugar de versiones cacheadas retenidas bajo un TTL largo.
Después de que un rollout devuelve errores, el equipo transmite los logs en vivo de la app, detecta una variable de entorno faltante en el trace de arranque, la corrige, redespliega, y observa como el healthcheck se pone verde para confirmar la recuperación.
Un editor corrige un error factual en un artículo publicado, purga esa única URL, y la página corregida está en vivo en segundos sin esperar a que el caché expire por sí solo.
Preguntas frecuentes
Qué tan rápido hace efecto un purge?
El purge marca los objetos objetivo como inválidos para que la siguiente solicitud de ellos se obtenga fresca desde el origin en lugar de servirse desde caché. En la práctica el cambio es efectivo en segundos, por lo que el purge es la herramienta correcta para correcciones urgentes en lugar de esperar a que expire el TTL.
Debería purgar todo o solo las URLs cambiadas?
Purga de forma acotada siempre que puedas. Limpiar una sola URL o un pequeño conjunto de rutas refresca exactamente lo que cambio manteniendo el resto del caché caliente, así evitas una ráfaga de tráfico al origin. Reserva un purge completo para releases que alteran assets compartidos usados en todo el sitio.
Puedo disparar purges automáticamente desde mi pipeline de deploy?
Si. La purge API permite que tu CI/CD o script de deploy llame la invalidación como parte del lanzamiento, de modo que el caché de las URLs que un build cambio se limpia automáticamente en el momento en que se despliega, sin que nadie tenga que abrir el panel.
Qué muestran los logs de contenedores?
Transmiten el stdout y stderr propios de tu aplicación casi en tiempo real, para que veas la salida real en ejecución, como stack traces de errores, queries fallidas y mensajes de arranque. Esa es la diferencia entre leer la causa real de un fallo y adivinarla a partir de una página de error genérica.
Cómo sé si un deploy realmente tuvo éxito?
Lee la vista de status. Muestra que release es el actual, cuando se desplegó, y si el healthcheck está pasando. Un build puede terminar y aun así la app puede fallar al iniciar, así que un healthcheck aprobado es la confirmación concreta de que la nueva versión realmente está sirviendo tráfico.
Cuál es el orden recomendado después de un deploy?
Lanza el cambio, purga el caché afectado para que los visitantes reciban la nueva versión, observa los logs en vivo en busca de errores durante el arranque, y finalmente confirma que el healthcheck está verde. Ejecutar ese mismo ciclo corto cada vez mantiene los deploys observables y de bajo riesgo.