Cómo crear un servidor casero utilizando Docker Desktop

Montar un servidor casero con Docker Desktop es una de las formas más cómodas de centralizar servicios como web, bases de datos, VPN, nube personal o incluso servidores de juegos sin volverte loco con instalaciones tradicionales. Gracias a los contenedores puedes tenerlo todo ordenado, fácil de actualizar y con un grado de aislamiento que reduce bastante los sustos cuando algo se rompe.

Si tienes un PC antiguo, un miniordenador o un NAS tipo Synology, puedes convertirlo en el centro neurálgico de tu red doméstica: servidor de archivos, multimedia, nube privada, DNS filtrante, gestor de contraseñas y laboratorio para tus proyectos. Y lo mejor es que con Docker y, si quieres, Portainer, puedes administrarlo de forma bastante intuitiva aunque no seas un gurú de Linux.

Elegir máquina y sistema operativo para tu servidor casero

La base de todo servidor casero es la máquina física sobre la que vas a montar Docker. Puedes reutilizar un PC que tengas por casa, apostar por un NAS tipo Synology o montar un servidor cloud remoto, según lo que te interese más en ruido, consumo, precio y potencia.

Un PC antiguo suele ser la opción más barata: aprovechas una torre que ya no usas, compras uno o dos discos duros grandes (por ejemplo, 2 TB, 4 TB o 12 TB) y los montas en RAID si quieres tolerancia a fallos. Adaptadores de bahía y discos tipo Western Digital Red o similares te dan un buen equilibrio entre capacidad y fiabilidad para uso 24/7.

Los NAS como Synology aportan simplicidad y silencio. Por ejemplo, un modelo tipo DS420+ viene con su propia distribución basada en Linux, interfaz web muy pulida y aplicaciones oficiales (incluido soporte para Docker en muchos modelos). El hardware suele ser modesto (2 GB de RAM y CPU de dos núcleos pueden ser habituales), pero para servicios domésticos va más que sobrado.

A nivel de sistema operativo, casi cualquier cosa vale: puedes usar Windows, macOS o Linux. Un servidor casero básico puede funcionar perfectamente con el Windows que traía el PC, pero si quieres exprimir recursos y tener un sistema pensado para servidores, Debian, Ubuntu Server, TrueNAS o la propia distro de un NAS suelen ser mejores candidatos.

En cuanto a requisitos de hardware, Docker no es especialmente exigente para un uso doméstico típico (Nextcloud, bases de datos pequeñas, Plex, Pi-hole, etc.). Con 2 GB de RAM y una CPU de dos núcleos puedes mover bastantes contenedores siempre que no hagas cosas muy pesadas como transcodificación masiva de vídeo o servidores de juegos para cientos de personas.

Instalar Docker (y Docker Desktop) en tu servidor

El primer paso real es tener el sistema operativo actualizado y con un usuario con privilegios de administrador (sudo en Linux). En un entorno tipo Debian 10 Server, tras la instalación básica del sistema conviene actualizar paquetes, ajustar la red y dejar creada una cuenta no root con permisos de administración.

En Debian y derivadas, Docker se instala desde el repositorio oficial. El proceso típico pasa por instalar paquetes de soporte (como ca-certificates, curl, gnupg), descargar y añadir la clave GPG del repositorio de Docker, registrar el repositorio correspondiente a tu distribución y, finalmente, instalar los paquetes docker-ce, docker-ce-cli y containerd.io, entre otros.

Una vez instalados los paquetes, toca validar que Docker funciona. Lo habitual es lanzar el contenedor de prueba «hello-world», que descarga una imagen mínima desde Docker Hub y muestra un mensaje por consola si todo está correctamente configurado. De paso puedes consultar la versión con el comando adecuado para asegurarte de que tienes una versión reciente.

Para facilitar el uso diario de Docker sin estar tirando de sudo todo el rato, es buena idea añadir tu usuario al grupo docker. Así podrás ejecutar comandos docker como usuario normal. Tras hacer este cambio, conviene cerrar sesión o reiniciar para que se apliquen los permisos y comprobar que el servicio docker arranca correctamente al inicio del sistema.

