Docker

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 la tecnología Docker apareció, la adoraron por el lema: «Build once, run anywhere» (Construye una vez, ejecuta en cualquier lugar). Los desarrolladores dejaron de escuchar la frase «en mi máquina funciona, pero en el servidor no». Pero junto con la comodidad llegó una nueva amenaza.

Un contenedor no es solo tu aplicación. Es todo un mini-sistema operativo (SO) con sus propias bibliotecas, utilidades y llamadas al sistema. Y si no vigilas ese SO, dejas a los atacantes una puerta enorme completamente abierta.

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.

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.

La experiencia de colaboración dejó una impresión sumamente positiva, principalmente por el profesionalismo y el enfoque para resolver los problemas que surgieron.

Respuesta: ¡Gracias por la reseña! ¡Encantado de ayudar!

Jitsi Meet — plataforma de videoconferencias de código abierto que se integra fácilmente con Active Directory (AD). Esta integración permite usar cuentas corporativas para iniciar sesión, simplificando la administración y aumentando la seguridad. En esta guía analizaremos en detalle cómo conectar Jitsi Meet (en Docker) a un AD basado en Windows Server 2016, y mostraremos métodos de depuración probados que ayudarán a evitar errores típicos.

Importante: usar LDAP sin cifrado no es seguro. Para pruebas esto es admisible, pero en producción es obligatorio usar LDAPS (puerto 636) con certificados correctos.

Read more

Cómo instalar Jitsi Meet (Docker) detrás de Nginx Reverse Proxy

En el artículo anterior desplegamos un servidor Jitsi Meet básico con Docker.
Es una excelente forma de arrancar videoconferencias rápidamente, pero en producción el servidor Jitsi a menudo debe funcionar en el mismo host donde ya están otras aplicaciones web.
Para que todo conviva en paz, hay que ocultar Jitsi detrás de un Nginx reverse proxy.
Nginx se encargará del SSL, de los puertos 80/443 y hará de proxy de las peticiones hacia los contenedores Jitsi que escuchan en puertos internos.

Local Telegram Bot API permite a los desarrolladores ejecutar su propio servidor API, ofreciendo ventajas significativas en el trabajo con archivos grandes, rendimiento y flexibilidad de configuración. Sin embargo, para entender la necesidad de un servidor local es importante considerar las limitaciones del Telegram Bot API estándar, que funciona a través de la interfaz HTTPS. En este artículo revisaremos las ventajas de Local Bot API, las limitaciones del enfoque estándar y los pasos para configurar un servidor local mediante Docker, incluyendo el registro del bot para usarlo con él.

Objetivo

🚀 Crear un proxy propio, rápido y fiable, registrarlo en Telegram para rastrear estadísticas y, si se desea, hacerlo público.

Elección de la solución: Docker + Imagen oficial MTProto

• ¿Por qué Docker?
  Docker permite ejecutar el proxy en un contenedor aislado sin instalar dependencias innecesarias en el servidor. Es limpio, seguro e increíblemente rápido.
  El archivo docker-compose.yml describe toda la configuración en un solo lugar, lo que hace que el despliegue y la gestión sean tareas triviales.

  Read more