DEV Community: Jarith

Home Assistant 2026.11.0: ¿actualizar ya o esperar? Qué revisar antes

Jarith — Fri, 06 Nov 2026 02:54:25 +0000

En breve: Según la documentación consultada el 2026-11-06, la versión 2026.11 es grande, pero el riesgo real para un homelab se concentra en dos cambios: la migración de HACS al Marketplace integrado y el nuevo sistema de nombres de entidades.

Resumen

Según la documentación consultada el 2026-11-06, la versión 2026.11 es grande, pero el riesgo real para un homelab se concentra en dos cambios: la migración de HACS al Marketplace integrado y el nuevo sistema de nombres de entidades. El resto de novedades importa menos a la hora de decidir.

Criterio de decisión:

Si usas pocas integraciones personalizadas y pocas tarjetas o plantillas que dependan del friendly name, actualizar es razonable con copia de seguridad y revisión previa.
Si tu dashboard está lleno de tarjetas personalizadas o plantillas que construyen textos a partir de nombres, esperar al primer parche es una opción prudente.

Lo que no debería preocuparte: los entity IDs, automatizaciones, scripts, escenas y dashboards seguirán funcionando. Lo que cambia es lo que ves, no a qué apuntan tus automatizaciones.

Qué ha cambiado

HACS pasa a ser el Marketplace

HACS se integra en Home Assistant como Marketplace (Ajustes > Marketplace), disponible en todos los tipos de instalación y sin cuenta de GitHub para instalar o actualizar. Es gratuito y lo hace la comunidad: el proyecto no lo prueba, audita ni soporta, y se ejecuta dentro de tu instancia.

Qué pasa con lo que ya tienes:

Si usas HACS, Home Assistant lo migra automáticamente al arrancar tras la actualización. Se conservan lo instalado, los repositorios personalizados y las entidades de actualización.
El instalador de HACS se detiene en 2026.11, así que ya no es posible una instalación separada en esta versión, y el HACS antiguo no recibirá nuevas versiones.
Instalar una integración desde el Marketplace no requiere reinicio, pero las actualizaciones todavía sí; tras actualizar, una reparación avisa si hace falta reiniciar.
Los repositorios personalizados requieren conexión con GitHub (inicio de sesión por dispositivo, solo lectura de información pública).
La fuente de descarga puede cambiarse a espejos de la comunidad china, pero entonces el catálogo y el código instalado pasan por quien gestiona el espejo y, si no se alcanza, por un proxy de terceros. Elige solo fuentes de confianza.

Como el instalador antiguo se detiene y el HACS antiguo no recibirá versiones, conviene tratar la migración como de un solo sentido y apoyarte en la copia de seguridad.

Nuevo sistema de nombres

El cambio es incompatible hacia atrás: algunos nombres en dashboards se verán distintos, sobre todo los de entidades que no empiezan por el nombre del dispositivo.

Qué nombres cambian. Si el nombre de la entidad ya empieza por el del dispositivo, se elimina esa parte. Si no, se mantiene y se añade el contexto: un switch llamado «Coffee machine» en «Smart plug 3» pasa a mostrarse «Smart plug 3 Coffee machine».

Cómo se arregla. Renombra el dispositivo y activa «Main entity of the device». Para entidades expuestas a Assist, Alexa o Google Assistant, el nombre antiguo se añade como alias, así que tus comandos de voz no deberían perderse.

Dispositivos hijo. Los dispositivos complejos se dividen en dispositivos hijo en Z-Wave, MQTT, ESPHome, algunos Tuya y otras integraciones; Matter y ZHA están en progreso. Si usas alguna de ellas, espera ver más dispositivos en tu lista tras actualizar.

Plantillas y tarjetas personalizadas. Aquí está el riesgo más probable: algunas tarjetas personalizadas y plantillas que usan el friendly name pueden mostrar nombres distintos a los integrados. Se recomienda usar entity_name(), device_name() y area_name() en plantillas. El friendly name se mantiene por compatibilidad, pero se planea deprecar.

Novedades que pueden justificar el salto

En automatizaciones puedes excluir entidades, dispositivos, áreas, plantas y etiquetas de un target. El cálculo se hace en cada ejecución, así que incluye elementos añadidos después.
Hay secciones de dashboard automáticas y copiar/pegar secciones.

Si no usas targets por área o etiqueta ni dashboards por secciones, estas novedades por sí solas no justifican correr.

Qué comprobar en tu homelab

Antes de actualizar

Haz una copia de seguridad guardada fuera del dispositivo. Pesa más si usas HACS, porque conviene tratar su migración como unidireccional.
Lee los «Backward-incompatible changes» de todas las notas entre tu versión y la de destino.
Localiza tus tarjetas personalizadas y plantillas que dependan del friendly name, y valora migrarlas a entity_name(), device_name() y area_name().
Si usas repositorios personalizados, asegúrate de poder iniciar sesión en GitHub por dispositivo.

Actualización

Por CLI: ha core update --backup.

Después de actualizar

