Nextcloud autoalojado en un VPS: sustituir Google Drive por un servidor que controlas tú

Qué estás sustituyendo realmente, y qué no

Nextcloud es, despojado de su marketing, una aplicación PHP que mantiene una base de datos de metadatos de archivos y un directorio con el contenido de esos archivos, y habla suficientes protocolos como para que los dispositivos normales la traten como una cuenta en la nube cualquiera. Esa descripción se queda corta con lo mucho de tu vida digital que en realidad cubre. La sincronización de archivos es la parte visible, y es la parte por la que la gente la instala. Las partes que resultan importar seis meses después son las que nadie enseña en una demo: calendarios y contactos por CalDAV y CardDAV, para que las aplicaciones nativas de tu teléfono dejen de hablar con un proveedor de correo; una biblioteca de fotos con subida automática desde la cámara, que es lo que realmente saca a una familia de Google Photos; y notas, tareas y marcadores que ya no están repartidos entre cuatro cuentas que no controlas.

Merece la pena ser precisos con la comparación, porque el planteamiento habitual está equivocado. Nadie se autoaloja para ahorrar dinero en gigabytes — un plan de consumidor con dos terabytes cuesta más o menos lo mismo que un VPS de gama media y no da ningún trabajo. Te autoalojas porque la alternativa es una relación en la que la contraparte guarda los datos, pone las condiciones, escanea el contenido para comprobar el cumplimiento de sus políticas, y tramita requerimientos legales sobre ti sin ninguna obligación de avisarte antes. Eliminar a esa contraparte es el producto entero. Todo lo demás es un efecto secundario, parte de él agradable y parte de él tu nueva responsabilidad.

Lo que no obtienes, y no deberías esperar, es el suelo operativo invisible que un hyperscaler proporciona gratis. No hay replicación multirregión a menos que la construyas tú. No hay una red de borde que haga rápida una descarga grande desde el otro lado del planeta. No hay una cola de soporte que encuentre tu archivo cuando lo borras y vacías la papelera la misma tarde. Cuando el disco se llena a las tres de la madrugada, los clientes de sincronización de cinco dispositivos empezarán a mostrar iconos rojos, y la persona que lo arregla eres tú. Esto no es un argumento en contra de hacerlo — es la descripción del trabajo que estás aceptando.

Lo último con lo que hay que ser realista es el ritmo de actualizaciones. Nextcloud publica versiones mayores varias veces al año, las actualizaciones hay que aplicarlas de una versión mayor en una, y las aplicaciones de terceros de las que has llegado a depender a veces se quedan un poco atrás. No es un trabajo difícil, y el actualizador integrado más una instantánea previa lo convierten en una tarea de quince minutos, pero es trabajo recurrente y con fecha límite: una instancia tres versiones mayores por detrás es una instancia que no puedes actualizar en un solo paso ni tampoco puedes exponer con seguridad a internet.

La máquina: dimensionar para un servidor de archivos, no para un sitio web

La mayoría de las guías de autoalojamiento dimensionan un servidor según su aplicación. En este caso la aplicación es casi irrelevante y la biblioteca lo es todo. El proceso de PHP, el servidor web, la base de datos y la caché juntos caben cómodamente en uno o dos gigabytes de RAM bajo una carga doméstica; lo que decide tu plan es cuántos bytes vas a poner en el disco y en cuántos archivos individuales se reparten esos bytes, que son dos restricciones separadas que fallan de dos formas distintas.

Empieza por el inventario honesto en lugar del aspiracional. Los documentos y las hojas de cálculo son ruido — una década de ellos rara vez supera los diez gigabytes. El carrete de fotos no es ruido: un teléfono moderno produce entre quince y cuarenta gigabytes al año por persona una vez incluido el vídeo, y activar la subida automática para una familia de cuatro es comprometerse a aproximadamente cien gigabytes anuales que llegan pienses en ello o no. Luego añade un margen sobre la biblioteca en bruto: vistas previas generadas para imágenes y vídeo, versiones de archivos guardadas para documentos editados, y una papelera que por defecto conserva los archivos eliminados hasta treinta días y cuenta contra el mismo disco. Una cifra de trabajo de la biblioteca más un veinte por ciento es realista, y ese veinte por ciento es la parte que la gente olvida hasta que el disco está al noventa y cinco.