Si trabajas desde un equipo de escritorio con Windows o macOS, Docker Desktop es la forma más sencilla de disponer de Docker localmente con interfaz gráfica básica, integración con Kubernetes opcional y soporte nativo para docker-compose. Desde ese equipo puedes desarrollar, probar contenedores y, si quieres, desplegar en un servidor remoto por SSH.

Portainer: administración gráfica de contenedores Docker

Aunque la línea de comandos de Docker es potente, puede imponerte respeto si estás empezando. Para suavizar la curva de aprendizaje, una herramienta muy interesante es Portainer, una interfaz web que se ejecuta en un contenedor y te permite gestionar imágenes, contenedores, redes y volúmenes sin recurrir siempre a la consola.

El proceso típico para poner en marcha Portainer en un servidor Linux pasa por crear primero un volumen para persistir su configuración, por ejemplo con un comando para generar portainer_data. Ese volumen se usará para guardar datos de la interfaz, usuarios, conexiones, etc., de forma que no se pierdan al actualizar el contenedor.

Después se lanza el contenedor Portainer mapeando los puertos necesarios, por norma general el 9000 para la interfaz web y, si lo necesitas, el 8000 para ciertas funciones adicionales. Además, es obligatorio montar el socket de Docker (/var/run/docker.sock) dentro del contenedor para que Portainer pueda hablar con el motor Docker del host y gestionar los recursos.

Una vez levantado el contenedor, accedes a Portainer desde el navegador apuntando a la IP de tu servidor y el puerto 9000. En el primer acceso te pedirá crear un usuario administrador con su contraseña y configurar la conexión inicial, que en el caso habitual será la conexión local al Docker Engine del propio servidor.

Desde la interfaz de Portainer puedes ver de un vistazo todos tus contenedores, revisar su estado, logs, reiniciarlos, crear stacks usando archivos docker-compose, gestionar imágenes, redes, volúmenes y, en general, tener una vista mucho más cómoda de todo lo que ocurre en tu servidor Docker, incluso si se trata de varios hosts remotos.

Crear una red puente y servicios compartidos en Docker

Cuando empiezas a montar varios servicios en contenedores (web, base de datos, nube, proxy inverso, DNS, etc.) lo más limpio es definir una red Docker específica para que todos ellos se vean entre sí por nombre, sin tener que ir a tiro de IPs internas que pueden cambiar.

Al crear una red tipo bridge personalizada, Docker levanta de forma automática un pequeño servicio DNS interno. Todos los contenedores que conectes a esa red podrán resolverse por su nombre de contenedor, lo cual viene genial para configuraciones como Nginx proxy inverso, Nextcloud hablando con MariaDB o aplicaciones que dependen de otros servicios.

Conviene tener en cuenta que los nombres de contenedor deben ir en minúsculas cuando se usan en configuraciones como las de Nginx, ya que este servidor web convierte los nombres de host a minúsculas al resolver DNS. Si mezclas mayúsculas y minúsculas podrías tener quebraderos de cabeza innecesarios.

En muchos casos, además de la red Docker, vas a querer un servicio DNS externo o de red doméstica que te permita acceder a tus dominios o subdominios públicos desde fuera de tu red NAT. Aquí entran en juego servicios como DuckDNS o los DNS del propio router, que puedes combinar con contenedores para actualizar IPs dinámicas.

En resumen, la idea es que todos tus contenedores de infraestructura compartan una misma red interna (por ejemplo, «proxy_net» o similar), mientras que sólo unos pocos exponen puertos hacia el exterior (normalmente el proxy inverso), simplificando así la configuración de cortafuegos y reenvío de puertos en el router.

DuckDNS: dominio dinámico gratuito como contenedor

Si tu proveedor de Internet te asigna una IP dinámica y quieres acceder a tu servidor casero desde fuera, necesitas algún tipo de DNS dinámico que actualice tu IP en un dominio o subdominio. DuckDNS es una de las opciones gratuitas más conocidas y funciona muy bien con Docker.

