EtherChannel Cisco, también llamado PortChannel, agrupa varios enlaces físicos entre dos switches en un solo enlace lógico. En lugar de tener dos o cuatro cables que STP bloquearía por redundancia, el switch los ve como un único enlace con el ancho de banda sumado y con tolerancia a fallos. En este artículo verás sus ventajas, sus desventajas, los tipos que existen y cómo configurarlo paso a paso.
Table of Contents
¿Qué es EtherChannel (PortChannel)?
EtherChannel es la tecnología de agregación de enlaces de Cisco: toma de 2 a 8 enlaces físicos (hasta 16 en algunos modelos, con 8 activos) y los presenta como una sola interfaz lógica, Port-channel. El tráfico se reparte entre los enlaces y, si uno falla, el resto sigue pasando tráfico sin que STP tenga que recalcular nada, porque para STP el PortChannel es un solo enlace.
El nombre cambia según la plataforma: en IOS clásico se llama EtherChannel y la interfaz lógica es Port-channel; en Nexus e IOS XE más recientes se habla de PortChannel. Es la misma tecnología.
Ventajas
Más ancho de banda: dos enlaces de 1 Gbps forman un enlace lógico de 2 Gbps.
Redundancia: si un cable o un puerto falla, el tráfico sigue por los enlaces restantes sin interrupción.
Balanceo de carga: el tráfico se reparte entre los enlaces según el método configurado (por IP, por MAC, etc.).
Sin enlaces bloqueados por STP: sin EtherChannel, STP bloquearía los enlaces redundantes; con EtherChannel todos pasan tráfico.
Escalable: puedes añadir enlaces al grupo sin cambiar la topología.
Desventajas
La configuración debe coincidir en ambos extremos: si un lado negocia LACP y el otro está en estático, el grupo no se forma o queda en estado suspendido.
Todos los enlaces deben tener la misma velocidad y el mismo dúplex.
El balanceo es por flujo, no por paquete: una sola transferencia no supera la velocidad de un enlace individual, aunque el total sí sume.
Más complejidad: hay más cosas que revisar cuando algo falla (modos, VLAN, estado de cada miembro).
Si la configuración de VLAN no coincide en los miembros, el tráfico puede ir a la VLAN equivocada.
Tipos de EtherChannel
Tipo
Protocolo
Modos
Cuándo usarlo
Estático
Ninguno (sin negociación)
on
Cuando el otro extremo no soporta negociación o quieres un grupo fijo
LACP
IEEE 802.3ad (estándar abierto)
active / passive
Recomendado: funciona entre marcas y negocia el grupo
PAgP
Propietario de Cisco
desirable / auto
Solo entre equipos Cisco; hoy en desuso frente a LACP
Estático (mode on): no hay negociación; el grupo se forma porque así lo configuraste en ambos lados. Es rápido, pero si un extremo está mal, no hay forma de detectarlo.
LACP (active/passive): el estándar. Un extremo en active inicia la negociación; passive solo responde. Para que el grupo se forme, al menos un extremo debe estar en active.
PAgP (desirable/auto): el protocolo propietario de Cisco. Desirable inicia la negociación, auto solo responde. Solo funciona entre equipos Cisco, por eso hoy se recomienda LACP.
Además, el PortChannel puede ser de Capa 2 (el más común: lleva VLAN y se configura como trunk o access) o de Capa 3 (con no switchport y una dirección IP, para enrutar entre switches).
Cómo configurar EtherChannel con LACP (Capa 2)
Ejemplo: dos enlaces Gi1/0/1 y Gi1/0/2 entre dos switches, como trunk con las VLAN 10 y 20.
Switch# configure terminal
Switch(config)# interface range gigabitethernet1/0/1 - 2
Switch(config-if-range)# switchport mode trunk
Switch(config-if-range)# switchport trunk allowed vlan 10,20
Switch(config-if-range)# channel-group 1 mode active
Switch(config-if-range)# end
Switch# show etherchannel summary
El comando channel-group 1 mode active crea automáticamente la interfaz Port-channel1 y añade los dos puertos al grupo 1 en modo LACP activo. La configuración del trunk se aplica a los miembros y se hereda a la interfaz Port-channel.
Verificación:
Switch# show etherchannel summary
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) LACP Gi1/0/1(P) Gi1/0/2(P)
Po1(SU) significa que es un PortChannel de Capa 2 (S) y está en uso (U); la (P) junto a cada puerto indica que está agregado al grupo. Si un puerto aparece con (s), está suspendido: revisa que la configuración coincida en ambos extremos.
Balanceo de carga (opcional):
Switch(config)# port-channel load-balance src-dst-ip
Switch# show etherchannel load-balance
Errores comunes
Modos incompatibles: dos extremos en passive (o en auto) nunca negocian; uno debe ser active (o desirable).
Mezclar LACP con estático: un lado en mode active y el otro en mode on no forma el grupo.
Velocidades o dúplex distintos entre los miembros del grupo.
VLAN distintas en los puertos miembros: la configuración debe ser idéntica en todos.
Configurar solo el Port-channel y no los miembros (o al revés): la configuración se aplica a los miembros y se refleja en la interfaz lógica.
Conclusión
EtherChannel convierte varios enlaces en uno solo: más ancho de banda, redundancia y balanceo sin que STP bloquee nada. Para la mayoría de los casos, configura el grupo con LACP en modo active en ambos extremos, verifica con show etherchannel summary y revisa que la configuración coincida en los dos switches.
Las VLAN permiten dividir un switch físico en varias redes lógicas, cada una con su propio dominio de broadcast. En esta guía aprenderás cómo crear una VLAN en un switch Cisco desde cero, con los comandos para crearla, asignar puertos access y trunk, y verificar que todo funcione.
Table of Contents
¿Qué es una VLAN y para qué sirve?
Una VLAN (Virtual LAN) agrupa dispositivos en una misma red lógica aunque no compartan el mismo switch físico. Por ejemplo, puedes poner a Ventas en la VLAN 10 y a TI en la VLAN 20, y aunque estén conectados al mismo switch, no verán el tráfico entre sí sin un router.
Sus beneficios principales son la segmentación de la red, mayor seguridad, menos tráfico broadcast y una organización más clara por departamentos o funciones.
Requisitos antes de empezar
Acceso al switch por consola, SSH o Telnet.
Contraseña del modo privilegiado (enable).
Un plan claro de qué VLAN crear y qué puertos asignar. Para este ejemplo usaremos:
VLAN 10 — Ventas — puertos Fa0/1 a Fa0/5
VLAN 20 — TI — puertos Fa0/6 a Fa0/10
Puerto Gi0/1 como trunk hacia otro switch
Paso 1. Crear la VLAN
Entra al modo de configuración global y crea la VLAN con un número y un nombre:
Switch> enable
Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name Ventas
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# name TI
Switch(config-vlan)# end
Switch# show vlan brief
Con show vlan brief confirmas que las VLAN 10 y 20 aparecen como activas. Recuerda: los ID válidos van del 1 al 4094, la VLAN 1 es la predeterminada y no conviene usarla para equipos de usuario, y las VLAN 1002 a 1005 están reservadas.
Paso 2. Asignar puertos access a la VLAN
Un puerto en modo access pertenece a una sola VLAN y se usa para conectar equipos finales como PC, impresoras o puntos de acceso:
En switches antiguos, antes de switchport mode trunk puede ser necesario ejecutar switchport trunk encapsulation dot1q. En IOS moderno el trunk ya usa 802.1Q por defecto.
Paso 4. Verificar la configuración
Estos comandos te muestran si la VLAN quedó bien configurada:
Switch# show vlan brief
Switch# show interfaces trunk
Switch# show interfaces fastethernet0/1 switchport
Verifica que la VLAN aparezca como activa, que los puertos estén listados en su VLAN y que el trunk tenga permitidas las VLAN 10 y 20.
Paso 5. Guardar la configuración
Este es el paso que más se olvida. Si no guardas, la configuración se pierde al reiniciar el switch:
Switch# copy running-config startup-config
Las VLAN del 1 al 1005 también se guardan en el archivo vlan.dat, pero la asignación de puertos vive en la running-config, así que guarda siempre.
Ejemplo completo
Toda la configuración junta para el ejemplo de Ventas y TI:
enable
configure terminal
vlan 10
name Ventas
vlan 20
name TI
interface range fastethernet0/1 - 5
switchport mode access
switchport access vlan 10
interface range fastethernet0/6 - 10
switchport mode access
switchport access vlan 20
interface gigabitethernet0/1
switchport mode trunk
switchport trunk allowed vlan 10,20
end
show vlan brief
copy running-config startup-config
Errores comunes al crear una VLAN en un switch Cisco
No guardar la configuración y perderla al reiniciar el switch.
Dejar los equipos de usuario en la VLAN 1, la predeterminada.
Configurar el trunk sin permitir las VLAN, o con la lista de allowed vlan incompleta.
Asignar el puerto a una VLAN que no existe. En algunos modelos el switch la crea automáticamente al asignarla, pero es mejor crearla explícitamente.
Olvidar que un puerto trunk no lleva IP ni modo access.
Conclusión
Crear una VLAN en un switch Cisco se resume en tres comandos: vlan para crearla, switchport mode access para definir el puerto y switchport access vlan para asignarlo. Con la verificación y el guardado, la segmentación queda lista para usarse.
En próximos articulos veremos cómo hacer que estas VLAN se comuniquen entre sí con enrutamiento entre VLAN.
Visita nuestros artículos de homelab y automatización, temas como wordpress, docker, uptime kuma, etc.
Cuando administramos un Home Server, normalmente terminamos utilizando diferentes aplicaciones para cubrir nuestras necesidades: monitorización, almacenamiento, automatización del hogar, administración de servicios y publicación de contenido.
El problema aparece cuando queremos que todas estas aplicaciones trabajen juntas.
Por ejemplo, ¿qué pasaría si pudiéramos recibir una notificación de Telegram cuando un servicio deja de funcionar? ¿O ejecutar una tarea automáticamente cada día, consultar una API, procesar información y enviar un reporte sin tener que intervenir manualmente?
Para conseguirlo podemos utilizar n8n, una plataforma de automatización de flujos de trabajo que permite conectar diferentes aplicaciones y servicios mediante una interfaz visual.
En este artículo veremos qué es esta plataforma, cuáles son sus principales funcionalidades, cómo instalarlo utilizando Docker Compose y algunos casos de uso prácticos para aprovecharlo en nuestro Home Server.
Table of Contents
1. ¿Qué es n8n?
Es una plataforma de automatización de flujos de trabajo (workflow automation) que permite conectar aplicaciones, servicios, bases de datos y APIs para ejecutar tareas de forma automática.
Su principal característica es que utiliza una interfaz visual donde podemos construir flujos de trabajo mediante bloques llamados nodos.
Cada nodo representa una operación específica, como:
Recibir información desde una aplicación.
Consultar una API.
Procesar datos.
Ejecutar una condición.
Enviar un mensaje.
Guardar información en una base de datos.
Ejecutar una acción en otro servicio.
Los nodos se conectan entre sí para construir un flujo de trabajo que se ejecuta cuando ocurre un evento o se cumple una condición determinada.
Esta herramienta puede utilizarse sin necesidad de programar, aunque también permite incorporar JavaScript, expresiones y solicitudes HTTP para desarrollar automatizaciones más avanzadas.
Es importante mencionar que esta herramienta utiliza un modelo de licencia fair-code, por lo que no debe confundirse con un proyecto de código abierto tradicional bajo una licencia OSI.
2. ¿Para qué sirve n8n?
El objetivo principal es reducir las tareas repetitivas y facilitar la comunicación entre diferentes aplicaciones.
Imaginemos que tenemos un servidor con Docker donde ejecutamos varios servicios:
Cada aplicación tiene sus propias funcionalidades, pero eso no significa que todas puedan comunicarse directamente entre sí.
La plataforma funciona como un intermediario que permite conectar estos servicios y establecer reglas para ejecutar acciones automáticamente.
Por ejemplo, podemos crear un flujo que reciba una alerta de Uptime Kuma, procese la información y envíe una notificación a Telegram.
También podemos programar tareas para consultar información periódicamente, procesar archivos o interactuar con servicios externos.
3. Principales funcionalidades
Automatización mediante workflows
La funcionalidad principal es la creación de flujos de trabajo.
Un workflow está compuesto por diferentes nodos que se ejecutan siguiendo una secuencia lógica.
Por ejemplo:
Un evento inicia el flujo.
n8n recibe información.
Procesa los datos.
Evalúa una condición.
Ejecuta una acción.
Devuelve un resultado.
Esto permite construir automatizaciones sencillas o procesos mucho más complejos.
Integración con aplicaciones y servicios
Este servicio dispone de una biblioteca de integraciones que permite conectar diferentes plataformas.
Podemos trabajar con servicios como:
Telegram.
Discord.
Google Sheets.
Gmail.
GitHub.
WordPress.
Home Assistant mediante APIs.
Bases de datos.
Servicios de almacenamiento.
Plataformas de inteligencia artificial.
Además, mediante el nodo HTTP Request podemos realizar solicitudes a prácticamente cualquier servicio que disponga de una API compatible.
Automatizaciones programadas
No todas las automatizaciones necesitan ejecutarse cuando ocurre un evento.
Esta herramienta permite establecer horarios mediante nodos de programación.
Por ejemplo:
Generar un reporte todos los días.
Consultar una API cada hora.
Ejecutar tareas de mantenimiento.
Revisar información periódicamente.
Enviar un resumen semanal.
Esto permite automatizar procesos que normalmente tendríamos que realizar manualmente.
Webhooks
Los Webhooks permiten que aplicaciones externas envíen información a n8n mediante solicitudes HTTP.
Cuando se recibe una solicitud en una URL configurada, podemos iniciar un workflow y procesar la información recibida.
Esta funcionalidad es especialmente útil para integrar aplicaciones que no cuentan con un nodo específico dentro dentro de la plataforma.
Procesamiento de información
La plataforma permite transformar, filtrar, combinar y organizar información antes de enviarla a otro servicio.
Por ejemplo, podemos consultar una API que devuelve información en formato JSON, seleccionar únicamente los campos que necesitamos y enviar los resultados a una hoja de cálculo.
También podemos utilizar JavaScript para realizar transformaciones más específicas.
Inteligencia artificial y agentes
Se incorporan funcionalidades relacionadas con inteligencia artificial y herramientas para construir flujos que utilizan modelos de lenguaje.
Podemos integrar proveedores como OpenAI, Google y otros servicios compatibles para:
Clasificar mensajes.
Resumir información.
Procesar documentos.
Crear asistentes conversacionales.
Analizar información.
Construir agentes de IA que interactúan con herramientas externas.
Estas funcionalidades permiten desarrollar automatizaciones más avanzadas, combinando reglas tradicionales con capacidades de inteligencia artificial.
4. Requisitos previos
Para instalar este servicio utilizando Docker necesitamos:
Un servidor Linux.
Docker Engine instalado.
Docker Compose.
Acceso administrativo al servidor.
Conexión a Internet.
Un directorio o volumen para almacenar los datos.
También es recomendable contar con un dominio o subdominio si queremos acceder a la interfaz desde fuera de nuestra red local.
En este tutorial utilizaremos Ubuntu Server y Docker Compose.
5. Instalación de n8n con Docker Compose
Una de las ventajas es que podemos instalarlo directamente como un contenedor Docker.
Esto permite mantener la aplicación aislada del sistema operativo y facilita su administración.
Paso 1. Crear el directorio de instalación
Nos conectamos al servidor mediante SSH y creamos el directorio donde almacenaremos la configuración:
mkdir -p ~/docker/n8n
cd ~/docker/n8n
También creamos un directorio para compartir archivos entre el servidor y el servicio:
Debemos sustituir n8n.midominio.com por nuestro propio dominio o subdominio.
Explicación de los parámetros
image: indica la imagen Docker que utilizaremos. En este caso seleccionamos la versión estable liberada.
container_name: establece el nombre del contenedor.
restart: permite que Docker reinicie automáticamente el servicio cuando sea necesario.
ports: publica el puerto 5678, utilizado por la plataforma.
N8N_HOST: establece el nombre de dominio utilizado para acceder a la aplicación.
N8N_PROTOCOL: indica que utilizaremos HTTPS mediante un proxy inverso o túnel.
N8N_EDITOR_BASE_URL: define la dirección pública de la interfaz de administración.
N8N_WEBHOOK_URL: establece la dirección pública que utilizará n8n para generar las URL de los Webhooks.
GENERIC_TIMEZONE y TZ: establecen la zona horaria utilizada por la aplicación y las tareas programadas.
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: solicita que el archivo de configuración tenga permisos restrictivos.
N8N_RESTRICT_FILE_ACCESS_TO: limita el acceso de los nodos de archivos al directorio especificado.
n8n_data: volumen persistente donde se almacena su base de datos, credenciales cifradas y configuración.
local-files: directorio compartido entre el servidor y el contenedor.
Paso 3. Iniciar n8n
Una vez guardado el archivo ejecutamos:
docker compose up -d
Comprobamos que el contenedor se encuentre funcionando:
docker ps --filter name=n8n
Para revisar los registros:
docker logs --tail 100 n8n
Si queremos visualizar los registros en tiempo real:
docker logs -f n8n
Paso 4. Acceder a la interfaz web
Si estamos utilizando únicamente la red local podemos acceder mediante:
http://IP-DE-TU-SERVIDOR:5678
Si configuramos un dominio con HTTPS mediante un proxy inverso o Cloudflare Tunnel, podremos acceder utilizando:
https://n8n.midominio.com
En el primer acceso tendremos que completar el asistente de configuración y crear nuestra cuenta de propietario.
Una vez finalizado, podremos comenzar a construir nuestros primeros workflows.
Importante: si publicamos esta plataforma mediante un proxy inverso o Cloudflare Tunnel, debemos configurar correctamente la dirección pública de los Webhooks y los encabezados de proxy. No debemos exponer directamente la interfaz administrativa a Internet sin protección.
6. Cómo funciona un workflow
Para entender cómo trabaja esta herramienta podemos construir un ejemplo sencillo.
Imaginemos que queremos recibir una notificación cuando se ejecute una automatización.
Un workflow puede estar compuesto por tres nodos:
Nodo 1: Schedule Trigger
Inicia la automatización en un horario determinado.
Nodo 2: HTTP Request
Realiza una solicitud a una API y obtiene información.
Nodo 3: Telegram
Envía un mensaje con los resultados obtenidos.
El flujo sería:
Schedule Trigger
|
v
HTTP Request
|
v
Telegram
Cada nodo recibe información del anterior, realiza su operación y entrega el resultado al siguiente.
Podemos agregar condiciones, filtros y más nodos dependiendo de lo que necesitemos.
Una de las ventajas de n8n es que podemos ejecutar manualmente los nodos durante el desarrollo para comprobar que cada operación funciona correctamente antes de activar el workflow completo.
7. Casos de uso de n8n en un Home Server
Aquí es donde esta herramienta realmente demuestra su utilidad.
Algunos ejemplos prácticos que podemos implementar en una infraestructura doméstica son los siguientes.
Caso 1. Notificaciones de Uptime Kuma mediante Telegram
Podemos integrar Uptime Kuma con esta herramienta para recibir notificaciones cuando un servicio deje de responder.
El funcionamiento sería:
Uptime Kuma detecta que un servicio está fuera de línea.
Envía una notificación mediante un Webhook a n8n.
n8n procesa el nombre del servicio y el estado.
Envía un mensaje a Telegram.
También podemos configurar una notificación diferente cuando el servicio vuelva a estar disponible.
Esto permite centralizar las notificaciones y personalizar los mensajes que recibimos.
Caso 2. Automatizar tareas de Home Assistant
n8n puede comunicarse con Home Assistant mediante su API y Webhooks.
Algunos ejemplos:
Enviar notificaciones cuando ocurre un evento.
Consultar el estado de dispositivos.
Ejecutar servicios de Home Assistant.
Procesar información de sensores.
Crear reportes de consumo energético.
De esta manera podemos utilizar n8n para coordinar procesos que involucran diferentes aplicaciones.
Caso 3. Automatizar respaldos y reportes
Podemos crear workflows que ejecuten tareas programadas relacionadas con el mantenimiento de nuestro servidor.
Por ejemplo:
Un Schedule Trigger inicia el flujo.
Se consulta información de los servicios.
Se procesa la información.
Se genera un reporte.
Se envía el resultado mediante Telegram o correo electrónico.
También podemos integrar servicios de almacenamiento para gestionar archivos y respaldos.
Para ejecutar comandos directamente en el servidor debemos diseñar un mecanismo de acceso seguro y restringido, evitando otorgar privilegios administrativos innecesarios a n8n.
Caso 4. Automatización de WordPress
Si administramos un sitio web con WordPress, esta plataforma puede ayudarnos a automatizar diferentes tareas editoriales.
Algunos ejemplos:
Recibir propuestas de artículos mediante formularios.
Generar borradores a partir de información almacenada.
Consultar información de APIs.
Preparar resúmenes de contenido.
Enviar notificaciones cuando se publica una entrada.
Distribuir enlaces de nuevos artículos en otros servicios.
También podemos utilizar la API REST de WordPress para interactuar con el sitio.
Esto puede ser especialmente útil para automatizar tareas repetitivas sin perder el control editorial.
Caso 5. Integración con servicios externos mediante APIs
No todas las aplicaciones cuentan con una integración directa dentro de n8n.
Sin embargo, podemos utilizar el nodo HTTP Request para comunicarnos con servicios que ofrecen una API.
Por ejemplo:
Consultar información meteorológica.
Obtener datos de servicios externos.
Enviar información a plataformas de almacenamiento.
Consultar bases de datos.
Integrar aplicaciones que no tienen un nodo nativo.
Esto se convierte en una herramienta muy flexible para conectar diferentes plataformas.
Caso 6. Automatizaciones con inteligencia artificial
También podemos utilizar esta herramienta para crear flujos de trabajo que incorporen modelos de inteligencia artificial.
Por ejemplo:
Recibir un mensaje mediante Telegram.
Enviar el contenido a un modelo de IA.
Analizar la respuesta.
Procesar el resultado.
Enviar una contestación al usuario.
Podemos ampliar este tipo de automatizaciones para procesar documentos, resumir información, clasificar mensajes o consultar bases de conocimiento.
8. Administración y mantenimiento
Al ejecutarse dentro de Docker, podemos administrar utilizando los comandos habituales de Docker Compose.
Consultar el estado del contenedor:
docker ps --filter name=n8n
Consultar los registros:
docker logs --tail 100 n8n
Reiniciar el servicio:
cd ~/docker/n8n
docker compose restart
Detener el servicio:
docker compose stop
Iniciar nuevamente el servicio:
docker compose up -d
Actualizar la imagen:
docker compose pull
docker compose up -d
Antes de actualizar una instalación que contiene workflows y credenciales importantes, debemos realizar un respaldo y revisar las notas de la versión. No es recomendable depender de actualizaciones automáticas sin validar la compatibilidad.
9. Respaldos y seguridad
Esta plataforma almacena información importante en su directorio de datos, incluyendo:
Base de datos SQLite, cuando se utiliza la configuración predeterminada.
Workflows.
Credenciales cifradas.
Clave de cifrado.
Configuración de la instancia.
Información relacionada con las ejecuciones.
Por eso debemos prestar especial atención a los respaldos.
Conservar el volumen persistente.
No debemos eliminar el volumen n8n_data cuando recreamos o actualizamos el contenedor.
Respaldar la clave de cifrado.
La clave de cifrado es indispensable para recuperar las credenciales almacenadas. Debemos protegerla y conservarla junto con el respaldo de la base de datos.
Utilizar HTTPS.
Si accedemos a n8n desde Internet, debemos utilizar una conexión HTTPS mediante un proxy inverso o un túnel seguro.
Proteger las credenciales.
Las conexiones con servicios externos pueden contener tokens, contraseñas y claves API. No debemos compartirlas dentro de los workflows ni publicarlas en repositorios abiertos.
Restringir el acceso a archivos.
Debemos limitar los directorios que pueden consultar los nodos de lectura y escritura.
Realizar auditorías de seguridad.
Este servicio incorpora una herramienta de auditoría que permite identificar configuraciones y elementos que pueden representar riesgos de seguridad.
Podemos ejecutarla mediante:
docker exec -it n8n n8n audit
Mantener todo actualizado.
Debemos revisar las nuevas versiones, las notas de publicación y los posibles cambios incompatibles antes de actualizar nuestra instalación.
10. Conclusión
n8n es una herramienta muy interesante para quienes administramos un Home Server y queremos ir más allá de instalar aplicaciones independientes.
Su capacidad para conectar diferentes servicios, procesar información y ejecutar tareas automáticamente permite construir una infraestructura mucho más integrada.
Podemos utilizarlo para recibir notificaciones, administrar información, interactuar con APIs, automatizar tareas de mantenimiento e incluso incorporar inteligencia artificial a nuestros procesos.
Además, al ejecutarlo mediante Docker, podemos integrarlo fácilmente en nuestra infraestructura existente.
Si tenemos varios servicios funcionando en nuestro servidor, esta herramienta puede convertirse en el punto central de automatización que permite que todos trabajen en conjunto.
La verdadera ventaja no está solamente en automatizar una tarea, sino en conectar diferentes herramientas para construir procesos completos sin tener que hacerlo todo manualmente.
Cuando administramos un Home Server, no basta con instalar aplicaciones y comprobar que funcionan correctamente. También necesitamos saber si nuestros servicios continúan disponibles, si responden correctamente y cuándo ocurre algún problema.
Imaginemos que tenemos varios servicios funcionando en nuestro servidor: Jellyfin, Nextcloud, WordPress, Home Assistant o incluso una página web alojada en Internet.
¿Qué sucede si alguno deja de funcionar mientras no estamos en casa? ¿Cómo podemos saber si nuestro sitio web está disponible o si un contenedor Docker se ha detenido inesperadamente?
Para solucionar este problema existe Uptime Kuma, una herramienta de monitorización de código abierto que nos permite supervisar servicios, servidores, páginas web y diferentes dispositivos desde un único panel de control.
En este artículo veremos qué es Uptime Kuma, cuáles son sus funcionalidades, cómo instalarlo utilizando Docker Compose y cómo configurarlo para monitorear los servicios de nuestro Home Server.
Table of Contents
1. ¿Qué es Uptime Kuma?
Uptime Kuma es una herramienta de monitorización autohospedada (self-hosted), diseñada para comprobar la disponibilidad de servicios y dispositivos de red.
Su principal característica es ofrecer un panel de control desde el cual podemos visualizar el estado de nuestros servicios, consultar tiempos de respuesta, identificar interrupciones y recibir notificaciones cuando algo deja de funcionar.
A diferencia de algunas plataformas comerciales de monitorización, Uptime Kuma puede instalarse directamente en nuestro propio servidor, por lo que mantenemos el control sobre su configuración y los datos de monitorización.
Su interfaz gráfica permite administrar los monitores sin necesidad de escribir comandos constantemente.
2. ¿Para qué sirve Uptime Kuma?
Uptime Kuma permite supervisar prácticamente cualquier servicio que podamos comprobar mediante una conexión de red o un mecanismo compatible.
Algunos ejemplos de uso son:
Comprobar si una página web está disponible.
Verificar que un servidor responde a solicitudes HTTP o HTTPS.
Supervisar puertos TCP de aplicaciones y servidores.
Comprobar la conectividad de dispositivos mediante Ping.
Monitorear contenedores Docker.
Verificar registros DNS.
Supervisar certificados SSL y sus fechas de expiración.
Recibir notificaciones cuando un servicio deja de responder.
Publicar páginas de estado para mostrar la disponibilidad de nuestros servicios.
Por ejemplo, podemos configurar un monitor para comprobar que nuestro sitio web responde correctamente cada cierto intervalo.
Si el sitio deja de responder, Uptime Kuma registra el incidente y puede enviarnos una notificación.
De esta manera podemos identificar problemas sin tener que comprobar manualmente cada aplicación.
3. Principales funcionalidades
Monitorización HTTP y HTTPS
Permite comprobar la disponibilidad de páginas web y aplicaciones accesibles mediante HTTP o HTTPS.
Podemos configurar la URL que queremos supervisar y establecer los códigos de respuesta HTTP que consideramos válidos.
También permite comprobar certificados SSL para identificar cuándo se aproxima su fecha de expiración.
Monitorización TCP
Permite comprobar si un puerto específico de un servidor está aceptando conexiones.
Por ejemplo, podemos supervisar:
Puerto 22: SSH.
Puerto 80: HTTP.
Puerto 443: HTTPS.
Puerto 3001: Uptime Kuma.
Esta funcionalidad es útil para comprobar que determinados servicios continúan escuchando en sus puertos correspondientes.
Monitorización mediante Ping
Permite comprobar si un dispositivo responde a solicitudes ICMP.
Podemos utilizarlo para supervisar:
Routers.
Switches.
Servidores.
Computadoras.
Impresoras de red.
Otros dispositivos conectados a nuestra infraestructura.
Es importante recordar que un dispositivo puede bloquear ICMP y seguir funcionando correctamente. Por eso, un resultado negativo de Ping no siempre significa que el dispositivo esté completamente fuera de servicio.
Monitorización de contenedores Docker
Una de las funcionalidades más interesantes para quienes utilizamos Docker es la posibilidad de supervisar directamente nuestros contenedores.
Uptime Kuma puede conectarse al motor Docker y comprobar el estado de los contenedores seleccionados.
Esto permite visualizar si un contenedor está ejecutándose o si ha dejado de estar disponible.
Para utilizar esta funcionalidad necesitamos proporcionar acceso al socket de Docker, algo que veremos durante la instalación.
Sistema de notificaciones
Uptime Kuma permite configurar diferentes mecanismos para recibir alertas cuando ocurre algún incidente.
Entre las integraciones disponibles encontramos:
Telegram.
Discord.
Slack.
Gotify.
Correo electrónico mediante SMTP.
Pushover.
Otros servicios compatibles.
Esto permite recibir notificaciones sin necesidad de mantener abierto el panel de monitorización.
Páginas públicas de estado
Otra funcionalidad interesante es la posibilidad de crear páginas de estado.
Estas páginas permiten mostrar la disponibilidad de determinados servicios sin necesidad de proporcionar acceso al panel administrativo.
Podemos utilizarlas para informar a otras personas si nuestros servicios están funcionando correctamente o si existe alguna interrupción.
4. Requisitos previos
Para instalar Uptime Kuma utilizando Docker necesitamos:
Un servidor Linux con Docker Engine.
Docker Compose.
Acceso administrativo al servidor.
Conexión a Internet para descargar la imagen.
Espacio de almacenamiento para conservar la configuración y el historial de monitorización.
En este tutorial utilizaremos Ubuntu Server y Docker Compose.
5. Instalación de Uptime Kuma con Docker Compose
La instalación mediante Docker Compose permite mantener la configuración organizada y facilita las tareas de mantenimiento.
Paso 1. Crear el directorio de instalación
Nos conectamos al servidor mediante SSH y creamos el directorio donde almacenaremos los archivos de configuración:
mkdir -p ~/docker/uptime-kuma
cd ~/docker/uptime-kuma
Abrimos nuestro navegador y utilizamos la siguiente dirección:
http://IP-DE-TU-SERVIDOR:3001
Por ejemplo:
http://192.168.8.10:3001
En el primer inicio tendremos que completar el asistente de configuración y crear nuestra cuenta administrativa.
Una vez finalizado este proceso, tendremos acceso al panel principal de Uptime Kuma.
Nota: si queremos publicar Uptime Kuma mediante un proxy inverso o Cloudflare Tunnel, debemos configurar correctamente el acceso y proteger el panel administrativo. No es recomendable exponerlo directamente a Internet.
6. Cómo configurar nuestro primer monitor
Una vez dentro de Uptime Kuma, podemos comenzar a supervisar nuestros servicios.
Para crear un monitor:
Seleccionamos la opción para agregar un nuevo monitor.
Elegimos el tipo de monitorización.
Asignamos un nombre descriptivo.
Introducimos la dirección IP, dominio o URL correspondiente.
Configuramos el intervalo de comprobación.
Guardamos los cambios.
Por ejemplo, podemos crear un monitor HTTP(s) para comprobar nuestro sitio web:
Esto nos permite centralizar la supervisión de nuestros servicios Docker desde una sola interfaz.
Consideración de seguridad: montar el socket Docker proporciona un acceso muy elevado al servidor. Aunque se monte como un volumen de solo lectura, eso no convierte automáticamente la API de Docker en una API de solo lectura. Debemos proteger el acceso administrativo a Uptime Kuma y evitar exponerlo públicamente sin controles adicionales.
8. Configurar notificaciones
Una de las ventajas de Uptime Kuma es que no necesitamos estar revisando constantemente el panel para detectar problemas.
Podemos configurar notificaciones para recibir alertas cuando un monitor cambia de estado.
Para hacerlo:
Entramos en Settings.
Seleccionamos Notifications.
Agregamos un nuevo mecanismo de notificación.
Introducimos los parámetros necesarios.
Ejecutamos una prueba de conexión.
Guardamos la configuración.
Por ejemplo, podemos integrar Telegram para recibir mensajes cuando un servicio deja de responder y cuando vuelve a estar disponible.
También podemos asociar una misma configuración de notificaciones a varios monitores.
Esto resulta especialmente útil cuando tenemos numerosos servicios funcionando en nuestro Home Server.
9. Consultar registros y diagnosticar problemas
Como Uptime Kuma funciona dentro de Docker, podemos consultar sus registros directamente desde la terminal.
Para visualizar los últimos registros:
docker logs --tail 100 uptime-kuma
Para observarlos en tiempo real:
docker logs -f uptime-kuma
También podemos comprobar el estado del contenedor:
Y para comprobar que el puerto responde localmente:
curl -I http://127.0.0.1:3001
Estos comandos son útiles para identificar problemas de inicio, conectividad o funcionamiento del contenedor.
10. Respaldos y buenas prácticas
Uptime Kuma almacena su información en el directorio /app/data, que en nuestra instalación está vinculado a un directorio persistente del servidor.
Aquí se conserva información importante como:
Configuración de la aplicación.
Monitores creados.
Historial de monitorización.
Datos de la base de datos.
Configuración de notificaciones.
Por este motivo, debemos realizar respaldos periódicos del directorio de datos.
Algunas recomendaciones:
Realizar respaldos consistentes.
Antes de copiar los archivos de datos, es recomendable detener temporalmente el contenedor o utilizar un procedimiento de respaldo consistente con la base de datos. No debemos asumir que copiar únicamente el archivo SQLite mientras la aplicación está escribiendo garantiza una copia válida.
Proteger la cuenta administrativa.
Utilizar una contraseña segura y habilitar la autenticación de dos factores cuando esté disponible.
No exponer el socket Docker.
El socket proporciona un acceso privilegiado al motor Docker. Debemos limitar quién puede acceder a Uptime Kuma.
Configurar intervalos razonables.
No todos los servicios necesitan comprobarse con la misma frecuencia. Podemos adaptar los intervalos según la importancia de cada aplicación.
Utilizar notificaciones.
Un sistema de monitorización es mucho más útil cuando recibimos alertas oportunamente.
Supervisar desde una ubicación independiente.
Si Uptime Kuma y los servicios monitorizados se encuentran en el mismo servidor, una caída completa del servidor también puede dejar sin funcionamiento al sistema de monitorización. Para una supervisión más completa, podemos instalar una segunda instancia en otro equipo o servidor.
11. Conclusión
Uptime Kuma es una excelente alternativa para quienes queremos tener mayor visibilidad sobre los servicios que administramos en nuestro Home Server.
Su interfaz sencilla, las diferentes opciones de monitorización, la integración con Docker y el sistema de notificaciones permiten identificar problemas de disponibilidad sin depender de comprobaciones manuales.
Además, al ser una herramienta autohospedada, podemos ejecutarla en nuestra propia infraestructura y mantener el control sobre los datos.
Si administramos varios servicios Docker, contar con una herramienta como Uptime Kuma facilita considerablemente las tareas de supervisión y mantenimiento.
Un Home Server no solamente necesita funcionar; también necesitamos saber cuándo deja de hacerlo.
Cuando administramos un Home Server con Docker, una de las tareas que debemos realizar periódicamente es mantener actualizados nuestros contenedores.
Servicios como Jellyfin, Nextcloud, Home Assistant, Uptime Kuma o WordPress reciben actualizaciones que incorporan nuevas funcionalidades, correcciones de errores y mejoras de seguridad.
Sin embargo, actualizar cada contenedor manualmente puede convertirse en una tarea repetitiva, especialmente cuando tenemos varios servicios funcionando en nuestro servidor.
Aquí es donde entra Watchtower, una herramienta que permite automatizar la detección de nuevas versiones de imágenes Docker y actualizar los contenedores cuando existen versiones disponibles.
En este artículo veremos qué es esta herramienta, cómo funciona, cómo instalarlo utilizando Docker Compose y cómo configurarlo para realizar actualizaciones programadas.
Table of Contents
1. ¿Qué es Watchtower?
Es una herramienta de código abierto diseñada para supervisar y actualizar automáticamente contenedores Docker.
Su funcionamiento consiste en comprobar periódicamente si existen nuevas versiones de las imágenes utilizadas por nuestros contenedores.
Cuando detecta una actualización, puede realizar automáticamente las siguientes operaciones:
Detectar que existe una nueva versión de la imagen Docker.
Descargar la nueva imagen desde el repositorio correspondiente.
Detener el contenedor que utiliza la versión anterior.
Crear nuevamente el contenedor utilizando la imagen actualizada.
Conservar la configuración original del contenedor, incluyendo variables de entorno, puertos, redes y volúmenes configurados.
De esta manera, no necesitamos conectarnos constantemente al servidor para comprobar y actualizar manualmente cada servicio.
Importante: Esta herramienta no actualiza el sistema operativo ni los paquetes de Ubuntu. Su función se limita a administrar las actualizaciones de las imágenes de los contenedores Docker.
2. ¿Para qué sirve Watchtower?
Su principal objetivo es simplificar el mantenimiento de un entorno Docker.
Imaginemos que tenemos cinco servicios instalados en nuestro Home Server:
Jellyfin para administrar nuestra biblioteca multimedia.
Uptime Kuma para supervisar la disponibilidad de los servicios.
Home Assistant para automatización del hogar.
Calibre-Web para administrar libros electrónicos.
WordPress para alojar nuestro sitio web.
Sin una herramienta de automatización, tendríamos que comprobar periódicamente si existen nuevas imágenes y actualizar los contenedores manualmente.
Con esta herramienta podemos automatizar este proceso y establecer un horario para realizar las comprobaciones.
Esto resulta especialmente útil cuando administramos varios servicios y queremos reducir las tareas de mantenimiento.
3. Principales funcionalidades
Actualizaciones automáticas
Comprueba si existen nuevas versiones de las imágenes Docker y puede actualizar los contenedores automáticamente.
Actualizaciones programadas
Permite definir intervalos de comprobación o utilizar expresiones cron para establecer días y horarios específicos.
Exclusión de contenedores
Permite evitar que determinados servicios sean actualizados automáticamente mediante etiquetas de Docker.
Limpieza de imágenes antiguas
Con la opción Cleanup puede eliminar las imágenes anteriores después de completar una actualización, ayudando a evitar la acumulación de imágenes que ya no se utilizan.
Notificaciones
Permite configurar notificaciones para conocer cuándo se detectan o realizan actualizaciones, utilizando los mecanismos de notificación compatibles.
4. Requisitos previos
Antes de instalar este servicio necesitamos:
Un servidor Linux, Windows o cualquier sistema compatible con Docker.
Docker Engine instalado y funcionando.
Docker Compose.
Acceso administrativo al servidor.
Conexión a Internet para descargar las imágenes.
También es recomendable tener configurado un sistema de respaldos para los servicios y sus bases de datos.
5. Instalación de Watchtower con Docker Compose
Esta herramienta funciona como un contenedor Docker independiente y necesita comunicarse con el motor Docker del servidor.
Para ello utiliza el socket:
/var/run/docker.sock
Este socket permite que Watchtower consulte y administre los contenedores del servidor.
Nota sobre el proyecto: el repositorio original containrrr/watchtower fue archivado el 17 de diciembre de 2025. Para una instalación nueva, este tutorial utiliza la continuación comunitaria nickfedor/watchtower. Es importante comprobar el estado y la procedencia de las imágenes antes de instalarlas.
Paso 1. Crear el directorio
Nos conectamos al servidor mediante SSH y creamos el directorio donde almacenaremos la configuración:
mkdir -p ~/docker/watchtower
cd ~/docker/watchtower
Con esta configuración, Watchtower omitirá ese contenedor durante sus actualizaciones automáticas.
Esta funcionalidad es especialmente útil para servicios importantes, bases de datos y aplicaciones que requieren una validación previa antes de actualizarse.
8. Cómo comprobar los registros de Watchtower
Podemos consultar los registros del contenedor para comprobar si está funcionando correctamente:
docker logs watchtower
Para visualizar los registros en tiempo real:
docker logs -f watchtower
También podemos comprobar cuándo se realizó la última ejecución y si se encontraron imágenes nuevas.
Si queremos salir de la visualización en tiempo real, presionamos Ctrl + C. Esto no detiene el contenedor.
9. Buenas prácticas y recomendaciones
Aunque Watchtower facilita el mantenimiento de Docker, es importante considerar algunos aspectos antes de habilitar actualizaciones automáticas.
Realizar respaldos periódicos.
Antes de actualizar servicios importantes, debemos contar con respaldos de sus configuraciones y bases de datos.
No actualizar todo sin supervisión.
Las nuevas versiones pueden introducir cambios incompatibles. Es recomendable excluir los servicios críticos o utilizar un proceso de actualización manual para ellos.
Evitar depender exclusivamente de la etiqueta latest.
Es conveniente revisar qué versiones y etiquetas utilizan nuestros contenedores, especialmente cuando necesitamos mantener una versión específica.
Proteger el acceso al socket de Docker.
El acceso a /var/run/docker.sock proporciona un nivel de control muy elevado sobre Docker y, en la práctica, puede equivaler a privilegios administrativos sobre el servidor. No debemos exponerlo a redes o usuarios no confiables.
Revisar los registros después de las actualizaciones.
Una actualización exitosa no garantiza que la aplicación funcione correctamente. Debemos comprobar que los servicios continúen operativos.
No confundir actualización con respaldo.
Watchtower no crea copias de seguridad ni garantiza que podamos regresar automáticamente a una versión anterior.
10. Conclusión
Watchtower es una herramienta interesante para quienes administramos un Home Server con múltiples servicios Docker.
Su capacidad para detectar nuevas imágenes, programar actualizaciones y excluir determinados contenedores permite simplificar considerablemente las tareas de mantenimiento.
Sin embargo, la automatización debe utilizarse con precaución. No todos los servicios deberían actualizarse sin supervisión, especialmente aquellos que almacenan información importante.
La mejor estrategia es combinar Watchtower con respaldos periódicos, supervisión de los contenedores y actualizaciones controladas para los servicios críticos.
Así podemos mantener nuestro Home Server actualizado sin perder el control sobre los servicios que tenemos funcionando.
Tener un sitio web propio no necesariamente requiere contratar un servicio de hosting tradicional. Si disponemos de un servidor en casa, una conexión a Internet y algunos conocimientos de Linux, podemos alojar WordPress utilizando Docker y publicar el sitio mediante Cloudflare Tunnel.
En este artículo documentamos una implementación real sobre Ubuntu Server, utilizando contenedores Docker para ejecutar WordPress y MariaDB, y Cloudflare Tunnel para permitir el acceso público mediante HTTPS sin tener que exponer directamente los puertos del servidor a Internet.
El objetivo no es solamente mostrar cómo poner el sitio en funcionamiento, sino explicar la arquitectura, las decisiones técnicas, las medidas de seguridad y las comprobaciones necesarias para mantener el servicio.
La implementación descrita corresponde a un entorno de homelab. No debe interpretarse como una arquitectura de alta disponibilidad ni como sustituto de una estrategia completa de recuperación ante desastres.
Table of Contents
1. Arquitectura de la solución
La implementación utiliza tres servicios principales:
WordPress: aplicación web ejecutada sobre Apache y PHP.
MariaDB: motor de base de datos que almacena el contenido y la configuración de WP.
Cloudflare Tunnel: establece la conexión entre el servidor y la infraestructura de Cloudflare para publicar el sitio.
Los servicios se ejecutan en contenedores Docker y comparten una red interna.
Una característica importante de esta arquitectura es que el sitio no necesita publicar su puerto directamente en Internet. El contenedor de Cloudflare Tunnel se comunica con WordPress a través de la red interna de Docker.
Componentes utilizados
Componente
Implementación
Sistema operativo
Ubuntu Server 26.04 LTS
Contenedores
Docker Engine
Orquestación
Docker Compose
CMS
WordPress
Servidor web
Apache
PHP
8.3
Base de datos
MariaDB 11.4
Publicación externa
Cloudflare Tunnel
Red Docker
wordpress_net
2. Preparación del entorno
Antes de desplegar el sitio es necesario contar con un servidor Ubuntu actualizado y Docker Engine con Docker Compose.
Podemos verificar las versiones instaladas con:
docker --version
docker compose version
También conviene comprobar que Docker esté funcionando:
sudo systemctl status docker --no-pager
Para esta implementación se utiliza el usuario habitual del servidor, con permisos para administrar Docker.
Es recomendable trabajar con un directorio dedicado para mantener organizados los archivos de configuración:
El archivo .env contiene variables de entorno y credenciales. No debe publicarse, compartirse ni incluirse en repositorios públicos.
3. Organización de los servicios Docker
La implementación utiliza tres contenedores:
Contenedor
Imagen
wordpress-web
wordpress.3-apache
wordpress-db
mariadb:11.4
wordpress-cloudflared
cloudflare/cloudflared
La base de datos no publica ningún puerto en el servidor. El sitio accede a MariaDB mediante el nombre del servicio dentro de la red Docker.
WordPress, por su parte, publica su puerto HTTP únicamente en la interfaz local:
ports:
- "127.0.0.1:8088:80"
Esto significa que el servicio puede consultarse desde el propio servidor mediante 127.0.0.1:8088, pero no queda directamente expuesto en la interfaz de red pública o LAN del servidor mediante ese mapeo.
El contenedor de Cloudflare Tunnel utiliza la red Docker para alcanzar WordPress mediante:
http://wordpress-web:80
Variables y credenciales
Las credenciales de MariaDB y del sitio se administran mediante variables de entorno almacenadas en .env.
Un ejemplo de las variables que deben gestionarse es:
Los valores son ilustrativos. Deben utilizarse contraseñas largas, únicas y aleatorias.
El token de Cloudflare Tunnel también debe mantenerse fuera del archivo público de configuración y nunca compartirse en capturas, registros o repositorios.
4. Persistencia de datos: un aspecto fundamental
Los contenedores son reemplazables. Los datos importantes deben mantenerse fuera de la capa temporal del contenedor.
En esta implementación se utilizan dos volúmenes Docker:
Volumen
Destino dentro del contenedor
wordpress_wordpress_files
/var/www/html
wordpress_wordpress_db
/var/lib/mysql
El primero conserva los archivos del sitio, incluyendo temas, plugins, archivos multimedia y configuración.
En esta arquitectura también se utiliza un archivo de configuración PHP montado como solo lectura.
Es importante recordar que los volúmenes permiten conservar los datos al recrear contenedores, pero no sustituyen una copia de seguridad.
Precaución: no utilizar docker compose down -v sin comprender sus consecuencias. La opción -v puede eliminar los volúmenes asociados y, con ellos, los datos persistentes.
5. Publicación mediante Cloudflare Tunnel
Uno de los objetivos de esta implementación fue evitar la apertura directa de puertos entrantes en el router.
Cloudflare Tunnel permite que el servidor establezca conexiones salientes hacia la infraestructura de Cloudflare. De esta manera, el servicio puede publicarse sin configurar un reenvío tradicional de los puertos 80 y 443 hacia el servidor doméstico.
En la configuración utilizada, el hostname público es:
dotbugs.com
El destino interno del túnel es:
http://wordpress-web:80
El tráfico sigue este recorrido:
El visitante accede a https://dotbugs.com.
Cloudflare recibe la solicitud.
Cloudflare Tunnel transporta la solicitud hasta el servidor.
El contenedor de Cloudflare Tunnel se comunica con el sitio por la red Docker.
El sitio procesa la solicitud y devuelve la respuesta.
¿Por qué se utiliza HTTP entre los contenedores?
En esta implementación, la comunicación entre Cloudflare Tunnel y el sitio utiliza HTTP dentro de la red privada de Docker.
La conexión pública del visitante utiliza HTTPS. Esto no significa que debamos configurar HTTP público sin protección: la terminación HTTPS y la comunicación interna son tramos diferentes de la arquitectura.
Si se utiliza este modelo, es importante proteger el acceso al servidor y controlar quién puede acceder a la red Docker.
6. Configuración adicional de seguridad PHP
Durante la revisión de la instalación se identificó una medida preventiva relacionada con el mecanismo de seguimiento del progreso de cargas de archivos de PHP.
Para aplicarla se utiliza un archivo personalizado:
; Mitigación preventiva temporal del aviso de seguridad de PHP
session.upload_progress.enabled = 0
El archivo se encuentra en:
/home/dotbugs/docker/wordpress/php-security.ini
Y se monta en el contenedor como:
/usr/local/etc/php/conf.d/zz-security.ini
El montaje se realiza en modo de solo lectura.
Comprobar que PHP aplica la configuración
No basta con escribir una directiva en un archivo. Es importante verificar el valor efectivo dentro del contenedor:
Es importante señalar que WP y Cloudflare Tunnel no tienen un healthcheck de Docker configurado en esta implementación. Por lo tanto, que aparezcan como Up no garantiza por sí solo que la aplicación web sea accesible.
Comprobar WordPress localmente
Como el puerto está publicado únicamente en localhost, podemos realizar la prueba desde el propio servidor:
Importante: este mecanismo es un diagnóstico programado, no un servicio de monitorización continua. Tampoco actualiza automáticamente WordPress ni las imágenes Docker.
9. Copias de seguridad: qué tenemos y qué falta
Una instalación con volúmenes persistentes sigue necesitando copias de seguridad independientes.
En nuestro servidor se identificaron respaldos completos que contienen:
Una exportación SQL de la base de datos.
Un archivo comprimido con los archivos de WordPress.
El directorio utilizado es:
/home/dotbugs/backups/wordpress/
Los nombres de los archivos son:
wordpress-database.sql
wordpress-files.tar.gz
El diagnóstico semanal verifica que ambos archivos existan, que no estén vacíos, que el archivo comprimido pueda validarse y que la antigüedad de la copia no supere el límite configurado de ocho días.
Sin embargo, hay una distinción importante: la implementación documentada cuenta con copias de seguridad existentes y comprobaciones automáticas, pero no tiene confirmada una tarea periódica que genere nuevas copias automáticamente.
Tampoco se ha documentado una restauración completa probada.
Por ello, antes de considerar el entorno protegido ante cualquier incidente, todavía es necesario implementar y probar:
Generación periódica de copias SQL y de archivos.
Una política de retención y rotación.
Una segunda ubicación de almacenamiento independiente del servidor.
Un procedimiento de restauración probado.
Un respaldo que nunca se ha restaurado sigue siendo una copia cuya capacidad de recuperación no hemos demostrado.
10. Consideraciones de seguridad y mantenimiento
Al alojar un sitio web desde un servidor doméstico, debemos tener presentes algunos aspectos:
Mantener Ubuntu, Docker, WP, PHP y MariaDB actualizados.
Revisar los plugins y temas instalados y retirar los que no se utilicen.
Utilizar contraseñas únicas y robustas.
Proteger el archivo .env y el token de Cloudflare Tunnel.
Evitar publicar directamente el puerto de MariaDB.
Limitar la exposición de los servicios que no necesitan acceso externo.
Realizar copias de seguridad independientes.
Probar periódicamente los procedimientos de recuperación.
Revisar los informes de diagnóstico y las advertencias de actualización.
Evitar actualizar imágenes de producción sin revisar los cambios y contar con un respaldo reciente.
También conviene recordar que utilizar etiquetas como latest facilita el despliegue, pero no fija una versión inmutable. Antes de actualizar es recomendable revisar la imagen disponible, realizar una copia de seguridad y validar el funcionamiento posterior.
11. Conclusiones
Alojar WP en un homeserver utilizando Docker y Cloudflare Tunnel es una alternativa viable para quienes desean administrar su propia infraestructura y aprender sobre contenedores, redes y servicios web.
En esta implementación conseguimos:
Ejecutar WordPress y MariaDB en contenedores independientes.
Mantener los datos mediante volúmenes Docker.
Evitar publicar directamente el puerto de WordPress en la interfaz de red del servidor.
Publicar el sitio mediante Cloudflare Tunnel.
Aplicar una configuración PHP personalizada.
Comprobar la disponibilidad local y pública.
Automatizar diagnósticos semanales y generar informes.
La experiencia también demuestra que desplegar un servicio es solamente una parte del trabajo. Mantenerlo actualizado, verificar su disponibilidad y contar con una estrategia de respaldos y recuperación son responsabilidades igual de importantes.
La ventaja de un homelab es que permite construir, experimentar y documentar una infraestructura real. La clave está en conocer sus límites y no confundir que un servicio esté funcionando con que esté completamente protegido.
Nota técnica: este artículo describe una implementación real en Ubuntu Server 26.04 LTS, Docker y Cloudflare Tunnel, revisada el 3 de noviembre de 2026. Las rutas, nombres de contenedores y resultados corresponden a ese entorno y pueden necesitar ajustes en otras instalaciones.
