Nuevo conjunto de datos revela el uso real de recursos en reposo para aplicaciones autoalojadas

SelfHost Atlas ha publicado un nuevo conjunto de datos abierto que ofrece mediciones del consumo de recursos de cientos de aplicaciones autoalojables. Publicado en octubre de 2026, este registro documenta la huella real de memoria y disco en reposo del software instalado en servidores limpios y nuevos, siguiendo la documentación oficial. Los datos sirven como una comprobación de la realidad para desarrolladores y administradores de sistemas que necesitan dimensionar su infraestructura basándose en el comportamiento observado y no en mínimos teóricos.

Qué ocurrió

El conjunto de datos, alojado en GitHub bajo licencia CC BY 4.0, contiene registros de 256 aplicaciones. Cada entrada representa una ejecución de instalación verificada donde se siguieron de principio a fin las instrucciones de instalación publicadas por el proyecto en una máquina virtual efímera de la nube. El proceso captura si la instalación tuvo éxito, qué sistema operativo se utilizó y la fecha de la verificación. Crucialmente, también registra el uso de recursos inmediatamente después del primer arranque, proporcionando una línea base sobre lo que consumen estas aplicaciones cuando no están bajo carga.

La metodología se basa en un entorno estricto que elimina todos los contenedores, volúmenes y cachés de compilación entre cada prueba. Esto garantiza que las cifras de disco y memoria pertenezcan exclusivamente a la aplicación probada, sin contaminación de ejecuciones anteriores. Las mediciones incluyen la suma de memoria reportada por Docker stats para todos los contenedores en ejecución treinta segundos después del inicio, así como el espacio total en disco utilizado por imágenes, contenedores y volúmenes. Estas cifras se acompañan de metadatos sobre la configuración específica de la máquina utilizada para la prueba, como el tipo de instancia y la versión del SO.

Un aspecto significativo de este lanzamiento es la distinción entre los valores medidos y las recomendaciones documentadas. El conjunto de datos incluye tanto la RAM ociosa observada como la RAM mínima sugerida por el proyecto original o los editores de atlas. En muchos casos, estos números difieren sustancialmente. Por ejemplo, algunos gestores de contraseñas documentan la necesidad de 256 MB de RAM pero en reposo solo usan 7 MB. A la inversa, herramientas de gestión de fotos pueden recomendar 2 GB pero consumir aproximadamente 100 MB en reposo. Esta discrepancia resalta la brecha entre márgenes de seguridad conservadores y los costos operativos reales.

Detalles clave

• El conjunto de datos incluye 256 registros, disponibles en formatos JSON y CSV, con un DOI para citación.
• Las mediciones capturan el uso de RAM y disco en reposo en un servidor limpio y recién purgado inmediatamente después de la instalación.
• La verificación de instalación confirma que la documentación oficial funciona en versiones específicas del SO, registrando éxito o fallo.
• La RAM mínima documentada está claramente separada de la RAM ociosa medida para evitar confusiones entre recomendaciones y observaciones.
• El uso de CPU, el tiempo de instalación y el esfuerzo de mantenimiento no están incluidos en esta primera versión.
• Los datos están licenciados bajo CC BY 4.0, lo que requiere atribución a SelfHost Atlas si se utilizan o adaptan.

Contexto

Al planificar la infraestructura para software autoalojado, los ingenieros suelen depender de los requisitos mínimos del sistema listados en la documentación del proyecto. Estas cifras son típicamente conservadoras, diseñadas para asegurar que el software funcione incluso en hardware restringido o ante picos de carga inesperados. Sin embargo, para equipos pequeños o individuos que ejecutan múltiples servicios en un único servidor privado virtual, estas estimaciones conservadoras pueden llevar a un sobreaprovisionamiento y costos innecesarios. Entender la diferencia entre un mínimo recomendado y el uso real en reposo es crítico para una planificación eficiente de la capacidad.

El autoalojamiento implica ejecutar software en tu propia infraestructura en lugar de depender de un proveedor SaaS de terceros. Esto da a los usuarios control sobre sus datos y opciones de personalización, pero traslada la carga de mantenimiento y gestión de recursos al usuario. Herramientas como Docker simplifican el despliegue, pero no eliminan la necesidad de entender cuánta memoria y almacenamiento consume cada contenedor. Sin datos precisos, los administradores pueden asignar demasiados recursos a una app, dejando a otras hambrientas, o pagar por instancias de servidor más grandes de las necesarias.

Por qué importa

Para equipos que gestionan su propio stack de software, los datos precisos de recursos impactan directamente en el presupuesto y el rendimiento. Si un administrador asume que cada app necesita la RAM mínima documentada, podría aprovisionar un servidor con 8 GB de memoria cuando 4 GB serían suficientes según las mediciones reales en reposo. Este sobreaprovisionamiento aumenta las facturas mensuales de la nube sin añadir valor. A la inversa, conocer la verdadera huella en reposo permite empaquetar más servicios en un único host, maximizando la utilidad del hardware existente.

El conjunto de datos también sirve como capa de verificación para la documentación de instalación. En el mundo de código abierto, que avanza rápidamente, las instrucciones de instalación pueden quedar obsoletas pronto. Al registrar qué versiones del SO ejecutaron con éxito los scripts de instalación en fechas específicas, el conjunto de datos ayuda a los usuarios a identificar qué combinaciones se sabe que funcionan. Esto reduce el tiempo dedicado a resolver dependencias rotas o bibliotecas del sistema incompatibles durante la configuración inicial. Proporciona una línea base de confianza de que el software puede desplegarse tal como se describe.

Además, la transparencia de la metodología genera confianza. Como los datos son generados por un script automatizado en máquinas limpias, elimina sesgos humanos o trucos de optimización que podrían distorsionar los resultados. Los usuarios pueden ver exactamente cómo se derivaron los números, incluyendo comandos específicos de Docker y estados del sistema. Este nivel de detalle permite a los ingenieros DevOps replicar las pruebas en sus propios entornos si es necesario, asegurando que los datos se alineen con sus casos de uso y restricciones específicos.

Qué puedes hacer

• Descarga los archivos CSV o JSON desde el repositorio de GitHub para analizar el uso de recursos de las apps que ejecutas actualmente o planeas desplegar.
• Filtra los registros por install_verified_date para asegurarte de que estás mirando pruebas recientes, ya que las instalaciones antiguas pueden no reflejar las versiones actuales del software.
• Compara documented_min_ram_mb con measured_ram_mb para tus aplicaciones objetivo para identificar posibles sobreaprovisionamientos en tu configuración actual.
• Usa el campo install_verified_os para comprobar si la aplicación ha sido probada en la misma versión del sistema operativo que usas en producción.
• Atribuye correctamente los datos usando las pautas CC BY 4.0 proporcionadas si publicas cualquier análisis o dashboard basado en este conjunto de datos.
• Monitoriza el repositorio para actualizaciones, ya que el conjunto de datos se regenera mensualmente para incluir nuevas aplicaciones y mediciones actualizadas.