Instalar Nextcloud con Docker paso a paso
Montar Nextcloud en el homelab con Docker es más directo de lo que parece cuando tienes el stack bien definido. Aquí está el docker-compose.yml funcional y todo lo que conviene revisar antes de meter datos de verdad.
Si ya tienes homelab, Nextcloud encaja solo
Tienes Proxmox, un NAS, o una máquina Linux que no para. Sabes tirar un docker run sin mirar la documentación. Pero Nextcloud te ha dado pereza: PHP, Apache, permisos de carpetas… parece más lío del que merece. Te entiendo, a mí también me costó dar el paso.
Este tutorial es para ti. No para alguien que empieza desde cero con Linux, sino para quien ya tiene el entorno montado y quiere añadir sincronización de archivos propia sin depender de cuotas ni de que un tercero escanee lo que subes. Con Docker Compose el stack entero son dos contenedores y un fichero de configuración.
Al final tendrás Nextcloud corriendo con MariaDB, los datos persistidos en volúmenes y acceso desde la red local. Lo que no cubre este post: HTTPS, backups y hardening —sin eso no está listo para exponerse a internet, y lo dejamos claro— pero sí tendrás la base funcional sobre la que construir todo eso.
Por qué importa
Tus datos, tu servidor
Nextcloud corre bajo licencia AGPL-3.0: el código es auditable y los archivos nunca salen de tu máquina.
Stack de dos contenedores
Solo necesitas app Nextcloud + MariaDB en un docker-compose.yml. SQLite funciona, pero rinde mucho peor con varios usuarios.
Sync en todos los dispositivos
Clientes oficiales para Windows, macOS, Linux, Android e iOS sincronizan vía WebDAV sobre HTTPS sin configuración extra.
Actualiza sin saltar versiones
Cada versión mayor debe instalarse en orden; saltarse pasos corrompe la base de datos. Revisa el changelog antes de cada upgrade.
Qué necesitas antes de empezar
Para este tutorial parto de que ya tienes Docker Engine y Docker Compose v2 instalados en tu máquina: un servidor Linux, una VM en Proxmox, una Raspberry Pi 4 o lo que tengas en el homelab. Sin eso, primero sigue la documentación oficial de Docker para tu sistema operativo.
Lo que necesitas concretamente:
- Docker Engine ≥ 24.x y Docker Compose v2 (
docker compose, sin guión) - Un usuario con permisos para ejecutar Docker, o acceso root directo
- Un directorio libre donde almacenar datos y configuración
- Un dominio o subdominio si quieres acceso externo con HTTPS (no hace falta para pruebas locales)
Lo he probado en una VM Debian 12 con 2 vCPUs y 4 GB de RAM corriendo en Proxmox. Con menos RAM va, pero la generación de miniaturas de fotos y la indexación de documentos grandes se resiente.
El docker-compose.yml: app y base de datos
Lo primero que conviene aclarar: si levantas Nextcloud sin configurar una base de datos externa, usará SQLite por defecto. Para un solo usuario con pocos archivos puede funcionar, pero el rendimiento cae en picado con múltiples usuarios o bibliotecas de fotos grandes. Configura MariaDB desde el principio y no lo pienses más.
Estructura de directorios
Crea el directorio del proyecto y dos carpetas para los volúmenes:
mkdir -p ~/nextcloud/{data,db}
cd ~/nextclouddata guardará los archivos de usuario y la configuración de la app. db guardará los datos de MariaDB.
El fichero docker-compose.yml
services:
db:
image: mariadb:11
restart: always
environment:
MYSQL_ROOT_PASSWORD: pon_aqui_password_root
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_PASSWORD: pon_aqui_password_user
volumes:
- ./db:/var/lib/mysql
app:
image: nextcloud:30
restart: always
ports:
- "8080:80"
depends_on:
- db
environment:
MYSQL_HOST: db
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_PASSWORD: pon_aqui_password_user
volumes:
- ./data:/var/www/htmlCambia las contraseñas por valores reales antes de levantar el stack. El puerto 8080 del host apunta al 80 del contenedor; para pruebas locales está bien, pero en producción pondrás un reverse proxy delante en lugar de exponer este puerto directamente.
Uso nextcloud:30 en lugar de nextcloud:latest para controlar cuándo actualizo. Con latest, un docker compose pull puede saltar una versión mayor sin que te des cuenta, y eso tiene consecuencias que explico más adelante.
Primer arranque y configuración inicial
Levanta el stack:
docker compose up -dLa primera vez tarda un rato: descarga las imágenes, inicializa la base de datos y prepara la estructura de directorios. Sigue el progreso con:
docker compose logs -f appCuando los logs se calmen, abre http://localhost:8080 en el navegador.
Nextcloud te pedirá crear el usuario administrador. Introduce nombre y contraseña. En la sección de base de datos debería haber autodetectado MariaDB gracias a las variables de entorno; si no, selecciónala manualmente e introduce los mismos valores que pusiste en el compose. La carpeta de datos déjala con el valor por defecto.
La primera vez que monté este stack me quedé mirando la pantalla de «Instalando…» durante tres minutos convencido de que había petado algo. No había petado nada: Nextcloud instala las apps por defecto, genera las tablas de la base de datos y ejecuta varios chequeos internos. Es normal que tarde.
Una vez dentro, ve a Administración → Información básica. Verás una lista de advertencias: falta de HTTPS, configuración de cron, caché de memoria… No son errores bloqueantes, pero son la hoja de ruta de lo que queda por afinar antes de usar esto en serio.
Reverse proxy y HTTPS
Acceder por HTTP en local está bien para comprobar que todo funciona. Pero si vas a usar Nextcloud fuera de tu red, o quieres que los clientes de escritorio y móvil sincronicen sin quejas, necesitas HTTPS. Sin él, credenciales y archivos viajan en claro.
Las opciones más habituales en homelab:
- Nginx Proxy Manager: interfaz web, gestiona certificados Let’s Encrypt automáticamente, fácil de arrancar si no tienes experiencia con nginx en crudo.
- Caddy: gestiona HTTPS de forma automática, configuración muy concisa, buena opción si prefieres trabajar con ficheros de texto.
- Traefik: más potente y flexible, ideal si ya tienes varios servicios en Docker; la curva de aprendizaje inicial es mayor.
El flujo es siempre el mismo: el dominio apunta al reverse proxy (puerto 443), el proxy termina TLS y pasa el tráfico al contenedor de Nextcloud por HTTP interno (puerto 80). Nextcloud no gestiona TLS directamente en este setup.
Trusted domains: cuando cambias de URL
Si accedes desde un dominio diferente al que usaste en la instalación inicial, Nextcloud lo bloqueará por seguridad. Añade el dominio a la lista de confianza con occ:
docker compose exec app php occ config:system:set trusted_domains 1 --value=nextcloud.tudominio.comSi prefieres editar el fichero directamente, está en ./data/config/config.php:
'trusted_domains' =>
array (
0 => 'localhost',
1 => 'nextcloud.tudominio.com',
),Clientes de escritorio y móvil
Nextcloud tiene clientes oficiales para Windows, macOS, Linux, Android e iOS. La sincronización funciona sobre WebDAV, aunque el cliente lo abstrae completamente: introduces la URL de tu instancia, usuario y contraseña, eliges las carpetas a sincronizar, y listo. El flujo es idéntico al de cualquier cliente de nube comercial.
Lo uso principalmente para tener los proyectos de Fusion 360 y los ficheros STL disponibles en todos los ordenadores del taller. No es un backup —los datos siguen viviendo en un solo servidor—, pero para mantener los archivos de trabajo sincronizados entre varios equipos va perfecto.
Una aclaración útil antes de crear expectativas: Nextcloud no es un reemplazo funcional uno a uno de Google Drive si dependes de la edición colaborativa online. Las integraciones de edición (Collabora Online, OnlyOffice) existen y funcionan, pero requieren levantar servicios adicionales y configuración extra; no están incluidas en el stack básico de este tutorial.
Si arrancas sin HTTPS, el cliente de escritorio va a recordártelo con insistencia. Tiene opción de continuar de todos modos, pero es una advertencia que vale la pena resolver antes de empezar a sincronizar documentos reales.
Actualizaciones y backups: no lo dejes para luego
Estos dos puntos son los que más se descuidan en un setup doméstico y los que más problemas causan cuando algo va mal.
Cómo actualizar Nextcloud en Docker
Nextcloud no permite saltar versiones mayores. Si estás en la 28.x y quieres llegar a la 30.x, tienes que pasar por la 29.x primero. Saltarse este paso puede dejar la base de datos en un estado inconsistente del que es difícil recuperarse. Revisa el registro de cambios antes de cada actualización mayor.
- Haz un backup completo antes de tocar nada (ver sección siguiente).
- Edita el
docker-compose.ymly cambia la tag a la siguiente versión mayor (ej:nextcloud:28→nextcloud:29). - Ejecuta
docker compose pull && docker compose up -d. - Espera a que Nextcloud aplique las migraciones de base de datos siguiendo los logs.
- Repite para cada versión mayor hasta llegar a la objetivo.
Por esto no conviene usar nextcloud:latest en producción. Un docker compose pull desatendido puede saltar una versión mayor y romperte la instalación sin previo aviso.
Backups: el volumen local no es suficiente
Los datos en ./data y ./db están en el disco local del servidor. Si el disco falla, el servidor se rompe, o borras el directorio por error, los pierdes. Eso no es una estrategia de backup; es simplemente tener los datos en un sitio.
Lo mínimo que deberías tener automatizado:
- Un dump periódico de la base de datos exportado a otro destino: otro disco, NAS, o almacenamiento remoto.
- Una copia del directorio
./dataa un destino separado del servidor.
Para hacer el dump con Nextcloud en modo mantenimiento y garantizar consistencia:
docker compose exec app php occ maintenance:mode --on
docker compose exec db mysqldump -u nextcloud -ppon_aqui_password_user nextcloud > backup_nextcloud.sql
docker compose exec app php occ maintenance:mode --offHerramientas como Restic o Borgbackup encajan bien aquí para automatizar las copias incrementales y enviarlas a un destino remoto, pero eso da para otro post entero.
Preguntas frecuentes
Q: ¿Funciona Nextcloud en Docker sin saber PHP ni Apache?
A: Exactamente para eso sirve Docker: la imagen oficial de Nextcloud incluye PHP, Apache y todas las dependencias dentro del contenedor. Tú solo gestionas el fichero docker-compose.yml y los volúmenes. No necesitas tocar el sistema operativo del host para nada relacionado con el stack de la app.
Q: ¿Qué base de datos uso: MariaDB, PostgreSQL o SQLite?
A: Para un solo usuario ocasional SQLite puede arrancar, pero el rendimiento cae notablemente en cuanto hay más de un usuario o muchos archivos. Lo recomendable desde el principio es MariaDB o PostgreSQL; el docker-compose.yml ya lo levanta como segundo contenedor, así que el esfuerzo extra es mínimo.
Q: ¿Cómo actualizo Nextcloud en Docker sin romper nada?
A: Las actualizaciones de versión mayor deben hacerse de forma secuencial: no puedes saltar de la 27 a la 30 directamente. El proceso consiste en actualizar a cada versión mayor intermedia, verificar que el upgrade termina sin errores y luego pasar a la siguiente. Revisar el changelog antes de cada salto es obligatorio.
Q: ¿Este setup con Docker es seguro para producción real?
A: El contenedor en sí es funcional, pero no es production-ready tal cual: falta configurar HTTPS mediante un reverse proxy (nginx, Caddy o Traefik), establecer una estrategia de backups real y aplicar hardening básico. El volumen local donde viven los datos no es un backup; si el disco falla, los datos se pierden.
Q: ¿Vale Nextcloud para reemplazar Google Drive completamente?
A: Cubre la sincronización de archivos y el acceso desde clientes de escritorio y móvil mediante WebDAV, y en eso funciona bien. Pero algunas integraciones que das por supuestas en Google Workspace (edición colaborativa online con Office 365, por ejemplo) no existen en autoalojado o requieren añadir servicios externos como Collabora o OnlyOffice.
Deja una respuesta