La memoria es la segunda restricción y es mucho más barata de satisfacer. Cuatro gigabytes hacen funcionar una instancia de un solo usuario sin dramas. Ocho es la cifra cómoda para un hogar o un equipo pequeño, porque te permite darle a PHP-FPM suficientes workers para absorber a varios clientes de sincronización despertando a la vez, darle a la base de datos un buffer pool de verdad, y aun así dejar espacio para que la caché de páginas del sistema operativo mantenga en memoria los metadatos calientes. La cifra solo cambia de forma relevante si añades Nextcloud Office, que ejecuta un motor completo de conversión de documentos en su propio contenedor y quiere de dos a cuatro gigabytes para sí mismo antes de que nadie abra una hoja de cálculo.

La CPU apenas se nota en régimen estable y luego importa muchísimo durante aproximadamente una semana. Generar vistas previas para una biblioteca de fotos ya existente es lo más pesado que hará este servidor — cada imagen se decodifica y se recodifica en varios tamaños — y en un plan pequeño esa pasada inicial puede tardar días. Después, servir archivos es casi gratis: el trabajo es de E/S, y la locuacidad del protocolo de sincronización cuesta más en idas y vueltas que en ciclos de CPU. Compra núcleos para la importación, no para la instancia ya en marcha, y si la importación es el único motivo por el que subirías de plan, ejecútala en un plan mayor durante un mes y luego vuelve a bajar. La facturación mensual sin contrato es precisamente lo que hace barata esa maniobra.

Esa última fila es la que merece leerse dos veces, porque es donde la gente se equivoca con el perfil de la máquina. Un VPS es excelente como centro de sincronización y uso compartido para el conjunto de trabajo que toca un grupo de personas. Es un mal contenedor para un archivo multimedia: el plan más grande que vendemos topa en seiscientos cuarenta gigabytes de NVMe local, y en cuanto tu biblioteca se mide en terabytes la respuesta correcta es el hardware dedicado, donde un par de discos en espejo te da uno o dos terabytes con redundancia por debajo. Decidir eso antes de empezar es mucho menos doloroso que mover una instancia ya poblada después de haberte quedado sin espacio.

La decisión de base de datos que tomas una sola vez

El instalador te ofrecerá SQLite y funcionará. Úsalo para una demostración que tengas intención de borrar, y para nada más. SQLite serializa las escrituras en toda la base de datos, y esta aplicación escribe constantemente — cada sondeo de un cliente de sincronización, cada archivo escaneado, cada entrada de actividad — así que en cuanto hay dos clientes activos las peticiones se ponen en cola una detrás de otra y la interfaz adquiere un retraso que ningún ajuste elimina. Los requisitos oficiales lo dicen, con educación.

MariaDB y PostgreSQL son ambos de primera categoría y elegir entre ellos es casi una cuestión de gustos. MariaDB es lo que ejecutan la mayoría de los despliegues y lo que asumen la mayoría de las respuestas de la comunidad, lo cual vale algo cuando estás buscando un mensaje de error a medianoche; necesita que la base de datos se cree con el juego de caracteres UTF-8 de cuatro bytes para que los emoji en los nombres de archivo no trunquen una fila, y quiere su aislamiento de transacciones puesto en read-committed, algo que la documentación indica con claridad y que la gente se salta. PostgreSQL es discretamente mejor bajo concurrencia y necesita menos ajustes finos, a costa de un fondo algo más pequeño de respuestas para copiar y pegar. Cualquiera de las dos es correcta; ejecutar la que ya sabes cómo respaldar es más correcto que cualquiera de ellas.

Ponla en la misma máquina y conéctate mediante un socket unix. Este es uno de los pocos sitios donde la arquitectura obvia es también la correcta: una instancia única no gana nada con una base de datos en otro host y pierde una ida y vuelta de red en cada una de las muchas consultas pequeñas que hace la aplicación. Vincula la base de datos a la interfaz de loopback, nunca a la pública — la checklist de hardening explica por qué una base de datos escuchando en la red es, con diferencia, la forma más habitual en que le arrebatan un servidor pequeño a su dueño.