Con la imagen linuxserver/duckdns puedes montar un contenedor que se encarga de ir actualizando cada cierto tiempo la IP asociada a tu subdominio DuckDNS. De esta forma, aunque el router cambie de IP pública, seguirás entrando siempre a través de la misma URL.

Si no has descargado la imagen de DuckDNS previamente, Docker lo hará por ti la primera vez que lances el contenedor. A partir de ese momento, solo tendrás que definir correctamente las variables de entorno (token de DuckDNS, subdominios, etc.) y conectarlo a la red Docker que vayas a usar para los servicios expuestos.

Una práctica habitual con imágenes de linuxserver.io es indicarle a cada contenedor la UID y GID del usuario del servidor que será propietario de los directorios mapeados. De este modo, todos los ficheros de configuración, logs y datos generados tendrán los permisos adecuados en el sistema anfitrión.

Para no liarte con permisos, suele ser buena idea crear un usuario específico en el servidor que será dueño de todas las carpetas donde se guardarán datos de contenedores (por ejemplo /home/user/appdata/…). Después, reúsas esa UID/GID en los contenedores de linuxserver para que todo quede alineado.

Base de datos MariaDB/MySQL y Nextcloud en contenedores

Muchos de los servicios que vas a querer en tu servidor casero necesitan una base de datos detrás. Un ejemplo clásico es Nextcloud, tu nube personal, que requiere un motor tipo MariaDB/MySQL para funcionar de forma fiable y con buen rendimiento.

Con la imagen linuxserver/mariadb puedes levantar un SGBD ligero, configurando desde el propio contenedor el usuario, la contraseña y la base de datos que utilizará Nextcloud. Todo ello se hace con variables de entorno que se pueden definir en la línea de comandos de docker run o en tu archivo docker-compose.

Una vez creado el contenedor de MariaDB, puedes iniciarlo y acceder a él con el cliente de MySQL desde otro contenedor o desde el host, según cómo lo tengas organizado. Desde ahí podrás crear bases de datos adicionales, ajustar permisos o hacer mantenimiento de forma habitual.

El siguiente paso suele ser desplegar el contenedor de Nextcloud, usando la imagen linuxserver/nextcloud o la oficial. Este contenedor se conectará a MariaDB a través de la red Docker interna, usando como host de la base de datos el nombre del contenedor (por ejemplo, «mariadb») en lugar de una IP.

Una estrategia habitual es no terminar la configuración de Nextcloud en local con su puerto HTTP directo, sino esperar a tener listo el proxy inverso con HTTPS y certificados de Let’s Encrypt. Así, la primera vez que entres en la URL pública ya estarás trabajando con la instalación definitiva y detrás del proxy segurizado.

Proxy inverso con Nginx y Let’s Encrypt en Docker

Para exponer varios servicios desde tu servidor casero a Internet sin andar abriendo puertos aleatorios, lo más cómodo es colocar un proxy inverso con Nginx delante de todo, que reciba el tráfico HTTPS en el puerto 443 y lo reparta a los distintos contenedores internos según el dominio o subdominio solicitado.

La imagen linuxserver/letsencrypt integra Nginx y la gestión de certificados de Let’s Encrypt, de forma que el propio contenedor se encarga de solicitar, crear y renovar automáticamente los certificados SSL. Normalmente se valida la propiedad de los subdominios bien por HTTP (puerto 80) o bien mediante DNS, para lo cual DuckDNS es un buen compañero.

La primera vez que arrancas el contenedor de Nginx + Let’s Encrypt, este realiza el proceso de validación y generación de certificados. Hasta que esto no se completa con éxito, Nginx no se pone plenamente operativo. Los certificados tendrán una validez de 90 días y el contenedor revisará de forma automática si necesita renovarlos, intentándolo con antelación suficiente.

