Limitaciones reales de Nextcloud en un VPS

En qué aspectos falla Nextcloud, en el orden en que suelen aparecer

La mayoría de las limitaciones de Nextcloud en un VPS dependen del número de archivos y de solicitudes, no del espacio en disco. Una biblioteca de 200 GB formada por archivos de vídeo funciona bien en un servidor pequeño. Los mismos 200 GB distribuidos entre 400,000 archivos pequeños hacen que cada listado de directorio sea lento y convierten la base de datos en el proceso con más actividad del servidor. El orden siguiente coincide con el orden en que un administrador que aloja el servicio encuentra estos límites: primero el modelo de solicitudes de PHP, después el cliente de sincronización, luego los valores predeterminados de la base de datos, después las tareas en segundo plano y, por último, la memoria.

Parte de lo que se describe como «Nextcloud es lento» se debe a un valor predeterminado que nadie ha cambiado. El resto se debe al diseño y no desaparecerá con ajustes de configuración. Cada sección indica cuál de los dos casos se aplica.

Por qué PHP determina el límite de concurrencia

Nextcloud está escrito en PHP, y una aplicación PHP no es un servidor de ejecución prolongada. Cada petición la gestiona un proceso worker del grupo de PHP-FPM (gestor de procesos FastCGI), y ese worker se encarga de la petición de principio a fin. Por tanto, el número de peticiones que el servidor puede gestionar al mismo tiempo es pm.max_children, y cada uno de esos workers mantiene su propia memoria.

De ahí se derivan dos consecuencias. Una petición lenta mantiene ocupado un worker durante toda su ejecución, por lo que una persona que prepara una carga de 4 GB ocupa un slot que nadie más puede usar. Cuando todos los workers están ocupados, las peticiones nuevas esperan en la cola de espera del socket. El grupo lo indica en su registro:

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

Normalmente, el primer síntoma que observa el usuario es un error 504 del servidor web frontal:

upstream timed out (110: Connection timed out) while reading response header from upstream

El grupo incluido por defecto en muchas distribuciones suele proporcionar pm.max_children = 5. Es una estimación razonable para un servidor compartido, pero demasiado baja para una instancia de Nextcloud con una docena de clientes de sincronización conectados. Calcule el tamaño a partir de la memoria disponible: mida el tamaño residente de un worker ocupado, reserve espacio para la base de datos y la caché y divida el resultado.

pm = dynamic
pm.max_children = 12
pm.max_requests = 500
php_value[memory_limit] = 512M

memory_limit es un límite por petición, no una asignación. La mayoría de las peticiones utiliza una fracción pequeña de ese límite. La generación de vistas previas y el ensamblado de cargas grandes son las operaciones que consumen el resto. Por eso hay que elegir conjuntamente el límite y el número de procesos secundarios.

Tampoco existe memoria compartida de la aplicación entre peticiones. Cada petición inicia de nuevo el framework: configuración, aplicaciones habilitadas, rutas y escuchas de eventos. OPcache conserva el bytecode compilado, por lo que se ejecuta en lugar de analizarse, y APCu (caché PHP alternativa) mantiene un pequeño almacén local de clave-valor en la memoria compartida. Por eso es importante la línea de la vista general de administración "No se ha configurado ninguna caché de memoria". Sin ella, las búsquedas que podrían resolverse desde la memoria consultan la base de datos en cada petición. Esa parte es de configuración. El modelo subyacente de un proceso por petición es arquitectónico.

Por qué muchos archivos pequeños ralentizan todo mucho antes de que lo haga el disco

Nextcloud mantiene los metadatos de cada archivo y carpeta en una sola tabla de base de datos, oc_filecache: ruta, hash de la ruta, tamaño, fecha de modificación, etag e identificador del almacenamiento. El listado de una carpeta es una consulta a esa tabla, no un readdir en el disco. Una escritura actualiza la fila del archivo y después propaga el nuevo tamaño y etag por cada carpeta principal hasta llegar a la raíz. Una carga implica una petición HTTP, varias instrucciones SQL y una actualización adicional por cada nivel de profundidad.