Lo que hay que entender sobre esta base de datos es que es pequeña en bytes y enorme en consecuencias. Su tabla central guarda una fila por archivo y por usuario — cien mil archivos repartidos entre cuatro cuentas son unos cientos de miles de filas, que no son nada para un motor moderno, y unos cientos de megabytes en disco. Pero esa tabla es lo único que conoce la estructura de tus datos. Pierde la base de datos y conserva los archivos, y te quedas con un árbol de directorios sin recursos compartidos, sin versiones, sin comentarios, sin etiquetas y sin estado de sincronización. El reescaneo por línea de comandos reconstruirá a partir de eso un árbol utilizable, lo cual es un auténtico alivio la primera vez que lo necesitas, pero no traerá de vuelta ni un solo enlace compartido ni el historial de versiones. Respalda las dos cosas juntas, siempre, y trata una copia de seguridad de una sin la otra como si no fuera ninguna copia de seguridad.

Por qué la instalación por defecto se siente lenta — y las cuatro opciones que lo arreglan

Una instancia recién instalada suele describirse como lenta, y quienes la describen así no se equivocan. No es el hardware ni es PHP: son cuatro ajustes de fábrica elegidos para la máxima compatibilidad en un hosting compartido, no para una máquina que controlas tú. Cambiarlos lleva veinte minutos y produce, sin comparación, la mayor mejora percibida que nadie hará jamás en esta instalación.

El primero son las tareas en segundo plano. De serie funcionan en modo AJAX, lo que significa que la cola solo avanza cuando un humano carga una página en un navegador — así que no se generan vistas previas, la papelera no caduca, los recursos compartidos federados no se actualizan y los índices de búsqueda no se construyen hasta que a alguien le da por visitar la instancia. Cambia a una entrada de cron del sistema que ejecute el gestor de tareas cada cinco minutos como el usuario del servidor web, exactamente como describe la documentación de tareas en segundo plano. La mitad de las quejas misteriosas de «esto no hace nada» sobre Nextcloud son este ajuste.

El segundo es la caché y el bloqueo de archivos. Sin una caché compartida, la aplicación relee constantemente la configuración y los metadatos de las apps, y sin bloqueo transaccional de archivos respaldado por Redis recurre a bloquear filas en la base de datos, que es precisamente donde no quieres contención. Instala Redis, haz que escuche en un socket unix en lugar de un puerto TCP para que nada en la red pueda alcanzarlo, y dirige tanto la caché distribuida como el backend de bloqueo de archivos hacia él, dejando la caché local rápida en APCu. La referencia de configuración de caché da el bloque exacto.

El tercero es la caché de opcode de PHP. Los tamaños de buffer de fábrica se calcularon para una aplicación pequeña, y esta no lo es — el resumen de administración te dirá directamente que el buffer de cadenas internadas está casi lleno, y un buffer lleno significa que el intérprete hace trabajo evitable en cada petición. Subir la memoria del opcache y el buffer de cadenas internadas, y elevar el máximo de archivos acelerados muy por encima del valor por defecto, cuesta un par de cientos de megabytes de RAM y se nota de inmediato en cada carga de página. El cuarto es el gestor de procesos de PHP-FPM: el número de procesos hijo por defecto está ajustado para una máquina con muchísima menos memoria que la tuya, y un hogar con varios clientes de sincronización hará cola detrás de él. Dimensiona el número de workers según tu RAM real y la huella por worker, que es el único cálculo de esta sección que merece la pena hacer sobre el papel.

Hay una trampa relacionada que merece su propio párrafo porque produce un síntoma confuso. Subir un archivo grande por la interfaz web falla, mientras que ese mismo archivo se sube sin problemas desde el cliente de escritorio. Eso no es un fallo: el cliente de escritorio divide las subidas en fragmentos y los reensambla en el servidor, así que se cuela por debajo de todos los límites, mientras que el navegador envía una única petición grande que tiene que sobrevivir a los límites de subida y de tamaño de post de PHP, al tamaño máximo de cuerpo propio del servidor web, y a cualquier timeout intermedio. Si el navegador es por donde entran los archivos grandes a tu instancia, todos esos valores hay que subirlos juntos — subir uno y no los demás solo cambia qué componente es el que dice que no.

Tres cosas distintas se llaman cifrado, y protegen frente a tres personas distintas

Esta es la sección donde la mayoría de los despliegues autoalojados se equivocan, y se equivocan de una forma comprensible: tres funciones sin relación entre sí comparten una palabra, la interfaz de administración las ofrece todas, y activar más suena más seguro que activar menos. No lo es. Cada una defiende frente a un adversario específico, cada una cuesta algo, y una de las tres es activamente perjudicial cuando se aplica al caso al que la gente suele aplicarla.

