Montar un servidor en casa usando Docker Desktop como pieza central se ha convertido en una de las formas más cómodas de tener tus propios servicios: nube privada, servidor multimedia, VPN, DNS filtrado, gestores de contraseñas y hasta servidores de juegos. Con un poco de maña y cualquier PC viejo o mini PC, puedes montar un auténtico laboratorio doméstico para aprender y, de paso, tener servicios útiles para tu día a día.
La idea general es muy sencilla: usar un sistema operativo estable (Debian, Ubuntu, Proxmox, incluso Windows) y apoyarte en Docker para encapsular cada servicio en su propio contenedor. Así separas cada aplicación, evitas conflictos, facilitas las actualizaciones y puedes tirar todo abajo y levantarlo de nuevo sin miedo a romper el sistema entero. Vamos a ver, paso a paso y con bastante detalle, cómo se organiza todo esto y qué servicios interesantes puedes montar en tu servidor casero usando Docker o Docker Desktop.
Elegir el equipo y el sistema para tu servidor casero
Lo primero es tener claro con qué máquina vas a trabajar: cualquier ordenador antiguo que tengas por casa suele ser más que suficiente para empezar. Mucha gente reutiliza una torre vieja, otros se compran un mini PC de bajo consumo, y también hay quien da el salto a un NAS tipo Synology o a una solución más pro como Proxmox.
Si optas por una torre antigua, lo normal es añadirle discos duros dedicados al almacenamiento, por ejemplo un par de HDD de varios teras en RAID para tener tolerancia a fallos. Un caso bastante típico es montar dos discos de 2 TB en RAID y, más adelante, ampliarlos a discos de 8 o 12 TB cuando el espacio se quede corto.
En cuanto al sistema operativo, el abanico es amplio: puedes usar Windows, Linux o una distro específica para almacenamiento como TrueNAS. Mucha gente empieza directamente con el Windows que trae el PC y funciona sin problemas, pero si hoy tuvieras que empezar desde cero, probablemente te interese más un Linux ligero (Debian o Ubuntu Server) o un NAS con su propia distribución, como los Synology que llevan un Linux muy optimizado.
El hardware mínimo tampoco es una locura: para la mayoría de servicios caseros, con 2 GB de RAM y una CPU de dos núcleos vas sobrado, siempre que el sistema esté algo optimizado y no cargues un escritorio pesado. En un NAS tipo Synology con 2 GB de RAM y un dual core puedes tener un buen puñado de contenedores (cloud, multimedia, descargas, DNS, etc.) sin pasar del 20 % de CPU, salvo picos puntuales al reproducir vídeo.
La gran duda suele ser si ir a por un NAS como un Synology o seguir con una torre: el NAS ocupa menos, hace mucho menos ruido y viene bastante afinado para ser servidor, pero es más caro si ya tienes una torre en casa. En cambio, la torre es ampliable, puedes cambiar CPU, RAM, añadir tarjetas… y si necesitas mucha potencia, será la opción más flexible. Eso sí, revisa que tenga una tarjeta de red decente, porque de poco sirve tener un servidor potente si el cuello de botella es la conexión.
Proxmox, Docker, Docker Desktop y Portainer: el combo para tu laboratorio
Una forma muy cómoda de organizar tu servidor casero es montar Proxmox como capa de virtualización y, dentro de él, crear contenedores LXC o máquinas virtuales donde instalar Docker. Proxmox se administra íntegramente desde el navegador, entrando a la IP del servidor (algo tipo http://<ip_servidor>), así que no necesitas tener monitor ni teclado conectados al “servidor”.
En un escenario típico con Proxmox, puedes tener varios contenedores LXC corriendo distintas distros (Debian, Ubuntu, etc.), cada uno con su propia IP y recursos asignados. Dentro de uno de ellos instalas Docker, y a partir de ahí gestionas los contenedores desde la línea de comandos o desde una interfaz gráfica como Portainer. Esto te permite aislar servicios y tener, por ejemplo, un contenedor para servicios web, otro para bases de datos, otro para monitorización, etc.
Docker en sí es una plataforma de contenedores que encapsula aplicaciones junto con todas sus dependencias. El sistema anfitrión comparte el kernel, así que es mucho más ligero que una máquina virtual completa. Esto es ideal para tener varios servicios escuchando en los mismos puertos internamente, pero mapeando puertos diferentes hacia el exterior para evitar conflictos. Por ejemplo, dos contenedores con servidores web usando el puerto 80 en su interior, pero uno expuesto como 8080:80 y el otro como 8081:80 en el host.
Si trabajas en escritorio (Windows o macOS), Docker Desktop te simplifica enormemente la configuración, porque te instala el motor de Docker, una interfaz gráfica básica y la integración con Docker Compose. En un servidor Linux puro usarás Docker Engine “a pelo”, sin interfaz de escritorio, pero la filosofía es la misma.
Como guinda, puedes instalar Portainer, que es una interfaz web muy cómoda para gestionar contenedores, imágenes, redes y volúmenes sin depender de la terminal. Desde Portainer arrancas, paras, borras contenedores, ves logs, creas stacks con archivos docker-compose.yml y controlas varios hosts Docker desde un único panel.
Instalar Docker en Debian, Proxmox o un contenedor LXC
Si eliges Debian 10/11 como sistema base, el proceso recomendado es añadir el repositorio oficial de Docker y evitar el paquete que trae la distribución por defecto, que suele ir más desactualizado. Los pasos típicos son preparar el sistema, añadir la clave GPG, configurar el repositorio, instalar los paquetes y probar que todo funciona.
Primero actualizas el sistema, instalas paquetes básicos (como ca-certificates, curl, gnupg y lsb-release) y luego descargas la llave del repositorio oficial de Docker, la registras en el sistema y añades la entrada correspondiente a tu versión de Debian. Después instalas el motor de Docker y los componentes recomendados.
Una vez instalado, es buena idea lanzar el contenedor de prueba hello-world para verificar que Docker está operativo y comprobar la versión con docker --version. De paso, conviene añadir tu usuario al grupo docker para no tener que usar sudo todo el rato. Tras un reinicio rápido compruebas el estado del servicio con systemctl status docker y listo.
En entornos con Proxmox y contenedores LXC, mucha gente usa un script automatizado que se lanza dentro del LXC y deja Docker listo para funcionar, ajustando cgroups y demás peculiaridades de los contenedores. Estos scripts suelen estar en repositorios comunitarios de Proxmox y ahorran bastante tiempo, aunque siempre puedes seguir también la documentación oficial de Docker para Ubuntu o Debian.
Si estás en Windows o macOS con Docker Desktop, el proceso es más amigable: descargas el instalador, lo ejecutas, reinicias si hace falta y la propia app levanta el motor de Docker en segundo plano. Desde la interfaz gráfica puedes ver contenedores, imágenes y logs, y en paralelo usar la terminal de siempre con los mismos comandos de Docker.
Portainer: panel web para controlar tus contenedores
Portainer es de esas herramientas que, cuando la pruebas, ya no quieres volver a gestionar todo sólo con CLI, sobre todo si estás empezando. Se despliega como un contenedor Docker más y, una vez en marcha, te da un panel web para ver y gestionar tu entorno.
En un servidor Debian, por ejemplo, lo más habitual es crear primero el contenedor de Portainer mapeando el puerto 9000 (o 9443 si usas HTTPS). La imagen clásica es portainer/portainer o, en la versión actual, portainer/portainer-ce. Con un simple comando docker run indicando nombre del contenedor, puertos y volumen de datos, ya tienes el panel preparado.
Para acceder sólo tienes que abrir el navegador y apuntar a la IP del servidor seguida del puerto, algo tipo http://ip-del-servidor:9000. En el primer acceso, Portainer te pide crear la contraseña del usuario administrador, seleccionar el entorno (en local, el propio host Docker) y, a partir de ahí, quedarás en el panel principal desde el que podrás ver imágenes, contenedores, redes, volúmenes, stacks, etc.
La gran ventaja es que Portainer te permite crear contenedores a golpe de clic, bien a partir de plantillas, bien subiendo tus propios archivos docker-compose.yml en la sección de Stacks. También puedes ver los logs en tiempo real, gestionar las variables de entorno, montar volúmenes, redes y mucho más sin necesidad de sabértelo todo de memoria en la terminal.
Redes Docker, DNS interno y preparación para un proxy inverso
Cuando empiezas a tener varios contenedores que necesitan hablar entre sí (web, base de datos, nube, proxy inverso…), es fundamental entender cómo funciona la red en Docker. Lo más habitual es crear una red tipo bridge (puente) propia para tus servicios y conectar a ella todos los contenedores que deban comunicarse.
Al crear una red bridge personalizada, Docker levanta un pequeño servidor DNS interno para esa red. Esto significa que los contenedores se pueden resolver entre sí por nombre, sin necesidad de IPs. Por ejemplo, si tu contenedor de base de datos se llama mariadb y tu contenedor de Nextcloud está en la misma red, podrás usar mariadb como host de la base de datos en la configuración de Nextcloud.
Una pequeña curiosidad: si luego usas esos nombres en configuraciones de nginx (ya sea en un proxy inverso manual o en un contenedor preparado), es recomendable que todos los nombres de contenedor estén en minúsculas, porque nginx normaliza a minúsculas antes de resolver. Así evitas problemas tontos de DNS que te harán perder tiempo.
Esta red bridge común también viene genial cuando montas un proxy inverso con nginx o herramientas tipo Nginx Proxy Manager o Traefik, ya que el proxy sólo tiene que saber los nombres de los contenedores de destino (por ejemplo, nextcloud, jellyfin, etc.) y podrá enrutar el tráfico internamente sin tocar IPs.
Acceso externo: DuckDNS, certificados SSL y Let’s Encrypt
Si quieres acceder a tu servidor casero desde fuera de tu red (por ejemplo, a tu nube privada o a tu servidor multimedia), vas a necesitar un dominio o subdominio que apunte a tu IP. Como la mayoría tenemos IP dinámica de nuestro ISP, una solución muy usada es DuckDNS, que te da un subdominio gratuito y una forma sencilla de actualizar la IP.
La gracia es que también puedes usar DuckDNS desde Docker, levantando un contenedor como el de linuxserver/duckdns. En este contenedor configuras tu subdominio y tu token, y él se encarga de ir actualizando la IP pública para que el nombre de dominio siempre apunte correctamente a tu casa. Así no te tienes que preocupar de si el router ha cambiado de IP tras un reinicio.
Sobre esta base es donde entra en juego Let’s Encrypt. La idea es levantar un contenedor que combine nginx como proxy inverso y Let’s Encrypt para gestionar certificados SSL de forma automatizada. La imagen de linuxserver/letsencrypt es un clásico: se ocupa de emitir un certificado (incluso comodín para subdominios) y de renovarlo automáticamente cada vez que se acerque su caducidad.
En el primer arranque del contenedor, Let’s Encrypt valida que realmente eres el dueño del dominio, normalmente usando el propio DuckDNS. Si todo va bien, genera los certificados y a partir de ahí nginx empieza a responder por HTTPS en el puerto 443. Los certificados duran 90 días, pero el contenedor revisa su estado a diario y, si ve que quedan menos de 30 días, intenta renovarlos solo. Si algo falla, los logs en /config/log/letsencrypt te dirán qué ha pasado.
En cuanto a la configuración de puertos, muchas veces se juega con el redireccionamiento del router: por ejemplo, redirigir el puerto 443 externo al 444 interno del servidor, y luego mapear el 444 del servidor al 443 del contenedor en Docker. De cara a internet, sigues entrando por https://tusubdominio.duckdns.org sin notar nada. El puerto 80 sólo hace falta exponerlo si quieres validación HTTP, pero para ciertos modos de validación DNS ni siquiera es imprescindible.
Alojar webs estáticas y configurar nginx en el contenedor
Una vez que tu contenedor de nginx + Let’s Encrypt está funcionando, puedes aprovecharlo para servir un sitio web estático junto con el resto de servicios. Esta imagen suele mapear una carpeta de configuración y datos al host, algo tipo /home/user/appdata/letsencrypt, donde dentro tendrás subcarpetas como /config, /www, /nginx, etc.
Los archivos HTML de tu web estática se suelen colocar en /config/www. Así, si copias ahí un index.html o un page1.html, podrás acceder mediante tu dominio seguro: por ejemplo, https://www.subdominio.duckdns.org/page1.html. Es una forma muy sencilla de mantener una web “casera” directamente desde el mismo servidor.
El fichero de configuración principal de nginx suele estar en /config/nginx/default. No es buena idea borrarlo porque se regenera al reiniciar el contenedor, pero sí puedes editarlo para adaptarlo a tus necesidades. De fábrica suele escuchar en el puerto 443, con la raíz de documentos apuntando precisamente a /config/www.
Si quieres que también escuche en el puerto 80 y redirija todo el tráfico HTTP a HTTPS, tendrás que descomentar las líneas correspondientes en la parte superior del archivo (el bloque server que escucha en el 80 y devuelve una redirección al 443). Después de cada cambio en los ficheros de configuración, reinicia el contenedor para que nginx recargue la configuración.
Nextcloud tras un proxy inverso: tu nube privada
Una de las aplicaciones estrella para un servidor casero es Nextcloud, tu cloud privada con sincronización de archivos, calendario, contactos, notas, galería de fotos y mucho más. Normalmente lo despliegas junto con una base de datos, por ejemplo MariaDB, y luego lo pones detrás del proxy inverso que ya tienes con Let’s Encrypt.
El flujo típico en Docker es algo así: primero creas un contenedor de base de datos usando la imagen linuxserver/mariadb, configurando las variables de entorno para que cree un usuario y una base de datos específicos para Nextcloud (por ejemplo, MYSQL_USER=nextcloud, una contraseña segura y una base de datos llamada nextcloud_db). Luego levantas el contenedor y, si quieres, entras en él para gestionar las bases de datos desde la línea de comandos.
Después creas el contenedor de Nextcloud con la imagen linuxserver/nextcloud o la oficial, conectándolo a la misma red bridge y apuntando sus variables a la base de datos por nombre de contenedor (usando mariadb como host). Al principio podrías acceder temporalmente a Nextcloud por un puerto interno (algo tipo http://ip_servidor:444), pero lo más habitual es esperar a ponerlo detrás del proxy y terminar la configuración ya bajo HTTPS.
Para integrarlo con el proxy inverso de Let’s Encrypt, en la carpeta /config/nginx/proxy-confs de ese contenedor encontrarás archivos de ejemplo, como nextcloud.subdomain.conf.sample. Basta con renombrarlo a nextcloud.subdomain.conf y ajustar, si quieres, el subdominio que vas a usar (algo tipo nextcloud.subdominio.duckdns.org). Tras reiniciar el contenedor de Let’s Encrypt, ese subdominio ya apuntará a tu contenedor de Nextcloud.
En la primera visita a https://nextcloud.tusubdominio.duckdns.org, verás la pantalla de instalación de Nextcloud: ahí defines el usuario administrador y su contraseña, indicas la base de datos (nextcloud_db), el usuario y la contraseña configurados en MariaDB, y como host de DB pones mariadb. Desde ese momento, todos los accesos de los usuarios se harán cifrados gracias al proxy de Let’s Encrypt, mientras que la comunicación interna entre el proxy y el contenedor de Nextcloud se mantiene en la red local Docker.
Servicios imprescindibles que puedes montar con Docker
Una vez que tienes la base funcionando (Docker, red bridge, proxy inverso, certificado SSL), el cielo es el límite. Hay un montón de servicios ideales para un servidor casero, y casi todos tienen imágenes muy bien mantenidas que puedes desplegar vía Docker Compose o Portainer.
Para la gestión de Docker, Portainer es tu mejor aliado: te deja ver todos los contenedores, imágenes y volúmenes de un vistazo, y también crear stacks complejos usando archivos docker-compose.yml. Además, si en el futuro tienes más de un host Docker (por ejemplo, otro servidor en tu red), puedes gestionarlos todos desde una sola instancia de Portainer.
Un clásico para centralizar dominios y certificados sin tener que pelearte a mano con nginx es Nginx Proxy Manager. Es un contenedor que expone los puertos 80, 81 y 443: el 80 para HTTP, el 443 para HTTPS y el 81 para la interfaz de administración. Se levanta vía Docker Compose definiendo la imagen (jc21/nginx-proxy-manager:latest), el container_name, las políticas de reinicio, los puertos y los volúmenes de configuración y datos, de forma que los certificados y ajustes persistan aunque borres el contenedor.
En el propio fichero docker-compose.yml puedes jugar con el mapeo de puertos, por ejemplo cambiando el puerto de administración a algo menos estándar: si pones 84:81, estarás redirigiendo el puerto 84 del host al 81 del contenedor, así que entrarías al panel web desde http://<ip_servidor>:84. Esto es útil si tienes otras aplicaciones ocupando el 81 o quieres evitar los valores por defecto.
A nivel de volúmenes, Nginx Proxy Manager suele montar carpetas del host (rutas absolutas) donde guardará configuración y certificados, pero también puedes optar por volúmenes nombrados de Docker, que no requieren rutas específicas en el sistema de archivos. Docker los almacena en /var/lib/docker/volumes y son perfectos cuando no necesitas controlar exactamente dónde van los datos, sólo que se conserven al recrear contenedores.
Además del proxy y Portainer, hay toda una colección de servicios muy populares en un homelab: Wireguard o Zerotier para VPN, AdGuard o Pi-hole para DNS filtrado, Grafana y Prometheus para monitorización, bases de datos como PostgreSQL, MongoDB o Redis, Nextcloud para la nube, Jellyfin o Plex para multimedia, Home Assistant para domótica y los típicos servicios -arr (Sonarr, Radarr, Prowlarr, Readarr) integrados con un cliente de torrents tipo Transmission.
Almacenamiento, multimedia, contraseñas y DNS filtrado en tu servidor
Uno de los usos más prácticos de un servidor casero es como servidor de archivos centralizado donde guardar documentos, fotos, vídeos y copias de seguridad. Puedes montarlo como una simple carpeta de red desde el explorador de archivos de tu PC, o darle una capa “cloud” con Nextcloud o FileBrowser, según si quieres algo parecido a Google Drive o prefieres algo más sencillo.
Si sólo sois dos o tres personas accediendo a los archivos (por ejemplo, tú y tu pareja), muchas veces resulta más cómodo mapear una unidad de red en el sistema (SMB/NFS) y olvidarte de interfaces web complicadas. Eso no quita que puedas aprovechar aplicaciones de fotos específicas del NAS (como las de Synology) o de Nextcloud para tener galerías ordenadas y accesibles desde el móvil.
El otro gran clásico es el servidor multimedia casero. Aunque sigas pagando Netflix, Prime, HBO y compañía, siempre habrá contenido que no está en ninguna plataforma o que quieres tener descargado. Para reproducirlo en la tele, móvil o tablet, lo habitual es usar Plex, Emby o Jellyfin. En entornos Synology, por ejemplo, Plex suele ir especialmente fino al tener paquete nativo, sin necesidad de Docker, lo que reduce la carga de CPU y mejora la experiencia.
Plex tiene la pega de que la parte móvil requiere suscripción (unos 5 euros al mes o una licencia vitalicia más cara), pero a cambio ofrece una interfaz muy pulida y soporte decente. Jellyfin es totalmente libre y gratuito, pero en según qué combinaciones de hardware y transcodificación puede dar pequeños tirones. Emby se queda en un punto intermedio. Lo ideal es probar varios y ver cuál se adapta mejor a tu servidor y a tus clientes.
Para automatizar la descarga de contenido, lo normal es montar el combo de aplicaciones terminadas en -arr: Prowlarr como agregador de indexadores, Sonarr para series, Radarr para películas, Readarr para libros, y todo ello orquestado con un cliente de torrents como Transmission. Cada componente corre en su contenedor, compartiendo carpetas de descargas y biblioteca, de forma que cuando un episodio está listo, se mueve automáticamente a su sitio y aparece en Plex o Jellyfin.
En cuanto a seguridad, es muy recomendable tener tu propio gestor de contraseñas self-hosted. Vaultwarden (implementación ligera de Bitwarden) es una opción muy popular en Docker, porque se integra con extensiones de navegador y apps móviles igual que el servicio oficial. Así evitas reutilizar contraseñas y no dependes del almacenamiento del navegador, que puede quedar expuesto si pillas malware. Si no quieres alojarlo tú, siempre puedes usar servicios en la nube tipo NordPass, pero lo importante es no guardar claves sin cifrar en el navegador.
Para el tema DNS y bloqueo de publicidad o trackers, Pi-hole sigue siendo uno de los proyectos estrella. Lo colocas en un contenedor, apuntas el router o tus dispositivos para que usen su IP como DNS, y él se encarga de filtrar anuncios y rastreadores basándose en listas externas. Hay webs como Firebog donde puedes recopilar listas de dominios a bloquear: desde simples anuncios hasta trackers intrusivos. Así todo el tráfico de tu red pasa por Pi-hole antes de salir a internet.
Red, puertos, VPN y primeros pasos con Docker si estás perdido
Una de las cosas que más asusta al principio es la parte de red y puertos. En realidad, el concepto base es muy similar al de un servidor de juegos clásico: cada contenedor escucha en uno o varios puertos internos y tú decides qué puertos del host vas a exponer y redirigir desde tu router hacia fuera.
En Docker, la sintaxis de puertos en Compose sigue el esquema host:contenedor. Por ejemplo, 80:80 significa que el puerto 80 del host se mueve al 80 del contenedor. Si cambias a 8080:80, estarás accediendo al puerto 80 interno mediante el 8080 en el host. Esto es lo que te permite tener muchos servicios usando el mismo puerto interno pero con puertos externos diferentes, sin conflictos.
Para acceso remoto seguro a tu red (más allá de exponer servicios concretos), Wireguard es una opción ligera y muy rápida. Con un contenedor de Wireguard bien configurado, puedes conectar tu móvil o portátil desde fuera de casa y navegar como si estuvieras dentro de tu LAN. Zerotier es otra alternativa interesante si quieres crear redes virtuales entre amigos para servidores de juegos y demás, sin pelearte tanto con NAT y puertos en cada extremo.
Si vienes de cero y te suena todo a chino, piensa en un contenedor como un “mini sistema” aislado dentro de tu servidor, al que accedes con comandos tipo docker exec -it nombre_contenedor bash. Es algo parecido a entrar en un entorno virtual, pero a nivel sistema en lugar de sólo librerías de un lenguaje. Dentro del contenedor, usas los comandos propios de la aplicación (por ejemplo, clientes de base de datos, gestores de paquetes, etc.), mientras que fuera manejas la vida del contenedor con docker o docker compose.
Con el tiempo, verás que lo más cómodo es definir todos tus servicios en uno o varios ficheros docker-compose.yml. Ahí declaras la imagen, el nombre del contenedor, la política de reinicio (unless-stopped es muy común), los puertos, los volúmenes y las variables de entorno. Luego sólo tienes que ir a la carpeta donde está el archivo y lanzar docker compose up -d para levantar todo en segundo plano. Si prefieres algo más visual, Portainer te permitirá cargar esos YAML desde la interfaz y gestionarlos como “stacks”.
Cuando tengas ya una base sólida con Docker, un buen puñado de servicios levantados y algo de experiencia con puertos y redes, tu servidor casero se convierte en un laboratorio perfecto para seguir aprendiendo: puedes experimentar con bases de datos, microservicios, monitorización con Grafana y Prometheus, domótica con Home Assistant, o incluso montar tu propio servidor web como campo de pruebas antes de desplegarlo en un VPS público.
Todo este ecosistema, apoyado en Docker o Docker Desktop, hace que con un PC antiguo, un par de discos y algo de tiempo puedas pasar de no saber por dónde empezar a tener un montón de servicios útiles y seguros corriendo en casa, con acceso cifrado desde fuera, copias de seguridad, multimedia centralizado y una infraestructura sobre la que seguir cacharreando sin miedo a romper nada crítico.