Si la renovación automática falla y quedasen menos de 30 días para que caduquen los certificados, tendrás que revisar los registros en la ruta de logs correspondiente (típicamente /config/log/letsencrypt) para detectar qué está fallando: problemas de DNS, puertos cerrados, cambios en el dominio, etc.

En cuanto a puertos, lo normal es mapear el 443 del contenedor para acceso HTTPS y redirigir desde el router el puerto 443 de la WAN al puerto que uses en el servidor (por ejemplo 444) y de ahí al 443 del contenedor. El puerto 80 solo es estrictamente necesario para validaciones HTTP; si validas por DNS podrías prescindir de él salvo que quieras redirecciones automáticas de HTTP a HTTPS.

Alojamiento web estático y configuración de Nginx

Una vez que tu contenedor de Nginx con Let’s Encrypt funciona bien, puedes aprovecharlo para hospedar páginas web estáticas sin necesidad de montar nada más. Basta con colocar tus archivos HTML, CSS y JavaScript en la carpeta del host que tengas mapeada hacia la ruta web dentro del contenedor.

En configuraciones típicas de linuxserver/letsencrypt, todos los ficheros de configuración y contenido viven bajo la ruta /config dentro del contenedor, que sueles mapear a algo como /home/user/appdata/letsencrypt en el servidor. Los documentos web se colocan en /config/www (por ejemplo, un archivo page1.html que será accesible vía HTTPS).

La configuración principal del sitio por defecto en Nginx suele estar en /config/nginx/default. No conviene borrar este archivo porque se regenerará al reiniciar el contenedor, pero sí puedes editarlo para ajustar puertos, rutas, redirecciones y comportamiento general.

Por defecto, la configuración suele escuchar en el puerto 443 y tener como raíz de documentos /config/www. Si quieres habilitar también la escucha en el puerto 80 y que todo lo que llegue por HTTP se redirija a HTTPS, tendrás que descomentar las directivas adecuadas en la parte superior de la configuración por defecto.

Tras cualquier cambio en archivos de configuración de Nginx, es suficiente con reiniciar el contenedor para que la nueva configuración se aplique. No hay que tocar el host ni reiniciar servicios fuera del contenedor, lo que hace muy ágil ir ajustando detalles de tu servidor web casero.

Colocar Nextcloud como subdominio detrás del proxy

Una de las ventajas de usar Nginx como proxy inverso en Docker es poder disponer de varios servicios accesibles a través de subdominios limpios, como nextcloud.tudominio.duckdns.org, sin mezclarlos con puertos raros o rutas confusas.

En la estructura típica de la imagen linuxserver/letsencrypt, encontrarás plantillas de configuración para diferentes aplicaciones en /config/nginx/proxy-confs. Para Nextcloud suele existir un archivo de ejemplo llamado algo como nextcloud.subdomain.conf.sample.

Para activar el proxy para tu instancia de Nextcloud, renombra ese archivo de ejemplo a nextcloud.subdomain.conf, ajusta lo que necesites (rutas, nombre real del contenedor de Nextcloud si no coincide, etc.) y reinicia el contenedor de letsencrypt para que Nginx cargue la nueva configuración.

A partir de ese momento, si accedes por primera vez a la URL tipo https://nextcloud.tusubdominio.duckdns.org, deberías ver la pantalla de instalación de Nextcloud pasando ya por el proxy inverso y con certificados SSL válidos emitidos por Let’s Encrypt.

En el formulario de configuración inicial de Nextcloud, crearás el usuario administrador con su contraseña y rellenarás los datos de conexión a la base de datos MariaDB: nombre de la base (por ejemplo nextcloud_db), usuario (como MYSQL_USER=nextcloud), contraseña escogida y «mariadb» como dirección de host si ese es el nombre del contenedor de base de datos en la red Docker.

Desde ese momento, cualquier usuario que se conecte a tu Nextcloud lo hará a través del contenedor de letsencrypt por HTTPS en el puerto 443, y este reenviará el tráfico al contenedor de Nextcloud por la red interna, donde no es necesario cifrar de nuevo ya que todo queda dentro de tu infraestructura local.