Revisa Ajustes > Sistema > Reparaciones y Registros; ahí aparecerá el aviso de reinicio si lo requiere una actualización del Marketplace.
Abre Ajustes > Marketplace y comprueba que tus integraciones y repositorios personalizados siguen presentes, junto con sus entidades de actualización.
Recorre tus dashboards buscando nombres distintos; corrige renombrando el dispositivo y activando «Main entity of the device».
Verifica que las automatizaciones siguen funcionando: deberían, porque los entity IDs se mantienen.

Resumen de la decisión: actualiza ya si tu instalación es sencilla y puedes restaurar desde copia; espera al primer parche si dependes de muchas tarjetas personalizadas o plantillas con nombres.

Límites: no hay datos sobre requisitos de versión de Python o HA OS ni sobre incidencias posteriores al lanzamiento.

¿Lo usas en tu homelab? Cuéntalo en los comentarios.

Fuentes

Este artículo se ha elaborado con asistencia automatizada

WireGuard por tu cuenta o Tailscale en un homelab: qué plano de control quieres operar

Jarith — Mon, 02 Nov 2026 00:53:55 +0000

En breve: Respuesta corta: Tailscale es WireGuard con el trabajo de coordinación hecho por otro.

Resumen

Respuesta corta: Tailscale es WireGuard con el trabajo de coordinación hecho por otro. La pregunta real no es qué cifra mejor, sino qué parte del plano de control quieres operar tú: distribución de claves, configuración de endpoints y recuperación de conexiones tras NAT.

Criterio propio, apoyado en los datos de abajo:

Pocos nodos, uno con IP pública y ganas de controlarlo todo: WireGuard puro es una opción razonable, porque tú mantienes el endpoint y las claves.
Sin IP pública (CGNAT), varios usuarios o poco tiempo para mantenerlo: Tailscale, que funciona tras NAT sin abrir puertos y cuyo plan Personal es gratuito para uso no comercial.

Según la documentación consultada el 2026-11-02, estos son los datos en los que se apoya la decisión.

Criterios

1. Esfuerzo para llegar a un servicio desde fuera

WireGuard puro. El protocolo deja fuera de su alcance la distribución de claves y la configuración empujada. Cada peer necesita la clave pública del otro, y todo se define a mano con wg/wg-quick, AllowedIPs y Endpoint. Mi inferencia: al añadir un nodo nuevo habrá que revisar la configuración de los peers con los que deba hablar. Un esquema mínimo, con marcadores donde la fuente no da valores:

[Interface]
PrivateKey = <clave-privada-local>
Address = <ip-del-túnel>

[Peer]
PublicKey = <clave-pública-del-otro-peer>
AllowedIPs = <ips-permitidas>
Endpoint = <host-público>:<puerto>
PersistentKeepalive = 25

Tailscale. Al autenticar dos o más dispositivos se crea automáticamente la tailnet con políticas de acceso por defecto. Se despliega en minutos y las conexiones funcionan a través de firewalls y NAT sin abrir puertos. También puede enrutar todo el tráfico por un exit node.

2. CGNAT, hard NAT y UDP bloqueado

WireGuard puro. Un peer detrás de NAT o firewall que deba recibir paquetes tras un periodo de silencio necesita PersistentKeepalive. Está desactivado por defecto y 25 s es un valor razonable. Mi razonamiento, a partir de que cada peer se define con un Endpoint: si tu casa está tras CGNAT, nadie puede alcanzarla desde fuera, así que necesitarás un punto alcanzable (por ejemplo, un servidor externo) que tendrás que mantener tú. Las fuentes del pack no detallan este escenario.

Tailscale. Usa tres tipos de conexión: directa (UDP), relé DERP y Peer Relay. Todas van cifradas con WireGuard y la diferencia es de rendimiento. Empieza por DERP e intenta subir a directa. Con UDP bloqueado o hard NAT se queda en relé, que es más lento. Para favorecer conexiones directas puedes abrir el puerto UDP 41641 o habilitar NAT-PMP/UPnP en el router.

3. Control y privacidad del plano de control

Lo que cedes con Tailscale es la coordinación, no el cifrado del tráfico: los servidores DERP reenvían paquetes ya cifrados y no pueden descifrarlos. Lo que ganas con WireGuard puro es que tú mantienes el endpoint y las claves, y eso es a la vez control y trabajo.

Si te preocupan los relés, Tailscale desaconseja en general los DERP propios y recomienda Peer Relays: menor latencia, sin coste de egress y sin mantener derper. Los DERP propios, además, no soportan compartir dispositivos entre tailnets.

4. Coste para un homelab personal

El plan Personal de Tailscale es gratuito y de uso no comercial. Incluye dispositivos de usuario ilimitados, hasta 6 usuarios y 50 recursos etiquetados. Las tailnets creadas con dominio público (Gmail, etc.) se tratan como uso personal, y el homelab se menciona como caso típico. Con WireGuard puro, el coste que sale del pack es operativo: mantener el endpoint y las claves.