El cifrado de disco completo es la capa que está debajo de todo. Protege los datos en una máquina apagada — un disco sacado de un rack, una unidad dada de baja, una imagen copiada desde almacenamiento en frío. No hace absolutamente nada mientras el servidor está en marcha, porque el volumen está desbloqueado y el sistema operativo lo lee como archivos normales. Es barato, es invisible, no tiene efecto sobre ninguna función de Nextcloud, y no hay ninguna buena razón para no tenerlo. Lo que exige es un plan de desbloqueo remoto, porque un servidor que reinicia a las cuatro de la madrugada se queda caído hasta que alguien teclea una frase de contraseña; la guía de cifrado de disco completo cubre la configuración de SSH en initramfs que hace eso sobrevivible.

El cifrado del lado del servidor es el que exige pensar más. Cifra el contenido de los archivos con claves que residen en el mismo servidor, gestionadas por la misma aplicación, y su propósito real de diseño es proteger datos que colocas en un almacenamiento que pertenece a otra persona — un almacén de objetos, un montaje externo alquilado, un backend de terceros. Aplicado al almacenamiento principal local de una máquina que ya controlas, te protege de bien poco, ya que cualquiera que pueda leer los archivos puede leer las claves; y te cuesta aproximadamente un tercio más de almacenamiento, complica todos los escenarios de recuperación, y desactiva funciones que necesitan leer el contenido de los archivos. La documentación de cifrado es inusualmente directa sobre esta contrapartida. Si tu almacenamiento es NVMe local en un servidor que alquilas tú solo, déjalo desactivado y usa en su lugar la capa de disco.

El cifrado de extremo a extremo es el de verdad, y es el único de los tres que te protege frente al servidor. Los archivos de una carpeta de extremo a extremo se cifran en el cliente antes de salir del dispositivo, y el servidor almacena texto cifrado que no puede abrir — que es exactamente lo que quieres para el pequeño subconjunto de material en el que obligar al proveedor no debe producir datos legibles. El precio es severo y no negociable: esas carpetas no tienen interfaz web, ni búsqueda del lado del servidor, ni miniaturas, ni compartición pública, ni recuperación si pierdes la frase mnemotécnica que las desbloquea. Eso no es una limitación que haya que sortear con ingenio, es la definición misma de la garantía. Úsalo para la carpeta que de verdad lo necesita y deja la biblioteca de fotos familiares fuera, donde las vistas previas funcionan y la vida es agradable.

Los clientes, y las partes que de verdad usan otras personas

Que este proyecto tenga éxito lo deciden casi por completo personas que nunca van a entrar en el servidor, y su veredicto se forma en la primera semana gracias a tres piezas de software. El cliente de escritorio es el que más importa. Configúralo con archivos virtuales en lugar de una copia local completa — los archivos aparecen en el gestor de archivos, no ocupan espacio hasta que se abren, y se descargan bajo demanda — porque eso es lo que hace que una biblioteca de doscientos gigabytes sea manejable en un portátil con un disco pequeño, y es el comportamiento que la gente ya espera de los clientes comerciales.

La aplicación móvil trae la función que convierte a los escépticos: la subida automática del carrete de fotos. Actívala para la gente de tu hogar, apúntala a una carpeta por usuario, y en un mes se habrá acabado la discusión sobre dejar Google Photos. También es, y exactamente por la misma razón, lo que va a llenar tu disco según un calendario que tú no elegiste, por lo que la sección de dimensionamiento de más arriba dedica su tiempo a las cámaras y no a los documentos. Pon una cuota por usuario desde el principio — no porque tengas intención de hacerla cumplir, sino porque una cuota convierte quedarse sin disco en silencio en un mensaje claro en el teléfono de alguien.

Los calendarios y los contactos son la victoria silenciosa y lo que más a menudo se queda a medio configurar. Nextcloud habla CalDAV y CardDAV, que todo teléfono y todo escritorio soportan de forma nativa, así que nadie necesita una app nueva — pero el descubrimiento depende de un par de redirecciones en /.well-known/caldav y /.well-known/carddav que viven en la configuración de tu servidor web y no en la aplicación. Si las configuras mal, la configuración de la cuenta falla con un error nada útil en iOS mientras funciona bien en Android. El resumen de administración señala esto explícitamente, una razón más para vaciar esa página antes de que llegue nadie más.