La transferencia también se realiza por archivo. El protocolo de sincronización es WebDAV (creación y control de versiones distribuidos en la web), y WebDAV mueve un archivo por petición. 400,000 archivos implican 400,000 peticiones, cada una con autenticación, inicialización del framework, comprobaciones de permisos y escrituras en la base de datos. Si cada una requiere 25 ms de tiempo del servidor, la sobrecarga por sí sola suma casi tres horas antes de contar un solo byte de carga útil. Tómelo como un cálculo, no como una prueba de rendimiento. La conclusión importante es esta: el coste depende del número de archivos, no de su tamaño.

Un almacenamiento más rápido ayuda en parte. Las lecturas y escrituras aleatorias pequeñas son precisamente el aspecto en el que el almacenamiento NVMe y SATA de una VPS difieren más, por lo que conviene usar NVMe en una instancia grande. Esto no elimina el coste por petición, porque ese coste corresponde a PHP y SQL, no al disco.

Hay una consecuencia que todo el mundo descubre tarde o temprano. Los archivos copiados al servidor fuera de Nextcloud no existen para Nextcloud, porque nunca se escribió su fila. Sólo aparecen después de que occ files:scan recorra el árbol y escriba las filas que faltan, y en un árbol grande ese análisis tarda mucho. Si no está seguro de dónde se encuentran esos archivos en una instalación en contenedor, la estructura del directorio de datos de Nextcloud en Docker se explica en otra guía. Esta guía es arquitectónica: la base de datos es el listado de archivos.

Por qué el cliente de escritorio se ralentiza con un árbol grande

El cliente de sincronización es más eficiente de lo que suele creerse. Cada escritura propaga un nuevo etag hasta la carpeta raíz. Por eso, el cliente puede hacer una sola consulta sencilla para saber si ha cambiado algo y después descender sólo por las carpetas cuyo etag sea diferente. Por tanto, la consulta periódica cuando está inactivo no es costosa por sí misma.

Los costes restantes son reales. La primera sincronización recorre todas las carpetas, envía una solicitud PROPFIND por carpeta y descarga todos los archivos. Un cambio de nombre cerca de la raíz modifica el etag de todo lo que está debajo. Por eso, el cliente vuelve a examinar todo ese subárbol. Además, el cliente mantiene su propia base de datos local y obtiene información de los archivos locales. Un disco lento en el equipo portátil o un antivirus con análisis intensivo añade retrasos que no tienen ninguna relación con el servidor.

Sin la aplicación Client Push, notify_push, cada cliente conectado consulta el servidor según un temporizador. Treinta clientes generan un flujo constante de solicitudes en segundo plano contra el mismo grupo de workers que atiende la interfaz web. notify_push es un servicio independiente pequeño que mantiene un websocket por cliente y les informa cuando cambia algo. Así se elimina la mayor parte de ese tráfico en estado inactivo. En una instancia con mucha actividad, es una de las mejoras con mayor impacto que puede añadir.

No existe ninguna combinación automática. Si dos personas editan el mismo archivo mientras están sin conexión, se crea una copia en conflicto con un nombre similar a budget (conflicted copy 2026-08-22 141530).ods. Una persona debe resolver el conflicto manualmente. Editar mediante un servicio de oficina evita este problema, porque en ese caso sólo una copia del servidor es la autorizada. Los archivos virtuales, que aparecen como marcadores de posición hasta que se abren, funcionan de forma estable en Windows y macOS, pero han tardado más en estabilizarse en Linux. Compruebe la versión del cliente antes de diseñar un flujo de trabajo que dependa de esta función. La consulta periódica es configuración. Una solicitud por archivo es arquitectura.

Qué deja sin configurar una instalación predeterminada

Una instalación nueva de Nextcloud funciona. En una instalación manual típica todavía faltan cuatro cosas, y las cuatro aparecen en Settings, Administration, Overview.

• No hay caché de memoria. La vista general muestra "No memory cache has been configured". APCu requiere muy pocos recursos y elimina un gran número de consultas repetidas a la base de datos.
• Bloqueo de archivos en la base de datos. Nextcloud bloquea un archivo mientras se escribe. Sin Redis, ese bloqueo se almacena en una tabla de la base de datos. Esto aumenta la carga de escritura y deja bloqueos obsoletos cuando una solicitud termina de forma inesperada. Los usuarios ven errores que indican que el archivo está bloqueado, y sólo una limpieza manual los elimina.
• Faltan índices en la base de datos. La vista general muestra "The database is missing some indexes" y menciona occ db:add-missing-indices. En un filecache con millones de filas, esos índices marcan la diferencia entre un listado rápido y uno lento.
• SQLite. Una instalación manual puede terminar usando SQLite, que la documentación recomienda sólo para pruebas e instancias pequeñas. Las escrituras se serializan, por lo que un segundo usuario activo ya es demasiado.