5. Medir latencia y tipo de conexión de forma equivalente

En Tailscale, tailscale status indica si la conexión es direct, relay o peer-relay, y tailscale ping sirve para sondear.

tailscale status
tailscale ping <nodo>

Para una prueba idéntica en ambos (criterio mío, no de las fuentes): lanza desde el mismo cliente, a la misma hora y hacia el mismo servicio, un ping ordinario a la IP del túnel de cada solución y compara los resultados. En Tailscale, consulta además tailscale status para saber si medías una conexión directa o un relé, ya que los tipos de conexión difieren en rendimiento. En WireGuard puro, el camino lo define el Endpoint que configures.

6. Rendimiento

Hay un aviso que afecta a equipos viejos, y procede de un issue en GitHub con confianza media, no de documentación oficial. Según ese issue, en Tailscale v1.100.0, v1.102.0 y v1.98.10 wireguard-go perdió la optimización en ensamblador anterior a AVX para ChaCha20-Poly1305. En CPUs amd64 antiguas el caudal cayó: con un Xeon E5-2697 v2 y SSSE3 se pasó de 61,1 a 30,8 Gbit/s. Se prepara restaurarlo, pero no consta el estado final del arreglo. Si tu servidor es un equipo antiguo, tenlo en cuenta. WireGuard, por su parte, presume de alto rendimiento en el kernel de Linux, aunque su web indica que está en desarrollo activo.

Qué dicen las fuentes

Límites

El pack no incluye medidas propias de latencia ni de rendimiento entre WireGuard puro y Tailscale. Tampoco cubre con detalle Headscale ni Cloudflare Tunnel.

¿Lo usas en tu homelab? Cuéntalo en los comentarios.

Fuentes

Este artículo se ha elaborado con asistencia automatizada

Pi-hole 6.5: ¿actualizar? Seguridad, gravity.db y qué revisar antes

Jarith — Wed, 28 Oct 2026 06:06:07 +0000

Resumen

Sí, conviene actualizar a Pi-hole 6.5, pero tras unas comprobaciones concretas. A fecha de 2026-10-28, según la página de la release consultada, Pi-hole Core v6.5 es sobre todo un endurecimiento de seguridad: corrige cuatro avisos de severidad alta (CVSS 7.8, 7.8, 7.8 y 7.3) y uno de severidad baja (CVSS 2.2). Además migra tu gravity.db automáticamente y retira un comando.

Criterio de decisión, razonado a partir de lo anterior:

Si tu Pi-hole es accesible para otros usuarios o servicios de la máquina, o ejecuta FTL con configuración editable, los avisos de root y ejecución de comandos justifican actualizar pronto.
Si usas arpflush en scripts o cron, o adlists file://, o gravity.db en una ruta personalizada, revisa esos puntos antes; si no, el riesgo de la actualización es bajo.

Qué ha cambiado

Vulnerabilidades corregidas

Los cuatro avisos de severidad alta son:

Ejecución de comandos mediante un PID manipulado (GHSA-cf36-4hhc-8398), CVSS 7.8.
Root siguiendo un symlink al escribir el archivo de versión (GHSA-xch2-4qxw-g5vj), CVSS 7.8.
/opt/pihole pasa a ser de solo lectura para el servicio FTL (GHSA-j8vh-6fp9-cjcx), CVSS 7.8.
Root escribiendo en rutas proporcionadas por la configuración (GHSA-mff6-cjc4-5wq9), CVSS 7.3.

El de severidad baja (GHSA-g63w-24cr-p3w6, CVSS 2.2) afecta a adlists file://: la comprobación de lectura y curl podían resolver archivos distintos; ahora las listas locales se leen como el usuario cuyo acceso se comprobó.

A ello se suma más endurecimiento de privilegios: el comprobador de actualizaciones y los ajustes previos al arranque de FTL se ejecutan como usuario pihole, solo se confía en repositorios git que pihole no pueda modificar, y se deja de conceder CAP_CHOWN a todo lo que ejecuta pihole-FTL (se mantiene en el conjunto ambient del servicio FTL).

Qué se elimina o cambia de comportamiento

arpflush se elimina en favor de networkflush. Si algún script o cron aún llama a arpflush, fallará; sustitúyelo por networkflush.
Adlists file://: se leen sin curl y su URI se interpreta con expansión de parámetros y canonicalización de ruta (RFC 8089). Si tus rutas locales usan formas poco habituales, comprueba que siguen resolviéndose.
listsCache se guarda junto a gravity.db en lugar de siempre en /etc/pihole. Es relevante si gravity.db está en una ruta personalizada o en volúmenes Docker: el directorio puede aparecer en otro sitio.
Otros cambios menores: se evita la doble rotación de logs ahora que pihole está en /etc/logrotate.d (con USR2 tras logrotate), /etc/pihole/versions es legible por todos, mejora el manejo de errores de gravity y el volcado de consultas de 24 h se hace vía API de FTL.

gravity.db