Dos notas más pequeñas ahorran tiempo de verdad. El montaje por WebDAV está soportado y es realmente cómodo para un acceso ocasional desde una máquina en la que no quieres instalar nada; también es lento, porque cada operación es una ida y vuelta HTTP, así que es una mala opción como directorio de trabajo y una buena opción para coger un archivo suelto. Y crea una contraseña de aplicación para cada dispositivo en lugar de repartir la contraseña de la cuenta: revocar un teléfono perdido significa entonces borrar un token en lugar de cambiar una contraseña y volver a autenticar todos los demás clientes que tienes. Combina eso con la autenticación de dos factores en las cuentas, y mantén una cuenta de administrador que nadie usa el día a día separada de la cuenta con la que realmente sincronizas.

Donde la jurisdicción deja de ser una abstracción

Para la mayoría de las cosas que podrías autoalojar, la ubicación de la máquina es una decisión de latencia con una nota legal al margen. Para todo tu archivo de documentos, tus fotografías, tus contactos y tu calendario, la prioridad se invierte — esta es la única máquina donde la cuestión legal pesa más que la de red, porque los datos que contiene son precisamente el tipo de cosa para la que se emiten los requerimientos legales.

Entiende qué cambia cuando te sales de un hyperscaler. Cuando tus archivos viven con un proveedor grande, un requerimiento sobre ellos se notifica a ese proveedor, se evalúa en su departamento legal contra sus propios intereses, y se cumple bajo una orden de mordaza más a menudo de lo que crees — puede que nunca llegues a saber que ocurrió. Cuando los archivos viven en un servidor que alquilas tú, no existe tal departamento ni tal reflejo, y el requerimiento tiene que encontrar a alguien. Eso no es un escudo mágico; es un cambio estructural en a quién se le pregunta, cuán visible es la pregunta, y cuánta fricción hay entre una solicitud y una copia de tus datos. Nuestro explicador legal repasa en qué consiste esa fricción y en qué no.

De aquí se siguen dos consecuencias prácticas. La primera es que la jurisdicción debería elegirse a propósito y no por reflejo de latencia — la comparación de jurisdicciones y la nota sobre el acuerdo de los 14 Eyes exponen en qué difieren las cuatro ubicaciones, y para un archivo personal la respuesta suele ser el suelo legal más sólido cuyo tiempo de ida y vuelta puedas tolerar. La segunda es que al proveedor solo se le puede obligar a entregar aquello a lo que puede llegar, por lo que las capas de cifrado de más arriba no son decoración: cifrado de disco completo más cifrado de extremo a extremo en las carpetas que lo necesitan significa que la respuesta honesta a un requerimiento es una imagen de disco llena de texto cifrado.

Existe una contrapartida de latencia y es más pequeña de lo que la gente teme. La sincronización es un proceso en segundo plano — nadie se queda mirando cómo se sube una foto — así que cien milisegundos extra de ida y vuelta no te cuestan nada perceptible en lo que haces todo el día. Donde se nota es al abrir un documento en el editor web o al desplazarte por una galería grande, que es interactivo y donde esos mismos cien milisegundos se sienten en cada acción. Si las personas están en Europa, Ámsterdam o Zúrich mantiene rápidas las dos experiencias; si la postura legal es todo el objetivo, Reikiavik te cuesta una cantidad perceptible pero tolerable de capacidad de respuesta interactiva y nada en absoluto en la sincronización.

Merece la pena decir claramente una obligación, porque el autoalojamiento te la transfiere calladamente. En el momento en que hay archivos de otras personas en tu servidor — las fotografías de un familiar, los documentos de un colega, los contratos de un cliente — te has convertido en la parte responsable de ellos, y en Europa esa responsabilidad tiene un nombre y lleva aparejado un conjunto de obligaciones. No es gravoso a escala doméstica y no es algo que conviene descubrir en mitad de una discusión: decide quién tiene acceso a qué, dile a las personas dueñas de esos datos dónde viven, y mantén la cuenta de administrador fuera del uso cotidiano para que leer la carpeta de otra persona sea un acto deliberado y no un accidente.

Las copias de seguridad, y la restauración que tienes que ensayar