Servidor de archivos, multimedia y contraseñas con Docker Desktop

Más allá de la parte puramente técnica de redes y proxys, un servidor casero brilla cuando empiezas a usarlo para cosas del día a día: almacenar archivos, gestionar tu biblioteca multimedia, guardar contraseñas o bloquear trackers y publicidad a nivel de red.

Como servidor de archivos puedes montar carpetas compartidas en tu PC, portátil o móvil y usarlas como si fueran discos de red. Soluciones como Nextcloud o FileBrowser desplegadas en contenedores actúan como tu propia nube privada, alternativa a Google Drive o Dropbox, con posibilidad de compartir, previsualizar y sincronizar.

Para fotos, algunos NAS como Synology traen aplicaciones propias muy cómodas y bien integradas. Si trabajas sobre un servidor genérico con Docker, puedes recurrir a aplicaciones de galería o aprovechar las capacidades de Nextcloud para gestionar y ver fotografías desde cualquier dispositivo.

En el ámbito multimedia, contenedores como Plex, Jellyfin o Emby te permiten montar un «Netflix casero» con tu propia biblioteca de películas, series y música. Plex tiene versión nativa para muchos NAS y dispone de apps para casi todas las plataformas; Jellyfin y Emby también son grandes opciones, especialmente si quieres soluciones libres o autoalojadas sin coste de licencia.

Para automatizar descargas de contenido multimedia, el ecosistema de aplicaciones -arr (Prowlarr, Sonarr, Radarr, Readarr…) combinado con un cliente de torrents como Transmission va como anillo al dedo y se despliega de maravilla en Docker. Cada servicio en su contenedor, todos compartiendo carpetas de descarga y biblioteca.

En cuanto a seguridad de accesos, un gestor de contraseñas autohospedado como Vaultwarden (implementación ligera compatible con Bitwarden) es una joya para tener tus credenciales bajo tu control. Se integra con extensiones de navegador y apps móviles, y evita el riesgo de guardar contraseñas directamente en el navegador, algo muy poco recomendable si te entra malware.

Pi-hole, DNS filtrante y otros usos avanzados

Otro uso muy práctico de un servidor casero con Docker es desplegar un DNS filtrante como Pi-hole. Aunque nació principalmente para bloquear publicidad, es igual de útil para cortar trackers y dominios de seguimiento que no aportan nada y sí recopilan datos sobre tus hábitos de navegación.

Con Pi-hole en un contenedor puedes configurar tu red para que todos los equipos usen ese DNS, ya sea apuntando cada dispositivo a su IP o configurando el router para que distribuya la IP de Pi-hole por DHCP. Así toda la navegación pasará por ese filtro antes de salir a Internet.

Listas como las que ofrece Firebog permiten afinar lo que se bloquea: publicidad intrusiva, dominios de malware, rastreadores, etc. Es cuestión de ir probando y ver qué equilibrio encaja contigo, para no romper webs por bloquear demasiado ni dejar pasar todo por defecto.

A partir de ahí, el límite en un servidor casero con Docker lo marca tu imaginación (y el hardware). Puedes montar servidores de juegos para tus amigos, laboratorios de desarrollo usando NodeJS, bases de datos MongoDB, entornos MEAN completos, sistemas de cámaras de seguridad que sincronicen grabaciones en la nube y mucho más.

Si te preocupan las conexiones seguras desde fuera, añadir contenedores de WireGuard o ZeroTier te permitirá acceder a tu red doméstica como si estuvieras dentro, o bien ofrecerles a tus amigos un acceso controlado a tus servidores de juego y otros servicios sin exponerlo todo abiertamente a Internet.

Combinar un servidor casero (PC antiguo, NAS o cloud) con Docker o Docker Desktop te da una plataforma flexible, ampliable y relativamente sencilla de mantener para centralizar servicios, experimentar con nuevas tecnologías y tener más control sobre tus datos, tus aplicaciones y tu red doméstica, escalando poco a poco desde un simple servidor de archivos hasta un auténtico centro de operaciones digital personal.