El esquema se mejora para rendimiento (tablas de unión WITHOUT ROWID, nuevos índices para búsquedas de grupos, triggers más baratos) y las bases existentes se migran automáticamente a la versión de esquema 21 al actualizar. Implicación práctica: la migración es automática, pero no está documentado cuánto tarda en bases grandes, y una vez migrada tu base ya no tendrá el esquema anterior; de ahí que una copia previa sea aquí especialmente útil.

Relación con FTL v6.8

La URL de origen del adlist se pasa a parseList de FTL, algo necesario para la corrección de adlists file:// de FTL v6.8. Si dependes de listas locales, el arreglo completo requiere esa versión de FTL; el pack no indica qué versión de FTL acompaña a Core 6.5.

¿Afecta a Debian 11?

Debian 11 se elimina de la matriz de distribuciones del CI de Pi-hole, lo que sugiere que deja de probarse en esta versión. No hay información de que deje de funcionar, pero si ejecutas Debian 11 asumes una combinación sin pruebas automáticas; plantéate migrar de sistema.

Qué comprobar en tu homelab

Copia con Teleporter. Pi-hole incluye Teleporter para copias de configuración. Expórtala antes de actualizar, porque gravity.db se migra de forma automática al esquema 21.
Scripts y cron. Busca usos de arpflush y cámbialos por networkflush.
Adlists locales. Si tienes entradas file://, verifica que el archivo es legible por el usuario correcto y que la ruta se interpreta como esperas. Comprueba también la versión de FTL (v6.8 para la corrección completa).
Rutas personalizadas y Docker. Si gravity.db no está en el sitio por defecto o usas volúmenes, localiza dónde queda listsCache tras actualizar. En Docker, el pack no detalla el impacto exacto ni cómo se versiona la imagen.
Permisos y automatizaciones propias. Si algo tuyo escribía en /opt/pihole desde FTL, o dependía de que pihole-FTL tuviera CAP_CHOWN, puede dejar de funcionar.
Sistema operativo. Si estás en Debian 11, tenlo presente.

Límites: no hay datos sobre problemas conocidos tras actualizar ni sobre la duración de la migración en bases grandes.

¿Lo usas en tu homelab? Cuéntalo en los comentarios.

Fuentes

Este artículo se ha elaborado con asistencia automatizada

Home Assistant 2026.10: actualiza directamente a 2026.10.3 y revisa estas integraciones

Jarith — Sun, 25 Oct 2026 23:39:35 +0000

En breve: Sí, conviene actualizar, y lo razonable es saltar directamente a 2026.10.3. A fecha de 2026-10-24, según las notas de publicación consultadas, 2026.10.3 (publicada el 23 de octubre) figura como Latest.

Resumen

Sí, conviene actualizar, y lo razonable es saltar directamente a 2026.10.3. A fecha de 2026-10-24, según las notas de publicación consultadas, 2026.10.3 (publicada el 23 de octubre) figura como Latest. La rama salió el 7 de octubre con 2026.10.0, y después llegaron 2026.10.1 (10 de octubre), 2026.10.2 (16 de octubre) y 2026.10.3. Como los parches corrigen integraciones habituales en un homelab, no hay motivo para quedarse en 10.0 ni para instalar un parche intermedio.

Criterio de decisión: si usas MQTT, Modbus, KNX, FRITZ!Box, UniFi o Proxmox, los parches te afectan de forma directa. Si no usas ninguna, el cambio más visible para ti será el mapa.

Qué ha cambiado

Cambios de fondo de 2026.10.0

Mapa. El proveedor de mapas anterior empezó a exigir API key y rompió todos los mapas en 2026.9. Ahora se usan teselas vectoriales de OpenStreetMap servidas por la nueva integración Map tiles, que las obtiene y cachea a través de tu instancia, de modo que el navegador no contacta con servidores externos de teselas. Quien puede verse afectado son los dispositivos antiguos incapaces de renderizar mapas vectoriales, como una tablet de pared vieja: vuelven automáticamente al mapa clásico.

Trigger IDs. Ahora tienen interfaz: la condición «Triggered by» permite marcar triggers y Home Assistant gestiona los IDs. Tus IDs escritos a mano en YAML siguen funcionando igual, compartir ID entre triggers sigue permitido y Home Assistant no añade IDs a tu YAML. El campo de ID desaparece del editor. Por tanto, tus automatizaciones no deberían cambiar; lo único distinto es la edición desde la UI.

Modbus. Hay 15 integraciones nuevas, entre ellas SolarEdge Modbus (local por Modbus TCP, sin cuenta ni cloud) y KACO Modbus, además de un panel para conexiones Modbus. Si tienes un inversor solar, puede interesarte, pero no es un motivo para actualizar por sí solo.

Parches relevantes en un homelab

