Las razones por las que no uso los helper scripts de Proxmox

En el post anterior sobre Proxmox os conté por qué elegí Proxmox como plataforma de virtualización. Hoy os explico por qué huyo de los “helper scripts” que prometen instalar todo en un clic.

El encanto de lo fácil

Cualquiera que se haya adentrado mínimamente en el mundo de los homelabs y Proxmox se ha cruzado alguna vez con los famosos Proxmox Helper Scripts (los que antes mantenía tteck, ahora continuados por la comunidad). Son una auténtica maravilla: copias una línea en la consola de tu nodo de Proxmox, le das al Enter, respondes un par de preguntas y en cuestión de minutos tienes un contenedor LXC perfectamente configurado corriendo Nextcloud, N8N, Paperless-ngx, Firefly III o cualquier otro servicio que te puedas imaginar. Durante un tiempo los estuve usando para probar cosas rápido, e incluso pensé en basar toda la arquitectura de mis servicios en ellos. Pero conforme mi red crecía, detecté un problema arquitectónico bastante molesto.

Qué hace exactamente un helper script

Para quien no los haya visto nunca, el script de N8N, por ejemplo, hace esto cuando lo ejecutas:

Descarga una imagen base de Debian o Ubuntu para el contenedor LXC
Crea el contenedor con los recursos por defecto que el script considera razonables (que pueden o no coincidir con lo que tú necesitas)
Instala Node.js en ese contenedor
Instala PostgreSQL o SQLite en ese mismo contenedor, según el script decida
Instala N8N y lo configura para que use esa base de datos local
Configura systemd para que N8N arranque automáticamente
Te da la IP y el puerto En diez minutos tienes N8N corriendo. Magia. Y el problema es exactamente eso: que es una caja negra. No sabes qué versión de PostgreSQL instaló. No sabes con qué configuración. No sabes si aplicó algún ajuste de seguridad o si dejó el usuario root de la base de datos con contraseña vacía (cosa que he visto en algún script). Ejecutas un script de bash de terceros con permisos de root en tu nodo. Ese script descarga cosas de internet durante la ejecución. Y no tienes ni idea de qué está descargando exactamente ni de qué hace con ello. No digo que los scripts sean maliciosos. La comunidad que los mantiene hace un trabajo serio. Pero confiar ciegamente en un script que ejecutas con root en producción es exactamente el tipo de decisión que luego te cuesta cara.

El riesgo de ejecutar scripts de terceros en producción

Cuando ejecutas bash -c "$(curl -fsSL https://url-de-internet/script.sh)", estás haciendo varias cosas a la vez: descargando código de un servidor externo, ejecutándolo inmediatamente sin revisarlo, con los permisos más altos que puede tener un proceso en Linux. El ataque más evidente aquí se llama supply chain attack: alguien compromete el servidor que sirve el script o el repositorio de GitHub donde vive, modifica el script para que haga algo malicioso además de instalar el servicio, y el próximo que lo ejecute instala el malware sin enterarse. Ha pasado con paquetes de npm, con imágenes de Docker, con scripts de bash. No es ciencia ficción. La forma correcta de usar estos scripts, si los vas a usar, es siempre leerlos antes de ejecutarlos. Descarga el script, ábrelo, lee qué hace, y solo después ejecútalo. No lo hagas directamente con curl.

# MAL: ejecutar sin revisar
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/n8n.sh)"
# MEJOR: descargar primero, revisar, luego ejecutar
curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/n8n.sh -o n8n_script.sh
# Lee el script
cat n8n_script.sh
# Si te parece bien, ejecútalo
bash n8n_script.sh

Sé que la mayoría no lo hace. Yo tampoco lo hacía. Pero cuando tu homelab aloja datos reales (fotos de familia, documentos, bases de datos financieras), el nivel de cuidado tiene que ser otro. En mi post sobre Jellyfin os cuento cómo los helper scripts me asignaron solo 16GB de disco por defecto, y como todo “funcionaba”, no me di cuenta hasta que el disco se llenó y los transcodes de 4K empezaron a fallar silenciosamente.

El problema: el aislamiento de las bases de datos

El mayor inconveniente de estos scripts es, paradójicamente, su mayor virtud: son paquetes cerrados y aislados. Cuando instalas un servicio con un helper script que requiere una base de datos (por ejemplo PostgreSQL o MariaDB) o una caché (como Redis), el script asume que quieres la vía rápida y te instala el motor de base de datos dentro del propio contenedor LXC del servicio. Si tienes 10 servicios instalados así… acabas teniendo 10 instancias diferentes de PostgreSQL corriendo en el mismo nodo de Proxmox, en 10 contenedores distintos. Esto provoca cuatro problemas principales:

1. Desperdicio de recursos (RAM y CPU)