Hay exactamente tres cosas que preservar y las tres deben proceder del mismo instante: el directorio de datos, que contiene el contenido de los archivos, la base de datos, que contiene cada fragmento de metadatos sobre ellos, y config.php, que contiene el identificador de la instancia, las credenciales de la base de datos y — si activaste el cifrado del lado del servidor — los valores sin los cuales el resto es ilegible. Copia dos de tres y tienes un ejercicio arqueológico interesante en lugar de una restauración.

La coherencia es la parte fácil de estropear sutilmente. Un archivo copiado mientras se está escribiendo la base de datos produce una copia de seguridad cuyas dos mitades no coinciden, y la discrepancia aflora semanas después en forma de archivos que existen en el disco pero no en la interfaz, o entradas en la interfaz que no apuntan a nada. La solución sencilla es poner la instancia en modo de mantenimiento, volcar la base de datos, capturar el directorio de datos, y desactivar el modo de mantenimiento — lo cual es una interrupción corta que nadie nota a las cuatro de la madrugada. La documentación de copias de seguridad detalla la secuencia, y una instantánea del sistema de archivos tomada con la aplicación en pausa consigue lo mismo en menos tiempo si tu almacenamiento admite instantáneas.

Luego envíala a otro sitio, cifrada antes de salir. Restic y Borg cifran ambos en el cliente y deduplican bien contra un conjunto de datos que cambia por los bordes, que es la forma que tiene un servidor de archivos. Haz que el repositorio remoto sea de solo anexado para que un host comprometido no pueda borrar su propio historial — eso es lo que convierte una copia de seguridad en una defensa contra el ransomware y no solo contra un disco averiado — y pon el extremo lejano en una jurisdicción distinta de la del extremo cercano, ya que una copia que se puede incautar en la misma acción que el original no es realmente una segunda copia. Guarda la frase de contraseña del repositorio en algún sitio que no sea el servidor.

Merece la pena nombrar las dos funciones que la gente confunde con copias de seguridad. Las versiones de archivos y la papelera son comodidades que viven dentro de la misma instancia, en el mismo disco, en la misma base de datos; recuperan de maravilla una sobrescritura accidental y no sobreviven absolutamente nada de lo que le pase al servidor. Del mismo modo, las instantáneas horarias del proveedor — que todos los planes de aquí incluyen con siete días de retención — son excelentes para deshacer una mala actualización y no son una copia de seguridad externa, porque comparten el destino de la infraestructura sobre la que están. Usa las tres. Confía en la que está en otro sitio.

Por último, ensaya la restauración, una vez, mientras todo va bien. Aprovisiona un servidor desechable, restaura en él la base de datos y el directorio de datos, corrige la entrada de dominio de confianza en config.php, e inicia sesión. Vas a descubrir algo — un módulo de PHP que falta, un usuario de base de datos que nunca anotaste, una clave de cifrado que vivía en algún sitio que olvidaste — y lo vas a descubrir una tarde en la que te cuesta una hora, en lugar del día en que te cuesta el archivo entero. Si la restauración también necesita un reescaneo de archivos para reconciliar el árbol, para eso está la herramienta de línea de comandos, y saberlo de antemano es todo el sentido del ejercicio.

Compartir hacia fuera sin filtrar hacia dentro

La función que hace que esto sea genuinamente útil para otras personas es también la que pone una URL de tus archivos en la internet pública, así que merece cinco minutos de configuración deliberada en lugar de los valores por defecto. Los enlaces públicos deberían llevar contraseña y caducidad como cuestión de política, no como una decisión por enlace — ambas cosas se pueden forzar para toda la instancia, lo que significa que el ajuste lo haces tú una vez en lugar de que alguien lo olvide cada vez. Las carpetas de solo subida son el caso infravalorado: un enlace que acepta archivos sin revelar lo que ya hay en la carpeta sustituye a cualquier incómodo flujo de adjuntos por correo que tengas ahora mismo.

Detrás de un proxy inverso — que es como casi todo el mundo ejecuta esto — un valor de configuración causa una cantidad desproporcionada de confusión. Si a la aplicación no se le dice qué direcciones debe considerar de confianza como proxies, cada petición parece originarse en el propio proxy. La limitación de tasa entonces cuenta al mundo entero como un solo visitante, la protección contra fuerza bruta acaba limitando esa única dirección, y el efecto es una instancia que misteriosamente se ralentiza o bloquea a usuarios legítimos mientras los registros muestran que todo lo hace una sola IP. Configurar la lista de proxies de confianza y la anulación de protocolo, tal como describe la documentación de proxy inverso, arregla los registros y la protección con una línea cada uno.