2026.10.1: trae un cambio marcado como breaking-change: se elimina el intervalo de sondeo configurable por el usuario en omnilogic. También restauró TLS sin verificar para fuentes de stream con la opción verify_ssl y omitió la verificación TLS en streams RTSPS de UniFi Protect.
2026.10.2: MQTT device triggers y tags ya no se disparan dos veces tras recargar; se arregló la validación de permisos de ProxmoxVE; FRITZ!Box Tools ignora dispositivos sin TR-064 en el descubrimiento SSDP y el setup de Fritz ya no falla si falta la clave NewEnable; se arregló la recarga de Modbus sin config YAML.
2026.10.3: correcciones en Proxmox VE (detección de versión de actualización), UniFi Access (eventos de acceso duplicados), Omada, SMTP (nuevo contexto SSL en lugar de uno compartido), Synology DSM, Home Connect, EnergyZero y KNX (se retiene el timeout de arranque mientras inicializa el almacén de telegramas). Incluye además Python 3.14.8.

Seguridad y privacidad

2026.10.2 revoca los refresh tokens al eliminar un usuario y oculta credenciales o datos identificativos en los diagnósticos de SFR Box, NRGkick, Teslemetry y Tesla Fleet. Si compartes diagnósticos para pedir ayuda, esto reduce el riesgo de filtrar datos, pero solo en esas integraciones.

Qué comprobar en tu homelab

Omnilogic: si lo usas y habías configurado un intervalo de sondeo propio, ese ajuste desaparece.
Streams de cámaras: si dependías de verify_ssl en fuentes de stream, o tienes UniFi Protect con RTSPS, revisa que sigan funcionando, porque 10.1 modificó el comportamiento de la verificación TLS. Que RTSPS de UniFi Protect omita la verificación es un matiz de seguridad a tener en cuenta si tu cámara está en una red que no controlas por completo.
MQTT, Modbus, KNX, FRITZ!Box, Proxmox: si en 10.0 notaste disparos duplicados, fallos al recargar, setups de Fritz que fallaban o permisos de Proxmox rechazados, estos son los síntomas que 10.2 y 10.3 corrigen.
UniFi Access: si registras eventos de acceso, los duplicados deberían desaparecer con 10.3.
SMTP: si envías notificaciones por correo, comprueba tras actualizar que siguen llegando, ya que ahora se crea un contexto SSL nuevo en lugar de compartido.
Dispositivos con pantalla: si tienes tablets antiguas mostrando mapas, espera el mapa clásico como alternativa automática.
Automatizaciones con triggers: no hace falta tocar nada si ya usas IDs en YAML.

Aviso de futuro

Home Assistant Cloud pasará a llamarse Home Assistant Link en la versión de diciembre; es solo un cambio de nombre anunciado.

Límites

Las notas disponibles no permiten confirmar la lista completa de cambios incompatibles de 2026.10.0, ni requisitos de instalación o problemas conocidos al actualizar. Tampoco hay compatibilidad documentada entre una versión concreta de Proxmox VE y la integración de Home Assistant.

¿Lo usas en tu homelab? Cuéntalo en los comentarios.

Fuentes

Este artículo se ha elaborado con asistencia automatizada

Ollama 0.40.7: qué cambia y a quién afecta en un homelab

Jarith — Wed, 21 Oct 2026 15:51:47 +0000

Resumen

Según el listado de releases consultado para este artículo, v0.40.7 aparece como Pre-release (tag v0.40.7-rc1) y no como Latest. En ese mismo listado, la versión marcada como Latest era v0.40.6.

La página individual de v0.40.7 no pudo descargarse, así que no puedo confirmar que exista una versión estable final ni su fecha. Para un homelab, lo prudente es tratarla como candidata y no como la versión a la que actualizar por defecto.

Qué ha cambiado

En v0.40.7 (pre-release)