'memcache.local' => '\\OC\\Memcache\\APCu',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' => [
  'host' => 'localhost',
  'port' => 6379,
],

Nada de esto es exótico, y todo es configuración. Si prefiere empezar con una instalación en la que estas decisiones ya estén tomadas, la instalación con Docker, TLS y copias de seguridad inicia la caché y el contenedor de cron como parte del stack.

Por qué los trabajos en segundo plano se bloquean cuando cron no está configurado

Nextcloud delega el trabajo real en trabajos en segundo plano: generar vistas previas, caducar versiones antiguas de archivos, vaciar la papelera según un horario, enviar correos de notificación y limpiar recursos compartidos. Hay tres formas compatibles de ejecutarlos, y la predeterminada es la menos fiable.

El modo AJAX ejecuta un trabajo cuando un navegador carga una página. En una instancia personal que nadie visita durante una semana, no se ejecuta nada durante una semana. Las versiones y la papelera nunca caducan, por lo que el disco sigue llenándose con datos que el usuario cree haber eliminado. Las vistas previas nunca se generan por adelantado, así que la primera persona que abre una carpeta de fotos debe esperar mientras su propia petición las genera. Con el tiempo, el resumen indica que el último trabajo en segundo plano se ejecutó hace varias horas y que "Something seems wrong". Esa es la única advertencia que se muestra.

Webcron y system cron solucionan este problema. system cron ejecuta cron.php cada cinco minutos con el usuario del servidor web, y una instalación en un contenedor ejecuta lo mismo desde un contenedor cron dedicado. Cinco minutos es el intervalo que especifica la documentación, y los intervalos de los trabajos están ajustados a ese valor.

El coste restante es que los trabajos se ejecutan de forma serializada. Un trabajo largo, un lote de vistas previas o un análisis de archivos retrasa todo lo que está en cola detrás de él, y en una VPS de un solo núcleo esa ejecución compite con las peticiones activas. En un host con mucha carga, el tiempo de CPU robado por vecinos ruidosos alarga esas ejecuciones más de lo que predicen sus propias mediciones. Configuración, y la corrección con mayor impacto en la mayoría de las instancias desatendidas.

El consumo mínimo de memoria al añadir Office, Talk o las vistas previas

Nextcloud sin funciones adicionales es moderado: un grupo de procesos PHP, una base de datos, Redis y un servidor web. Una instancia pequeña funciona bien con 2 GB. Cada función que los usuarios suelen necesitar es un servicio independiente con su propio mínimo de recursos.

Vistas previas. De forma predeterminada, la vista previa se genera cuando se solicita por primera vez, por lo que el usuario espera dentro de la petición que la necesita. La aplicación Preview Generator traslada ese trabajo a cron, de modo que la espera se sustituye por consumo de CPU durante las ejecuciones de cron. En ambos casos, cada imagen original produce varios archivos de vista previa con distintos tamaños. Por tanto, una biblioteca de fotos multiplica el número de archivos y agrava directamente el problema de los archivos pequeños descrito arriba. Las imágenes originales grandes también son las que alcanzan el límite de memoria, como indica Allowed memory size of 536870912 bytes exhausted en el registro de errores de PHP. preview_max_x y preview_max_y no evitan ese problema: sólo establecen el tamaño de la vista previa almacenada más grande, y la imagen original se decodifica a tamaño completo antes de reducirla a ese tamaño. La opción que limita la imagen original es preview_max_memory, con 256 MB de forma predeterminada. Nextcloud lee las dimensiones de la imagen desde la cabecera del archivo, supone 4 bytes por píxel y omite cualquier imagen que necesite más memoria que ese límite. En su lugar, muestra el icono de archivo predeterminado. Según esta regla, una imagen de 20,000 por 20,000 píxeles necesita aproximadamente 1.6 GB, independientemente de lo pequeño que establezca el tamaño de la vista previa. preview_max_filesize_image, con 50 MB de forma predeterminada, es el límite equivalente para el tamaño del archivo. Mantenga preview_max_memory bastante por debajo del límite de PHP en lugar de aumentar ambos indefinidamente.