La lista de dominios de confianza es el otro valor que merece la pena entender en lugar de copiar. Es una lista de admitidos de los nombres de host en los que responderá la instancia, y existe porque la aplicación construye URL absolutas — enlaces de restablecimiento de contraseña, enlaces compartidos, callbacks de federación — a partir de la cabecera host que recibe. Dejarla abierta es una forma bien conocida de conseguir que tus propios enlaces apunten a otro sitio. Añade los nombres de host que realmente usas, incluida la dirección onion si publicas una, y nada más.

Si parte de esto no debería ser alcanzable en absoluto desde la internet abierta, no lo resuelvas con una regla de firewall y buenas intenciones. Existen dos respuestas limpias: poner la instancia detrás de un túnel WireGuard para que solo sea alcanzable desde dispositivos que tengan una clave, lo cual funciona bien para un archivo personal y mal para compartir con gente de fuera; o publicarla como servicio onion junto al nombre de host de clearnet, lo que mantiene funcionando los clientes de sincronización sobre Tor sin exponer ninguna dirección en absoluto. Las dos son aditivas — puedes ejecutar cualquiera de ellas junto a un nombre de host público normal y dejar que el material sensible viva detrás de la vía privada.

Cuándo no deberías autoalojar esto

Una guía que nunca dice esto está vendiendo algo, así que aquí está la lista. Si los datos pertenecen a una empresa cuyas operaciones se paran cuando lo hace el servidor de archivos, estás suscribiendo una garantía de disponibilidad con una sola máquina y la atención de una sola persona, y un único VPS no es el instrumento adecuado para eso. La alta disponibilidad para esta aplicación es genuinamente compleja — almacenamiento compartido, una base de datos replicada, un balanceador de carga que entienda las sesiones persistentes — y si la necesitas, necesitas un presupuesto y una segunda persona, no un plan más grande.

Si nadie va a hacer el mantenimiento mensual, no empieces. El trabajo es pequeño — aplicar actualizaciones, echar un vistazo al resumen de administración, confirmar que la copia de seguridad se ejecutó, actualizar una versión mayor cada vez que sale una nueva — pero no perdona que te lo saltes durante un año. Una instancia varias versiones mayores por detrás no se puede actualizar en un solo paso y no debería estar de cara a internet mientras tanto, y salir de esa posición es más trabajo del que habría sido el mantenimiento.

Si tu biblioteca se mide en terabytes y sigue creciendo, lo que falla es la forma, no el tamaño. Ningún plan de VPS que vendemos llega a un terabyte de NVMe local, y acoplar almacenamiento de objetos a la parte trasera de la instancia desplaza el problema en lugar de resolverlo: la base de datos se vuelve todavía más crítica, la latencia en cada operación de archivo sube, y has reintroducido calladamente a un tercero en un diseño cuyo propósito entero era eliminar uno. Compra hardware dedicado con discos en espejo, o acepta que el archivo y el centro de sincronización son dos sistemas distintos.

Y si lo que realmente quieres es Google Docs — treinta personas escribiendo en la misma hoja de cálculo con cursores que se actualizan en menos de un segundo — sé honesto contigo mismo: el stack ofimático autoalojado es bueno, no equivalente, y quiere su propia memoria y su propia CPU. Ejecútalo porque quieres los documentos en tu propio disco, no porque esperes que la colaboración se sienta idéntica.

Para todos los demás — un hogar cansado de pagar alquiler por sus propias fotografías, un equipo pequeño que preferiría no tener sus contratos indexados por una empresa con departamento de políticas, una persona que simplemente quiere que sus archivos estén en un lugar que ella eligió — esto es una de las cosas más gratificantes que puedes poner en un servidor. El software es maduro, los clientes son buenos, los modos de fallo están documentados, y el único genuinamente implacable es la copia de seguridad que nunca se probó. Un servidor tarda alrededor de un minuto en aprovisionarse, las vistas previas se seguirán generando mientras terminas de configurar los teléfonos, y puedes pagarlo con la misma postura de privacidad por la que lo estás comprando.