Se permite el parámetro effort de la API Responses de OpenAI en modelos sin modo thinking (#19010).
llama-server infiere el tipo de speculative decoding del draft (#19064).
Se añade soporte de PPLX Decider v1.2 en MLX (#19072).

El extracto disponible no incluye notas de breaking changes ni requisitos de hardware específicos para esta versión.

En v0.40.6 (Latest en el listado)

Evita runners huérfanos en Windows (#18500).
Añade los tipos de tensor y de archivo q2_0 a GGUF (#18967).
Lanza clef en la nube de Ollama (#19036).
Usa identificadores para las claves de pregunta del modo --ask (#19041).

Lo que arrastra la serie 0.40

Si vienes de una versión anterior, lo que más te afectará probablemente no está en 0.40.7, sino en las versiones intermedias:

v0.40.0: en Apple Silicon, las arquitecturas soportadas por el runtime MLX se ejecutan en MLX por defecto. Entre los modelos mencionados están gemma4, qwen3.6 y qwen3.5.
v0.40.1: añade un proxy de las APIs de uso y saldo de la nube (#18829) y elimina el paso de cuenta del onboarding del CLI (#18826). En Windows, evita symlinks en el manifest (#18852).
v0.40.2: los modelos descargados con versiones anteriores se actualizan en segundo plano la primera vez que se ejecutan, para mejorar el rendimiento y la compatibilidad con llama.cpp.
v0.40.3: pausó esa actualización en segundo plano por el rendimiento de las peticiones (embeddings y otras).
v0.40.4: mejora el rendimiento de inferencia reutilizando manifests verificados y modelos ya cargados. También añade soporte de embeddings multimodales vía llama-server y corrige la carga de modelos de embeddings multimodales con ventanas de contexto pequeñas.

Qué comprobar en tu homelab

1. Espacio en disco. Ollama conserva la copia original de los modelos migrados como respaldo para poder hacer downgrade, así que los modelos actualizados ocupan espacio extra temporalmente. Las notas de v0.40.2 incluyen un script (requiere jq) que consulta /api/tags y /api/show, selecciona los manifests con runner ggml de los modelos que tienen manifest llamacpp y los elimina con ollama rm. Solo borra los respaldos: si después vuelves a una versión anterior a 0.40, tendrás que hacer pull de esos modelos otra vez. Los extractos no indican si estos respaldos se eliminan ya automáticamente, así que revisa tú el uso de disco.

2. Windows. Los dos cambios relevantes son que v0.40.1 evita symlinks en el manifest (#18852) y que v0.40.6 evita runners huérfanos (#18500). Si usas Windows, la v0.40.6 es la que incluye esta última corrección.

3. Apple Silicon. Si tienes un Mac como servidor, ten presente que los modelos de arquitecturas soportadas por MLX se ejecutan en MLX por defecto desde v0.40.0. Compara resultados y rendimiento tras actualizar.

4. Uso de embeddings. Si tu stack (por ejemplo, RAG) depende de embeddings, revisa lo ocurrido en v0.40.3 y v0.40.4.

Recomendaciones generales (no proceden de las fuentes):

Haz una copia o un listado de tus modelos antes de actualizar.
Prueba primero en una máquina secundaria.
Espera a que v0.40.7 deje de figurar como pre-release antes de ponerla en un servicio que uses a diario.

Limitaciones de las fuentes. Las fechas de las releases aparecen sin año en las páginas individuales. Además, varias de las páginas consultadas (v0.40.4, v0.40.5, v0.40.6 y el listado general) figuran como no oficiales en la entrada, aunque su contenido corresponde a las releases de GitHub de ollama/ollama.

Fuentes

Este artículo se ha elaborado con asistencia automatizada

Guía práctica: Tailscale 1.104.1 en un homelab paso a paso

Jarith — Wed, 21 Oct 2026 02:50:52 +0000

Resumen

Esta guía recoge el procedimiento documentado para instalar Tailscale en un equipo Linux de un homelab, autenticarlo en tu tailnet y comprobar que funciona. Como referencia de versión usamos la release v1.104.1 de tailscale/tailscale: la página de GitHub la mostraba marcada como «Latest» en el momento en que se descargó, y remite al changelog oficial.

Importante: las fuentes consultadas no explican cómo fijar o instalar específicamente la versión 1.104.1 con el script de instalación. Tampoco se sabe qué cambia respecto a 1.104.2, cuya página de GitHub no pudo consultarse. Además, la documentación utilizada no se ha confirmado como reflejo exacto de 1.104.1. Trata los pasos como el procedimiento general documentado para el cliente de Linux.

Requisitos

Un equipo Linux con gestor de paquetes (apt, yum o zypper).
Acceso con sudo y una cuenta para autenticar el equipo en tu tailnet.
El módulo de kernel tun. Si falta, se carga con sudo modprobe tun. Para cargarlo en cada arranque, se añade tun a /etc/modules o a /etc/modules-load.d/tun.conf.
Si tu homelab incluye otros clientes: según el changelog consultado, Tailscale v1.104 requiere macOS Ventura 13 o posterior (no funciona en Monterey 12) y iOS 16 o posterior (no soporta iOS 15). Esto no afecta a Linux.

Pasos documentados

1. Instalar

En distribuciones con apt, yum o zypper, la documentación de Linux describe un script de instalación de una sola línea que se descarga con curl y se pasa a sh. Copia el comando exacto desde la página oficial de instalación en Linux (enlazada en «Fuentes») en lugar de reescribirlo de memoria. Como recomendación general, si prefieres revisar el script antes de ejecutarlo, descárgalo primero a un archivo y léelo.

2. Alternativa: binarios estáticos

Para distribuciones no cubiertas por el script existen binarios estáticos:

tar xvf tailscale_<version>_<arquitectura>.tgz
sudo tailscaled --state=tailscaled.state
sudo tailscale up

El archivo incluye una configuración de servicio systemd en el subdirectorio systemd/.

3. Autenticar el equipo

sudo tailscale up

El comando muestra una URL para autenticar el equipo en la tailnet. Después, confirma que el dispositivo aparece en la página Machines de la consola de administración.

4. Activar Tailscale SSH (opcional)

tailscale set --ssh

También existe el flag --ssh en tailscale up, que por defecto es false y permite el acceso según la política de acceso de la tailnet.

5. Caducidad de clave en servidores

En servidores, Raspberry Pi, hosts Docker o NAS se puede desactivar la caducidad de clave (key expiry) desde la página Machines de la consola. Esto reduce la seguridad y solo debe hacerse en dispositivos de confianza. Si la clave ya caducó, se fuerza la reautenticación con:

sudo tailscale up --force-reauth

6. Actualizar

El cliente puede actualizarse con tailscale update (Linux, Windows y macOS), desde la página de descargas o desde el sitio de paquetes de Tailscale, que ofrece las pistas stable, release candidate y unstable. También se pueden configurar actualizaciones automáticas.

Verificación

tailscale ip
tailscale status

tailscale ip muestra las direcciones IPv4 (100.x.y.z) e IPv6 Tailscale del equipo; con -4 o -6 se filtra la familia.
tailscale status muestra el estado de la conexión.

Comprueba además que la máquina figura en la página Machines de la consola.

Fuentes

Este artículo se ha elaborado con asistencia automatizada

Docker: qué cambia para quien se autoaloja

Jarith — Sun, 18 Oct 2026 00:05:11 +0000

Resumen

Si autoalojas servicios con Docker, las notas de versión de la serie 29 traen sobre todo correcciones de seguridad y algunos cambios de comportamiento que conviene revisar antes de actualizar. Según las notas de versión de Docker Engine consultadas el 2026-10-17, la última versión listada es la 29.9.1 (2026-10-14). Este estado se refiere a esas notas y puede haber cambiado desde entonces.

Qué ha cambiado

Seguridad

29.9.1 (2026-10-14): actualiza containerd a v2.4.2. Esa versión corrige CVE-2026-95839 (caída de containerd al hacer pull o import con un descriptor hijo con anotación io.containerd.manifest.subject y digest malformado), GHSA-8647-2jxj-p2rc (registro no confiable con Content-Length manipulado) y GHSA-hc94-p972-ch66 (agotamiento de disco por capas sin límite de tamaño declarado).
29.9.0 (2026-10-08): actualiza el runtime de Go y corrige cinco CVE (cuatro de HTTP/2 que podían tumbar el daemon o agotar memoria y CPU, y uno de Windows). También actualiza BuildKit a v0.34.0 y containerd a v2.4.1.
29.8.2 (2026-09-30): corrige CVE-2026-53493 (índice OCI manipulado con consumo ilimitado de CPU y memoria), CVE-2026-92543 (respuesta DNS maliciosa que podía omitir la verificación TLS del registro o degradar a HTTP) y CVE-2026-92542 (tramas Ethernet falsificadas en redes overlay cifradas de Swarm). Corrige además varios CVE de BuildKit (CVE-2026-93315 a CVE-2026-93323 y CVE-2026-93326).

Redes

En 29.9.0 se corrige un fallo en redes overlay cifradas. Ante errores al programar el kernel, parte del tráfico hacia algunos nodos podía enviarse en claro. La pérdida de confidencialidad se limita a flujos unidireccionales (por ejemplo, consultas DNS UDP) e intentos de handshake que no prosiguen.
También en 29.9.0, los puertos publicados de servicios Swarm pasan a ser accesibles en las direcciones IPv6 del host con el proxy de usuario habilitado. Una modificación de v29.8.0 lo habilitó de forma incidental y desde 29.9.0 es una función probada y soportada.

Otros cambios de comportamiento

En 29.8.0 se añade la opción --umask en docker create y docker run, se reservan los nombres de red container y container:, y el mínimo de Go del SDK pasa a 1.26.
En 29.7.0 empezaron a respetarse los límites de descargas y subidas concurrentes con el almacén de imágenes containerd. Para conservar el comportamiento previo sin límite hay que configurar max-concurrent-downloads y max-concurrent-uploads a 0. Esa versión introdujo además regresiones en pulls, corregidas en 29.7.1 y 29.7.2.

Docker Desktop

Docker Desktop 4.94.0 (2026-10-05) incluye Docker Engine v29.8.2 y cambia el driver de logging por defecto de los contenedores Linux nuevos a local, que rota los logs automáticamente. Docker Desktop 4.95.0 (2026-10-12) es la última versión listada en las notas consultadas el 2026-10-17. El Engine que trae Desktop no tiene por qué coincidir con el último Engine publicado.

Qué comprobar en tu homelab

Según la documentación

Origen del paquete: los paquetes de los repositorios de cada distribución los mantienen los empaquetadores de la distro y pueden diferir en configuración o código. Docker ofrece además binarios estáticos para instalación manual. Comprueba de dónde viene tu instalación para saber qué versión puedes obtener.
Compatibilidad de parches: la documentación de instalación indica que los parches son siempre retrocompatibles con su versión mayor y menor. También indica que existen los canales stable y test, y que el test incluye funciones experimentales sujetas a cambios incompatibles.
Soporte: Docker no ofrece soporte para Docker Engine como tal, que es un proyecto open source respaldado por Moby.
Exposición de la API: según la guía de seguridad, exponer la API del daemon por HTTP sin TLS no está permitido y hace que el daemon falle al arrancar. Se recomienda TLS o SSH (DOCKER_HOST=ssh://) y que el daemon solo sea alcanzable desde una red de confianza o VPN.
Límites de concurrencia: si usas el almacén de imágenes containerd y dependías de descargas sin límite, revisa max-concurrent-downloads y max-concurrent-uploads.
Swarm e IPv6: si usas Swarm, revisa qué puertos publicados quedan accesibles por IPv6.
Logs en Desktop: si usas Docker Desktop, ten en cuenta el nuevo driver de logging por defecto en contenedores nuevos.

Recomendaciones generales

Son consejos propios, no afirmaciones de las fuentes:

Haz copia de seguridad de volúmenes y de los ficheros Compose antes de actualizar.
Anota la versión actual para poder volver atrás.
Actualiza primero un servicio o nodo poco crítico.
Revisa los logs tras el cambio.

Lo que las fuentes no aclaran

Las fuentes consultadas no detallan los pasos de actualización por distribución ni los cambios de ruptura entre series. Tampoco indican la versión mínima recomendada de partida ni la política de soporte de ramas anteriores. Consulta las notas oficiales completas antes de actualizar.

Fuentes

Docker Engine version 29 release notes: https://docs.docker.com/engine/release-notes
Docker Desktop release notes: https://docs.docker.com/desktop/release-notes
Install Docker Engine: https://docs.docker.com/engine/install
Docker Engine security: https://docs.docker.com/engine/security

Este artículo se ha elaborado con asistencia automatizada

n8n 2.44.0: qué cambia y a quién afecta en un homelab

Jarith — Fri, 16 Oct 2026 16:02:37 +0000

Resumen

n8n 2.44.0 se publicó el 2026-10-13 y aparece marcada como Pre-release en GitHub; incluye una larga lista de correcciones y novedades. Después han llegado tres parches: 2.44.1 (2026-10-14), 2.44.2 (2026-10-15) y 2.44.3 (2026-10-16).

Según la documentación de n8n para Docker consultada el 2026-10-16, la versión estable es 2.43.7 y la beta es 2.44.3; la beta puede ser inestable y la estable es la recomendada para producción. Si tu homelab es de uso real y no de pruebas, conviene tenerlo en cuenta antes de saltar a 2.44.x.

Qué ha cambiado

2.44.0

Novedades: nueva credencial Google Vertex AI, nodo Microsoft SharePoint Trigger, opción configurable de timeout del health check y política de bloqueo de creación/actualización de workflows con nodos deprecados.
Observabilidad: métricas Prometheus para la recuperación de la conexión a base de datos, métricas servidas mientras la base de datos no está disponible, y el ID de ejecución en cada span OTel.
Queue mode/workers: los jobs desencolados durante el apagado de un worker, o recuperados antes de pausarse, se devuelven a la cola; los jobs se cuentan como en ejecución desde el inicio de su procesamiento; y cada segmento de Chat Hub se gestiona una sola vez.

Parches posteriores

2.44.1: solo añade mostrar los modelos Gemini por nombre y listar primero los priorizados en los selectores de modelo.
2.44.2: corrige que se cree un parser XML nuevo para cada cuerpo de petición de webhook.
2.44.3: corrige que se descartara la respuesta en lugar de conservar las líneas de detalle del Observer.

Qué comprobar en tu homelab

Estable o beta. A fecha de 2026-10-16, la documentación señala 2.43.7 como estable y 2.44.3 como beta. Decide si quieres probar la beta o esperar.
Cambios incompatibles. Las fuentes consultadas no indican si 2.44.0 trae breaking changes para self-hosting; las notas de GitHub solo listan fixes y novedades. La guía de actualización recomienda revisar las release notes por cambios incompatibles. La página de release notes de la documentación está truncada y no cubre 2.44, así que revisa las notas de GitHub directamente.
Workflows con nodos deprecados. Como 2.44.0 incluye una política de bloqueo de creación/actualización con nodos deprecados, revisa si alguno de tus workflows los usa.
Prueba primero. La guía recomienda actualizar con frecuencia (al menos una vez al mes) y probar antes la actualización en una instancia de test.
Queue mode. Si usas workers, todos los workers y mains deben ejecutar la misma versión, y la clave de cifrado de la instancia principal debe compartirse con los workers. Los arreglos de 2.44.0 te afectan sobre todo en este escenario.
Observabilidad. Si monitorizas con Prometheus u OpenTelemetry, las nuevas métricas y el ID de ejecución en los spans pueden resultarte útiles.

Cómo actualizar con Docker

Con Docker Compose: ve al directorio del compose y ejecuta docker compose pull, docker compose down y docker compose up -d. Con docker run, haz pull de una versión concreta (docker pull n8nio/n8n:<versión>), para y elimina el contenedor y vuelve a arrancarlo.

Recomendación general: antes de actualizar, haz una copia de seguridad de tus datos y fija una versión concreta en lugar de usar una etiqueta flotante.

Fuentes

Este artículo se ha elaborado con asistencia automatizada