Un motor de base de datos como PostgreSQL o MariaDB tiene un consumo de memoria base solo por estar funcionando, independientemente de lo grande que sea la base de datos que aloje. Multiplica ese consumo por la cantidad de servicios que tengas. Estás malgastando gigabytes de RAM que podrían estar haciendo algo útil.

2. Mantenimiento y actualizaciones

Si sale un parche crítico de seguridad para MariaDB, en lugar de actualizar un solo servidor de bases de datos tienes que ir entrando contenedor a contenedor, actualizando el sistema operativo y el motor de base de datos de cada uno de tus servicios. Un auténtico engorro.

3. Backups más complejos

Hacer backups de las bases de datos (un pg_dump o mysqldump puro) es bastante más molesto cuando cada base de datos vive aislada de las demás. Centralizándolo, gestionas las copias de seguridad de los datos vitales desde un solo lugar.

4. Dificultad para Alta Disponibilidad (HA)

Cuando cada servicio tiene su propia base de datos incrustada en su contenedor, configurar un entorno de Alta Disponibilidad real se convierte en una pesadilla. Con un servidor central de bases de datos es mucho más sencillo montar un clúster (Galera Cluster para MariaDB, Patroni para PostgreSQL) que replique tu información entre varios nodos. Sin centralización, tienes que configurar y mantener un sistema de replicación independiente por cada servicio aislado.

La solución: centralizar las bases de datos

La decisión de no usar los helper scripts es simplemente consecuencia de mi estrategia de centralización de datos. En lugar de lanzar el script y olvidarme, prefiero crear contenedores LXC puros o máquinas virtuales e instalar las versiones sin extras (o vía contenedores Docker, según el servicio). En paralelo, tengo un LXC dedicado exclusivamente a ser el servidor de bases de datos: mi MariaDB, mi PostgreSQL y mi Redis central. Cuando configuro N8N o Asterisk, simplemente los apunto a ese servidor central.

Cómo lo tengo montado en concreto

El contenedor de bases de datos tiene estos recursos asignados:

2 vCPU
2GB de RAM (generosos para que MariaDB tenga cache suficiente)
20GB de disco (solo para los datos de las bases de datos) Dentro corre MariaDB 10.11 y PostgreSQL 16 simultáneamente. Por qué los dos: algunos servicios solo soportan MySQL/MariaDB (como Paperless-ngx en su configuración más sencilla), otros prefieren PostgreSQL (como Nextcloud o N8N en serio). Redis está en el mismo contenedor porque consume muy poca RAM y simplifica la configuración. Cuando instalo un nuevo servicio, el proceso es:

# En el contenedor de bases de datos, crear la base de datos para el nuevo servicio
mysql -u root -p
CREATE DATABASE n8n CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'n8n'@'%' IDENTIFIED BY 'contraseña-segura';
GRANT ALL PRIVILEGES ON n8n.* TO 'n8n'@'%';
FLUSH PRIVILEGES;

Y en la configuración del servicio en su propio contenedor, la cadena de conexión apunta a la IP del contenedor de base de datos: 192.168.1.105:3306. Cada servicio tiene su propio usuario de base de datos con permisos mínimos. Si un servicio se ve comprometido, el atacante tiene acceso a su base de datos pero no a las del resto.

El ahorro real de RAM

Antes de centralizar, con cinco servicios instalados con helper scripts, medí el consumo de RAM de todos los procesos de bases de datos sumados: 1,8GB de RAM solo en motores de base de datos, sin contar los propios servicios. Con el servidor centralizado: esos mismos cinco servicios usan la misma instancia de MariaDB o PostgreSQL, que consume 600MB de RAM total. Ahorro neto: 1,2GB, que uso para otras cosas. No es un ahorro marginal. En un servidor doméstico con 16GB de RAM, esos 1,2GB importan.

Los backups, simplificados

Con la base de datos centralizada, el backup de datos críticos es un solo script que corre en el contenedor de bases de datos:

#!/bin/bash
# Backup de todas las bases de datos a la vez
mysqldump --all-databases -u root -p"$MYSQL_ROOT_PASSWORD" | gzip > /backups/mariadb-$(date +%Y%m%d).sql.gz
pg_dumpall -U postgres | gzip > /backups/postgres-$(date +%Y%m%d).sql.gz

Un cron, una tarea, todos los datos importantes. Sin entrar contenedor por contenedor. Sí, se pierde el factor “magia” y la inmediatez de los scripts. Pero se gana en robustez, te obliga a entender cómo funcionan por dentro las aplicaciones que hospedas y, a la larga, tu homelab consume muchos menos recursos.

Compártelo si te ha resultado útil. ¿Has pasado por algo similar con los helper scripts? ¿Cómo tienes estructurados tus servicios? Cuéntame en los comentarios. Y… hasta aquí por hoy!