Office. Collabora Online y OnlyOffice Docs se ejecutan como servicios independientes, normalmente en contenedores separados, con su propio entorno de ejecución y su propia memoria. Las sesiones de documentos consumen CPU y RAM en esos servicios, no en PHP. Reserve uno o dos gigabytes antes de esperar un funcionamiento fluido y consulte los requisitos actuales del proveedor a fecha de agosto de 2026 antes de dimensionar el servidor. Las dos soluciones se diferencian en más aspectos que el consumo de recursos. OnlyOffice frente a Collabora para el alojamiento propio explica esas diferencias.

Talk. De forma predeterminada, las llamadas se realizan entre pares mediante WebRTC y el servidor sólo transmite mensajes de señalización. La configuración administrativa de Talk advierte que, en llamadas con más de dos participantes sin High Performance Backend, que es un servidor de señalización independiente, lo más probable es que los participantes experimenten problemas de conectividad y una carga elevada en sus dispositivos. Muchas redes también necesitan un servidor TURN (traversal using relays around NAT), como coturn. Como los flujos multimedia retransmitidos pasan por su VPS, el ancho de banda se convierte en un coste real.

Búsqueda de texto completo. Una instancia de Elasticsearch necesita al menos un gigabyte de memoria heap para sí misma antes de indexar ningún contenido.

¿Cuántos recursos necesita Nextcloud en un VPS?

Dimensionar sólo por el número de usuarios puede inducir a error, porque el comportamiento determina la carga. Cinco desarrolladores que sincronizan un árbol de código fuente con 300,000 archivos generan más carga que treinta personas que abren documentos en el navegador. Use estos valores como punto de partida y contrástelos con sus propios recuentos de archivos; no son mediciones.

• 1 vCPU y 1 a 2 GB: uno o dos usuarios, sólo archivos y calendario, con las vistas previas estrictamente limitadas y sin servicio de oficina. Las actualizaciones y un análisis completo de archivos serán las tareas más lentas que se ejecuten en el servidor.
• 2 vCPU y 4 GB: aproximadamente de 5 a 15 usuarios habituales, con APCu, bloqueo mediante Redis, cron del sistema y vistas previas generadas por cron.
• 4 vCPU y 8 GB: el mismo rango de usuarios con un servicio de oficina, o de 15 a 40 usuarios con poca carga sin ese servicio. Las sesiones de oficina son las que determinan el consumo de memoria en este caso.
• 4 o más vCPU y 16 GB: Talk con High Performance Backend, búsqueda de texto completo o generación masiva de vistas previas para una biblioteca de fotos.

El disco requiere un cálculo independiente. Las vistas previas, las versiones de archivos y la papelera se suman a los datos reales, y sólo disminuyen cuando los trabajos en segundo plano se ejecutan correctamente. Que el coste total sea inferior al de una suscripción depende de esas cifras, y el almacenamiento autogestionado frente al precio de Dropbox permite hacer ese cálculo.

Qué limitaciones de Nextcloud se deben a la configuración y cuáles son arquitectónicas

Se pueden corregir en una tarde: la caché de memoria y el bloqueo con Redis, los índices de base de datos que faltan, el modo de trabajos en segundo plano, el tamaño del grupo de procesos de FPM y el límite de memoria de PHP, el tamaño de OPcache, notify_push y los límites de generación de vistas previas. Una instancia con todo eso configurado es un software distinto de una instalación predeterminada, aunque use el mismo hardware.

Son permanentes, independientemente de los ajustes aplicados:

• Un proceso por petición. La concurrencia está limitada por la RAM y una petición lenta ocupa un worker durante toda su ejecución.
• Una fila de base de datos por archivo, con el tamaño y el etag propagados a cada directorio padre. El coste aumenta con el número de archivos.
• Una petición por archivo en la red. La sincronización de muchos archivos pequeños está limitada por la sobrecarga de las peticiones y no por el ancho de banda.
• Una plataforma de trabajo colaborativo que incluye una aplicación de archivos. La configuración base incluye componentes que una herramienta de sincronización pura nunca carga.
• Actualizaciones serializadas. Las versiones principales se aplican de una en una, en modo de mantenimiento, y en cada paso hay que resolver la compatibilidad de las aplicaciones.

