Durante mucho tiempo quise tener mi propio servidor, pero me echaban para atrás el coste y la complejidad. Entonces descubrí Proxmox VE y, mirando atrás, me pregunto por qué no lo hice antes. Proxmox es una plataforma de virtualización gratuita y de código abierto basada en Debian: KVM para máquinas virtuales completas, LXC para contenedores ligeros y una interfaz web que de verdad facilita el día a día.
Lo bueno es que no hace falta un servidor caro. Yo empecé con un mini PC de segunda mano (un Dell OptiPlex Micro) con la RAM ampliada y un SSD NVMe: silencioso, de bajo consumo y más que suficiente para 10–15 contenedores y algunas máquinas virtuales. Con los precios de la electricidad que tenemos aquí, un mini PC que consume 10–15 vatios en reposo marca una diferencia enorme frente a un servidor de rack.
Tras la instalación, lo primero que hice fue desactivar el repositorio enterprise y configurar los repositorios community, proteger el acceso SSH con claves e instalar Fail2ban. Después llegaron los primeros servicios: Pi-hole como bloqueador de anuncios para toda la red, Nginx Proxy Manager y Portainer. Ese orden ha funcionado bien: empezar poco a poco, no levantar veinte contenedores de golpe.
Mi consejo más importante, que yo mismo tuve que aprender por las malas: configura las copias de seguridad antes de instalar el primer servicio. Siguiendo la regla 3-2-1, y las copias de seguridad por snapshot integradas en Proxmox lo ponen casi demasiado fácil. Por cierto, RAID no es una copia de seguridad; eso también me costó entenderlo.
Simplemente empieza. Un contenedor, un servicio, y aprenderás más sobre infraestructura que en cualquier curso en línea. Y si de momento solo quieres probar, también puedes usar un servidor en la nube barato para aprender.
Fuente: Homelab Guide
Según IT之家, el NAS de cuatro bahías Qu405-N150-8G de QNAP ya se vende en JD.com. Incluye 8 GB de memoria y una garantía estándar de 2 años. El equipo solo cuesta 2599 yuanes, y el paquete con un disco duro Seagate IronWolf de 4 TB sale por 3599 yuanes.
El diseño es sencillo. La carcasa mide 165 mm x 168 mm x 217 mm y pesa 2,15 kg. El procesador es un Intel N150 de 4 núcleos y 4 hilos, y la empresa afirma que puede transcodificar vídeo 4K y ejecutar máquinas virtuales y contenedores Docker, un punto muy atractivo para quien le gusta trastear con servidores domésticos. La memoria SODIMM DDR4 de 8 GB que trae de fábrica se puede ampliar hasta 16 GB.
El almacenamiento se reparte en cuatro bahías para discos SATA de 3,5 o 2,5 pulgadas. Además, en el interior hay dos ranuras M.2 2280 NVMe PCIe Gen 3 x1, que sirven para caché o para guardar datos del sistema y de los contenedores. Las conexiones incluyen dos puertos de red 2.5GbE, dos USB-A 3.2 Gen 2, un USB-C 3.2 Gen 2 y un HDMI 2.1.
En mi opinión, la combinación de doble 2.5G con un N150 ya es una configuración habitual en los NAS domésticos de entrada desde hace un par de años. Puede ejecutar Docker sin consumir mucha energía y su precio es bastante razonable. Eso sí, el artículo solo recoge especificaciones y no incluye pruebas reales, así que si estás pensando en comprarlo, conviene revisar antes el ruido, el consumo y la experiencia con el software.
Fuente: IT之家
Synology ha anunciado para Alemania su nueva serie neo+, formada por el DS725neo+, el DS925neo+, el DS1525neo+ y el DS1825neo+. ComputerBase los describe como variantes más baratas de los modelos Plus, en las que solo ha cambiado la configuración de memoria.
Según el informe, la «neo» significa «opción Non-ECC». Estos equipos usan memoria convencional sin ECC, y siempre solo de 4 GB. Los DS725+ y DS925+ llevan 4 GB de memoria ECC, mientras que los DS1525+ y DS1825+ tienen 8 GB de memoria ECC, así que las variantes neo+ tienen menos. Por lo demás, el equipamiento, las funciones y la ampliabilidad coinciden con los modelos Plus, y también el sistema DSM con sus aplicaciones es idéntico.
En el precio de venta recomendado por el fabricante, la diferencia ronda los 200 euros: el DS725neo+ figura con 549 euros netos y el DS725+ con 748 euros netos. En la tienda, sin embargo, la distancia no es tan clara: el DS725+ se encuentra actualmente desde 663 euros y el DS725neo+ desde 629 euros. La memoria se puede ampliar después sin problemas a memoria ECC.
Synology atribuye la decisión a la situación actual del mercado de memoria, es decir, a las fuertes subidas de precio que también han afectado a los modelos Plus.
Para el ámbito del servidor doméstico, me parece un equilibrio interesante. Quien use el NAS sobre todo para copias de seguridad, contenido multimedia y unos pocos contenedores probablemente se apañe con 4 GB sin ECC. Quien valore la integridad de los datos debería fijarse bien en lo que obtiene por la diferencia de precio.
Fuente: ComputerBase
Hardware.com.br se hace eco de un homelab que llama la atención por su tamaño reducido. Un usuario de Reddit publicó en r/HomeServer un pequeño rack de 10 pulgadas con cortafuegos, tres mini PC, un NAS y toda la infraestructura de red necesaria para mantener decenas de servicios funcionando en casa.
El procesamiento corre a cargo de tres mini PC, cada uno con un procesador de 8 núcleos y 16 hilos y 32 GB de RAM, lo que suma 24 núcleos, 48 hilos y 96 GB para virtualización. Usa Proxmox para crear máquinas virtuales y contenedores LXC. Entre las cargas hay una VM para Jellyfin, el llamado stack arr ejecutándose en Docker y otro host Docker con Portainer, Pi-hole y paneles como Homer y Homepage, además de servidores de juegos como Terraria y Core Keeper.
El almacenamiento está en un HP ProLiant MicroServer con cuatro discos duros de 4 TB en RAIDZ1 de ZFS, que permite seguir accediendo a los datos aunque falle un disco. Son 16 TB brutos, con menos espacio útil por culpa de la paridad. La red la controla un Fortinet FortiGate, que se encarga del enrutamiento, las VLAN y la VPN SSL, y un SAI APC Back-UPS 850 protege frente a cortes de corriente.
Lo más interesante, en mi opinión, está fuera de casa: el dueño mantiene dos VPS con Debian en centros de datos externos, conectados al homelab mediante una red WireGuard en configuración hub-and-spoke. Actúan como la capa pública de la infraestructura, con Traefik como proxy inverso.
Es un buen ejemplo de que un homelab no necesita un rack gigante: con planificación, cajas pequeñas y buena organización, se puede ejecutar mucho en poco espacio.
Fuente: Hardware.com.br
Si en un mismo servidor viven varios proyectos, tarde o temprano chocas con los puertos 80 y 443, que solo puede escuchar un proceso. Un artículo de Habr del blog de Selectel muestra paso a paso cómo resolverlo con Nginx Proxy Manager.
El autor explica primero el problema: los puertos privilegiados, la regla de un único oyente por puerto, los problemas de CORS cuando el frontend y el backend se separan por puertos y la falta de HTTPS. Un proxy inverso lo resuelve como intermediario, enrutando el tráfico por dominio y ruta. Una ventaja adicional es que el cortafuegos solo necesita los puertos 22, 80 y 443 abiertos.
El entorno de prueba es un VDS con 2 vCPU, 2 GB de RAM y 40 GB NVMe, con Ubuntu 24.04 y Docker del repositorio oficial. Se crea la red con docker network create proxy y se lanza el contenedor jc21/nginx-proxy-manager con volúmenes para datos y certificados. Me gustó que el panel de administración en el puerto 81 se vincule solo a 127.0.0.1 y se acceda por túnel SSH.
Después se configura un host de proxy: en Forward Hostname se pone el nombre del contenedor y el certificado SSL se asocia en la pestaña SSL. Para las pruebas se usa traefik/whoami. También se trata por separado el caso en que la aplicación corre directamente en el host: la dirección de la puerta de enlace de la red Docker se obtiene con docker network inspect, y el cortafuegos se configura para que no se pueda acceder a la aplicación saltándose el proxy.
Hay también algunos puntos débiles: los ejemplos mezclan dominios distintos y la imagen usa la etiqueta latest, lo que puede afectar a la reproducibilidad con el tiempo. Aun así, es un buen punto de partida para quien quiera tener varios servicios en casa o en un VDS sin editar a mano la configuración de nginx.
Fuente: Habr (blog de Selectel)
El Self-Host Weekly de esta semana, de selfh.st, reúne noticias que a la gente de los homelabs le interesará conocer. Me gusta este tipo de resumen porque ahorra mucho tiempo de lectura de feeds.
La noticia principal es un lío: un nuevo paquete de alternativas de código abierto a Adobe fue acusado de copiar proyectos existentes, sobre todo al popular Photopea, cuyo desarrollador fue de los primeros en dar la alarma. Los dos proyectos del centro, PhotoSuite y PhotoCraft, parecen estar conectados, y la cronología es difícil de seguir. El boletín aconseja mantenerse al margen hasta que demuestren que son algo más que una obra derivada.
Hay otras noticias más pequeñas que vale la pena mencionar. Let's Encrypt anunció que, en febrero de 2027, reducirá la duración de sus certificados SSL gratuitos de 90 a 64 días, lo que hace aún más importante una renovación automática fiable para quien tenga un proxy inverso en casa. Nabu Casa cambiará el nombre de Home Assistant Cloud a Home Assistant Link por la connotación negativa que ahora tiene la palabra «cloud». El proyecto de compartición de secretos cifrados Hemmelig ha sido archivado en GitHub, y la NVIDIA Shield TV, una caja de streaming de siete años muy popular entre los homelabs, ha subido 100 dólares de precio, algo que atribuyen a la inflación de hardware provocada por la IA.
El autor también ha lanzado la Encuesta de Usuarios de Self-Host 2026, con 45 preguntas sobre hardware, software, sistemas operativos, datos demográficos e IA. La encuesta del año pasado recibió algo más de 4000 respuestas, y la de este año ya tiene 2000 en solo dos días. Estará abierta hasta el 31 de octubre y los resultados se publicarán a principios de noviembre.
Personalmente, lo más práctico es el cambio en los certificados: si tu configuración de renovación es algo frágil, ahora es un buen momento para probarla.
Fuente: selfh.st
RedesZone responde a una duda muy habitual entre quienes montan un servidor en casa: si hay que reiniciar el NAS de vez en cuando o se puede dejar siempre encendido.
La respuesta corta es que sí, se puede tener encendido las 24 horas. Un NAS está pensado para funcionar de forma continua, con unidades de almacenamiento específicas para ello, y sirve para copias de seguridad, liberar espacio en otros equipos o compartir archivos grandes. Lógicamente consume energía, igual que el router o una cámara de seguridad, aunque están diseñados para gastar poco en reposo. Incluso con meses de uso continuo no hay un motivo obligatorio para reiniciarlo, más allá de ahorrar energía o de que no lo necesites.
Hay situaciones en las que sí conviene reiniciarlo: después de una actualización del sistema operativo, del firmware o de determinados paquetes, aunque el propio aparato no lo pida; cuando hay problemas de software, como una aplicación que deja de funcionar, un servicio lento, una interfaz web que va mal o errores en algún apartado; tras un cambio de hardware; y después de cualquier cambio importante en el funcionamiento. A veces un proceso se ha quedado bloqueado o un programa no se ha cerrado bien, y un reinicio devuelve todo a la normalidad.
Me parece un consejo sensato y sin dramatismos. Para un laboratorio casero, la regla práctica es dejar el NAS trabajando y reiniciarlo con intención, tras actualizar o cuando algo se comporta raro, en lugar de hacerlo por costumbre.
Fuente: RedesZone
Cuando tienes aplicaciones de código abierto en un servidor doméstico, a menudo necesitas enviar correos para registros o restablecimientos de contraseña. Pero enviar correo directamente desde casa exige montar un servidor SMTP y configurar un dominio de envío, y eso da más trabajo de lo que parece. Este artículo, que encontré en Qiita, resuelve el problema de forma sencilla con Mailpit y Discord, aceptando una solución más práctica.
Mailpit es, en origen, una herramienta para probar el envío de correo. Puede funcionar como servidor SMTP y además incluye una API de pruebas. Si configuras un webhook, puede llamar a una aplicación externa en cuanto llega un mensaje. El artículo aprovecha esta función para crear un sistema que envía el contenido de los correos recibidos a Discord.
La configuración consiste en dos contenedores, Mailpit y un webhook-handler, levantados con Docker Compose. El webhook-handler es una pequeña aplicación en Python hecha con FastAPI. Recibe los webhooks de Mailpit, da formato al remitente y al destinatario, y los reenvía a un webhook de Discord. La notificación también puede incluir un enlace a la interfaz web de Mailpit, para revisar el correo cuando haga falta. La configuración, como la URL del webhook, se guarda en un archivo .env aparte.
Aunque no envíes ningún correo al exterior, poder saber al momento que ha llegado un correo de restablecimiento de contraseña resulta muy práctico. Para quien tiene varias apps en un homelab, reunir todo el correo en un solo lugar debería facilitar mucho la gestión. El artículo es de agosto de 2026.
Fuente: Qiita
Una historia pequeña, pero que da que pensar a quien administra su propia red doméstica. Según GenK, un usuario de X llamado @NomadsGalaxy revisaba el Wi-Fi de sus padres y descubrió que una cafetera Keurig había generado alrededor de 1 TB de subida y casi 10 GB de descarga en solo 10 días.
Lo descubrió al mirar el sistema de red UniFi de la casa de sus padres. Ese volumen anómalo sobrecargó un punto de acceso Wi-Fi. En lugar de investigar la causa, desenchufó la máquina y les compró a sus padres otro producto. Según el artículo, la mayor parte del tráfico parecía quedarse dentro de la red interna y no salir a Internet, así que todavía no hay pruebas de que el aparato enviara datos de la familia a servidores externos. La causa más probable es un fallo de software o de comunicación en la red, y un reinicio pudo haberlo solucionado.
El artículo también apunta al panorama general del hogar inteligente: cuantos más dispositivos conectados hay, mayor es la probabilidad de fallos, vulnerabilidades de seguridad o interrupciones del servicio. Los dispositivos IoT pueden convertirse en una puerta de entrada para ataques si el fabricante no actualiza el software con regularidad, y algunos productos pierden casi todas sus funciones cuando la empresa cierra sus servidores.
En mi caso, la lección práctica es tener una herramienta que monitorice el tráfico por dispositivo en la red de casa y considerar separar los dispositivos IoT en una red aparte. Sin datos, es muy difícil darse cuenta de lo que hace una cafetera.
Fuente: GenK
Quien gestiona una red doméstica o un pequeño homelab conoce bien el sufijo .lan: aparece en los paneles de los routers, en los servidores DNS internos y en las direcciones que usamos para llegar a dispositivos sin un dominio registrado. IlSoftware.it informa de que una candidatura presentada ante la ICANN podría convertirlo en un dominio de Internet accesible en todo el mundo.
La solicitud para el TLD .lan la ha presentado Coffee Danger, una empresa estadounidense, y todavía está en fase de Pre-Evaluation Processing. Esto significa que el dominio no está aprobado y todavía no puede usarse para registrar direcciones públicas. La candidatura forma parte de la nueva tanda de asignación de dominios de primer nivel iniciada por la ICANN en 2026, en la que han participado cientos de empresas: entre los solicitantes están Google con .browser, OpenAI con .openai y .chatgpt, Meta con .facebook y la italiana Aruba con dominios como .pec, .vps, .lab, .roma y .ciao. Todas las solicitudes siguen sujetas a evaluación.
El punto delicado es que .lan no es un nombre como los demás. Muchos técnicos lo usan desde hace tiempo, por ejemplo nas.lan, router.lan o camera.lan. Si un nombre considerado interno entra en el DNS público, el riesgo es tener fallos de funcionamiento, consultas DNS que salen de la red y comunicaciones que podrían llegar a destinos distintos de los previstos.
Como aficionado a las redes domésticas, me parece un buen recordatorio: para los nombres internos conviene usar sufijos pensados para ese fin y no depender de convenciones de hecho. Por ahora no hay ninguna decisión, pero merece la pena seguirlo de cerca.
Fuente: IlSoftware.it
Korben vuelve sobre un comando de Cloudflare que muchos desarrolladores ya usan: cloudflared tunnel --url. Publica un servidor que corre en tu equipo en una dirección trycloudflare.com, sin cuenta, sin nombre de dominio y, sobre todo, sin abrir ningún puerto en el router. Para quien aloja servicios en casa, es una forma sencilla de enseñar un proyecto a alguien durante una prueba.
La novedad de estos días es la opción --allowed-mail. Antes, cualquiera con el enlace podía conectarse al servicio. Ahora el acceso puede limitarse a unas pocas direcciones de correo que tú defines, con un código de un solo uso enviado mediante Cloudflare Access.
El tutorial parte de un pequeño servidor web local en el puerto 8080, con una página de prueba servida por Python. cloudflared es el conector de código abierto que establece la conexión saliente hacia la red de Cloudflare. En Mac la instalación se hace con Homebrew. En Debian o Ubuntu hay que usar el repositorio oficial de Cloudflare, cuya clave de firma cambió hace poco, así que el autor aconseja seguir los comandos actuales y no los de tutoriales antiguos.
Un detalle que me pareció interesante: si haces trabajar agentes de IA con esta herramienta, Cloudflare recomienda un hook PreToolUse que bloquee cualquier comando sin --allowed-mail, para evitar que un agente exponga un túnel público por error.
Para un homelab es una alternativa ligera a abrir puertos o usar una VPN, siempre que recuerdes que un túnel público sigue siendo una exposición en Internet, aunque sea temporal.
Fuente: Korben
