DevOps

Si todavía haces next build directamente en el servidor de producción — tu servidor realmente sufre. CPU al máximo, OOM-kill, errores 502 y largos tiempos de inactividad — es un clásico que ya es hora de terminar.

En 2026, el estándar de la industria es la construcción separada:

1. Construimos una imagen standalone mínima en la nube con GitHub Actions.
2. La empujamos a GHCR (GitHub Container Registry).
3. En el servidor solo hacemos pull + reinicio atómico.

Capítulo 1. Dockerfile ideal (multietapa + standalone)

Todo el secreto de una imagen pequeña y rápida está en el modo standalone. Next.js calcula por sí mismo qué archivos y partes de node_modules son realmente necesarios para que funcione el servidor, y copia solo esos.

Cuando un proyecto sale del ámbito del desarrollo local y comienza a usar CI/CD, surge una pregunta fundamental: ¿cómo transmitir de forma segura los parámetros de configuración a los pipelines de build y despliegue? No se trata solo de contraseñas de bases de datos, sino también de tokens de registros de contenedores, claves SSH, claves de firma JWT, cadenas de conexión a colas de mensajes y cualquier otro parámetro que no deba almacenarse en texto claro.

Hubo varios problemas relacionados tanto con la parte técnica como con la comprensión en general. Mijaíl respondió rápidamente a la solicitud, ayudó a aclarar las cosas y resolvió los problemas técnicos, por lo que le doy las gracias por ello. Estoy satisfecho con el resultado.

Respuesta: ¡Gracias por el comentario! ¡Encantado de ayudar!

Todo se hizo rápido y con precisión. Lo recomiendo.

Imagine la situación: trabajas en un proyecto genial toda la noche. A las 4 de la mañana todo está listo, haces un git push final y te vas a dormir tranquilo. Y por la mañana descubres que tu balance en AWS está a cero y que hay un minero corriendo en tus servidores. ¿Qué pasó? Resulta que en uno de los archivos dejaste la línea: AWS_ACCESS_KEY_ID = "AKIA...".

Es un error clásico por el que han pasado miles de desarrolladores. En este artículo veremos por qué «simplemente borrar la contraseña» no ayuda y cómo configurar una protección automática que físicamente te impedirá cometer el error.

Escribir un Dockerfile simple: FROM node, COPY ., CMD run. Esto funciona, y para pruebas locales a menudo es suficiente. Pero cuando tal imagen llega al CI/CD o, Dios no lo quiera, a producción, empiezan los problemas: la construcción dura una eternidad, la imagen pesa gigabytes y los de seguridad se llevan las manos a la cabeza.

La diferencia entre “funciona” y “funciona correctamente” es colosal. Vamos a analizar cuatro niveles de optimización que separan una chapuza aficionada de una solución de ingeniería fiable.

Si te ocupas de self-hosting, tienes un laboratorio doméstico o administras un VPS pequeño, seguramente conoces Portainer. Es el estándar de facto: una navaja suiza potente y completa para Docker.

Pero seamos honestos: a veces la navaja suiza es demasiado pesada cuando solo necesitas pelar una manzana.

Recientemente descubrí Dockge — una herramienta del mismo desarrollador del popular Uptime Kuma. Me hizo replantear por completo el enfoque para gestionar contenedores. En este artículo cuento por qué Dockge puede ser el reemplazo ideal de Portainer para muchos escenarios.

Al trabajar con proyectos reales (cambio de CDN, migración, refactorización) a menudo es necesario reemplazar en masa una URL por otra.

A primera vista la tarea parece trivial: sed -i 's|old|new|g' **/* — y listo.

En realidad ese enfoque es una ruleta rusa.

Un reemplazo descuidado conduce a:

• 💀 Daño de archivos binarios (imágenes, pdf, archivos);
• 📉 Basura en el historial de git (los binarios aparecen como modificados);
• 🚫 Imposibilidad de una reversión limpia si no se hizo un respaldo.

En esta nota analizaremos un algoritmo apto para producción: cambiamos solo texto, no tocamos binarios, hacemos un respaldo puntual.

Jitsi Meet funciona de serie y resuelve muy bien la tarea de videoconferencias. La combinación Jitsi Meet + Jibri permite grabar las reuniones — y en muchas instalaciones ahí se quedan.

Pero tan pronto como Jitsi se usa no de forma esporádica, sino en el flujo de trabajo, muy pronto surgen preguntas:

• ¿Dónde almacenar las grabaciones de forma centralizada?
• ¿Cómo publicar automáticamente los enlaces para el equipo?
• ¿Cómo librarse de los pesados MP4 y pasar a reproducción por streaming?
• ¿Cómo servir las grabaciones por HTTPS sin revelar la estructura de directorios?
• ¿Cómo hacer todo esto automáticamente, sin intervención manual del administrador?

A continuación — una canalización de producción completa con código: desde la finalización de la grabación de Jibri hasta la publicación en Notion y el transcodificado asíncrono MP4→HLS con entrega a través de Caddy.

En los últimos diez años la industria del despliegue de aplicaciones web ha recorrido el camino desde scripts FTP y rsync hasta sistemas de orquestación muy complejos. Hoy en día los desarrolladores y los equipos pequeños se enfrentan cada vez más a una decisión difícil:

• o bien pagar una prima considerable por la comodidad de las plataformas PaaS (Heroku, Render, Fly.io),
• o bien sumergirse en la complejidad cognitiva y operativa de Kubernetes.

Kamal ofrece una tercera vía: la comodidad de los servicios en la nube modernos — en su propio servidor.