Ninguno de estos puntos es un error. Son el coste de los enlaces compartidos, los colaboradores externos, los clientes móviles y un único sistema de cuentas para todo ello. Pagar la edición empresarial proporciona soporte y algunas aplicaciones adicionales, pero no cambia el modelo de peticiones descrito arriba. Ese es uno de los aspectos que explica qué incluye realmente la edición gratuita de Nextcloud.

Quién no debería ejecutar Nextcloud en un VPS

• Quiere sincronizar rápidamente un árbol grande entre varias máquinas y nada más. Una herramienta peer-to-peer no mantiene una fila por archivo en la base de datos de una aplicación web, por lo que el coste de los archivos pequeños es completamente distinto: Syncthing comparado con Nextcloud para una sincronización básica.
• Quiere compartir archivos y tener una interfaz web, pero sus datos constan de millones de archivos pequeños. Seafile almacena el contenido en un almacén de bloques en lugar de usar un archivo por cada archivo, lo que cambia ese cálculo. La contrapartida es que los datos dejan de ser archivos normales en el disco: Seafile frente a Nextcloud.
• Sólo quiere ver en un navegador los archivos que ya están en el servidor, sin cliente de sincronización ni filas por archivo en una base de datos delante de ellos. Para eso sirven los gestores de archivos autoalojados más ligeros.
• Su requisito real es una unidad compartida para cuatro personas. Empiece con una solución más ligera y añádale funciones después: las alternativas autoalojadas a Nextcloud.
• Tiene 1 vCPU y 1 GB, y quiere editar documentos desde el navegador. Esa combinación no es adecuada y ningún ajuste puede hacerla viable.

Ejecute Nextcloud cuando necesite funciones de groupware: compartir con personas ajenas a su organización, calendario y contactos en todos los teléfonos, edición desde el navegador y un único inicio de sesión para todo. El fallo se produce de forma gradual, no de golpe. El número de archivos aumenta, la instalación sigue sin caché ni cron y, un día, una carpeta tarda ocho segundos en abrirse. Todo eso se puede medir y, en la mayoría de los casos, corregir antes de que empiece.

FAQ

¿Cuántos usuarios puede admitir un VPS de Nextcloud?

El comportamiento del sistema influye más que el número de usuarios. Un servidor ajustado con 2 vCPU y 4 GB admite cómodamente aproximadamente entre 5 y 15 usuarios habituales que trabajan con archivos, calendario y contactos. Añadir un servicio de oficina suele requerir 8 GB. Normalmente, el primer límite que se alcanza es el número de procesos de PHP en relación con la RAM disponible, o la base de datos cuando oc_filecache es grande. Por eso, pruebe con sus propios volúmenes de archivos antes de fijar el tamaño del plan.

¿Por qué Nextcloud es lento con muchos archivos pequeños?

Porque cada archivo corresponde a una fila de la base de datos y a una solicitud WebDAV independiente. Mostrar el contenido de una carpeta ejecuta una consulta SQL, escribir un archivo actualiza su fila y el tamaño y el etag de cada carpeta padre, y transferirlo mueve un archivo por solicitud HTTP, con autenticación y la inicialización del framework en cada ocasión. Por tanto, el coste depende del número de archivos y no del tamaño total. Un almacenamiento más rápido reduce la parte correspondiente al disco, pero la parte asociada a cada solicitud permanece.

¿Necesito Redis para Nextcloud?

Para un solo usuario, no. Para cualquier instalación multiusuario, sí. Sin Redis, el bloqueo transaccional de archivos se gestiona mediante una tabla de la base de datos. Esto aumenta la carga de escritura y deja bloqueos obsoletos cuando una solicitud termina de forma anómala. Como consecuencia, los usuarios ven errores que indican que el archivo está bloqueado. La configuración habitual usa APCu para la caché local y Redis para los bloqueos. Ambos se configuran en config.php.

¿Qué ocurre si nunca configuro las tareas en segundo plano de Nextcloud?

El modo AJAX predeterminado ejecuta una tarea por cada carga de página. Por tanto, no se ejecuta nada mientras no haya ningún usuario conectado. Las vistas previas no se generan de antemano, las versiones de archivos y la papelera nunca caducan y el disco sigue llenándose. Además, dejan de enviarse los correos de notificación. Con el tiempo, el resumen de administración indica que la última tarea en segundo plano se ejecutó hace varias horas y que parece haber un problema. La solución es cambiar a system cron cada cinco minutos. En una instalación en contenedores, una instancia de cron dedicada realiza esta tarea.