community-scripts contiene hoy, 5 de septiembre de 2026, 590 scripts de LXC, 16 de máquina virtual y 76 herramientas para el propio host, más el generador de plantillas TurnKey.curl en ese momento. En un laboratorio da igual. En infraestructura de clientes, no.ProxmoxVED— y se distingue mirando la URL del propio comando. Es la comprobación más barata que existe.Hay una herramienta que usamos casi a diario y que mucha gente que trabaja con Proxmox todavía no conoce. No tiene marketing, no tiene empresa detrás y no aparece en ninguna comparativa de producto. Solo tiene una web con un buscador, un repositorio en GitHub y una cifra que da bastante que pensar: dos millones y pico de instalaciones.
La mecánica es tan simple que cuesta creer que funcione. Abres la shell del nodo Proxmox, pegas una línea, respondes a dos o tres preguntas y a los pocos minutos tienes un contenedor LXC corriendo con PostgreSQL dentro, con su disco, su memoria, su red y el servicio arrancado. Lo que antes era media mañana aprovisionando, instalando dependencias y peleando con un fichero de configuración, ahora son dos minutos.
Y luego está la otra mitad del artículo, la que casi nadie escribe: qué criterio hace falta para meter esto en la infraestructura de un cliente sin que sea una imprudencia.
Un Helper-Script es un script de shell que hace tres cosas seguidas: crea el contenedor (o la máquina virtual), instala el servicio dentro y lo deja configurado con unos valores razonables. No es un instalador de paquetes con lazo, porque también decide el tamaño del contenedor, el sistema operativo base, si es privilegiado o no, y deja un ayudante de post-instalación para actualizar el servicio después.
El comando tiene siempre la misma forma:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/postgresql.sh)"A partir de ahí, dos caminos. En modo Default el script elige los recursos por ti y solo pregunta lo imprescindible; la mayoría de instalaciones terminan en menos de cinco minutos. En modo Advanced te deja tocar todo antes de que se cree nada: identificador del contenedor, CPU, memoria, disco, almacenamiento de destino, red, VLAN, DNS, si es privilegiado, y los ajustes propios de la aplicación.
Los valores por defecto no son de adorno. Estos son los reales de algunos que usamos, tal y como los declara el catálogo hoy:
| Servicio | Base | Recursos por defecto | Variante ligera |
|---|---|---|---|
| PostgreSQL | Debian 13 | 1 vCPU · 1 GB RAM · 4 GB disco | Alpine 3.24, 256 MB · 1 GB |
| MongoDB | Debian 13 | 1 vCPU · 512 MB RAM · 4 GB disco | — |
| MariaDB | Debian 13 | 1 vCPU · 1 GB RAM · 4 GB disco | Alpine 3.24, 256 MB · 1 GB |
| Valkey | Alpine 3.24 | 1 vCPU · 256 MB RAM · 1 GB disco | — |
| Docker | Debian 13 | 2 vCPU · 2 GB RAM · 4 GB disco | Alpine 3.24, 1 GB · 2 GB |
| Vaultwarden | Debian 13 | 4 vCPU · 6 GB RAM · 20 GB disco | Alpine 3.24, 256 MB · 1 GB |
| Keycloak | Debian 13 | 2 vCPU · 2 GB RAM · 4 GB disco | — |
| VictoriaMetrics | Debian 13 | 2 vCPU · 2 GB RAM · 16 GB disco | — |
| BentoPDF | Debian 13 | 1 vCPU · 4 GB RAM · 4 GB disco | — |
Fíjate en Vaultwarden: 4 vCPU y 6 GB de RAM por defecto, frente a los 256 MB de su variante Alpine. No es un error, es que la versión Debian compila desde fuente y necesita ese margen mientras construye. Ese tipo de detalle es justo el que uno agradece que alguien haya resuelto antes.
Conté los ficheros del repositorio esta mañana, en vez de fiarme del número redondo que circula por ahí. El reparto es este:
| Tipo | Cantidad | Qué contiene |
|---|---|---|
Scripts de LXC (ct/) | 590 | Servicios que se instalan creando un contenedor nuevo |
Scripts de VM (vm/) | 16 | Debian, Ubuntu, Arch, OPNsense, OpenWrt, TrueNAS, Home Assistant OS, MikroTik RouterOS… |
Herramientas de host (tools/pve) | 35 | Mantenimiento del propio Proxmox |
Complementos (tools/addon) | 32 | Se instalan dentro de un LXC que ya existe |
Migración de datos (tools/copy-data) | 9 | Mover datos entre variantes de un mismo servicio |
| TurnKey | 1 | Un script que da acceso a todo el catálogo de plantillas TurnKey |
El catálogo web contabiliza en torno a 730 entradas porque desglosa las plantillas TurnKey una por una. Categorías hay de todo: automatización del hogar, multimedia, redes, monitorización, bases de datos, seguridad y herramientas de desarrollo. Que el origen del proyecto sea el mundo del self-hosting doméstico explica que Jellyfin y Home Assistant convivan con PostgreSQL y Keycloak.
Los diez más instalados en los últimos treinta días, según el propio contador del proyecto, dicen bastante de quién lo usa:
| Script | Instalaciones (30 días) |
|---|---|
| Docker | 52.517 |
| AdGuard Home | 29.617 |
| Debian (LXC base) | 26.065 |
| Immich | 21.208 |
| Jellyfin | 17.600 |
| Nginx Proxy Manager | 16.479 |
| Frigate | 14.201 |
| Pi-hole | 12.835 |
| Vaultwarden | 12.574 |
| WireGuard | 12.469 |
Domina el homelab, sin discusión. Pero ahí abajo, en la misma lista, aparecen PostgreSQL con 4.507 instalaciones, Proxmox Backup Server con 6.676 y Grafana con 7.261. Esa es la parte que a nosotros nos interesa.
Si solo conoces la parte de «instalar aplicaciones», te estás dejando la mitad buena. Las 35 herramientas de tools/pve no crean nada: operan sobre el hipervisor. Estas son las que merecen un vistazo aunque nunca instales un solo LXC del catálogo:
| Herramienta | Para qué sirve |
|---|---|
| Proxmox VE Post Install | Gestiona los repositorios tras una instalación limpia: desactiva el empresarial, corrige las fuentes, activa el no-subscription, añade el de pruebas, quita el aviso de suscripción y actualiza el sistema |
| Proxmox Backup Server Post Install | Lo mismo para PBS. También existen las versiones para Mail Gateway y para Datacenter Manager |
| PBS 4 Upgrade | Guía la subida de PBS 3.x (Debian 12) a 4.0 (Debian 13): ajusta las fuentes de Debian, pasa los repositorios a formato deb822 y lanza la actualización completa |
| Kernel Clean | Borra los kernels antiguos que ya no se usan: acorta el menú de GRUB y recupera espacio en el disco de sistema |
| Kernel Pin | Fija o suelta un kernel concreto. La herramienta que quieres tener a mano el día que una versión nueva rompe un passthrough |
| Microcode | Instala las actualizaciones de microcódigo del procesador. Hay versión específica para PBS |
| Disk Health | Informe de salud de todos los discos físicos del host. Instala smartmontools y nvme-cli cuando hacen falta, ignora loop, zram y device-mapper, y puede lanzar un test SMART no destructivo |
| Clean Orphaned LVM | Localiza volúmenes LVM huérfanos que ya no pertenecen a ninguna VM ni contenedor y ofrece borrarlos, protegiendo los críticos como raíz y swap |
| Monitor All | Vigila el estado de todas las instancias, contenedores y máquinas, y las reinicia si dejan de responder. Excluye plantillas y lo que marques por etiquetas |
| Update LXCs | Actualiza el sistema operativo dentro de todos los contenedores, sean Debian, Ubuntu, Devuan, Alpine, Rocky, Alma, Fedora o Arch. Con Cron Update LXCs se programa solo |
| Update Apps | Actualiza los LXC creados con estos mismos scripts: detecta el servicio instalado, comprueba si hay actualizador y lo aplica, con copia previa opcional |
| Host Backup | Copia los directorios del host que le indiques a la ruta que le indiques |
| PVE Privilege Converter | Convierte contenedores entre privilegiado y no privilegiado usando vzdump y restauración |
| Storage Share Helper | Utilidad interactiva para probar y configurar almacenamiento SMB/CIFS, NFS e iSCSI, gestionar bind mounts en LXC y crear comparticiones en el host |
| Add IP-Tag | Añade la dirección IP como etiqueta a cada LXC y VM mediante un servicio systemd, y la actualiza si cambia |
| Execute | Ejecuta un comando dentro de uno o varios contenedores, con lista de exclusión. Arranca el contenedor parado, ejecuta y lo vuelve a dejar como estaba |
| Scaling Governor | Cambia el gobernador de frecuencia de la CPU, entre ahorro y rendimiento |
| fstrim | Lanza el descarte de bloques en los contenedores, que no lo automatizan como sí hacen las VM. Importante en almacenamiento con aprovisionamiento fino |
| HW Acceleration / USB Passthrough | Preparan el host y el contenedor para aceleración por hardware y para pasar dispositivos USB |
| NIC Offloading Fix | Desactiva el offloading de las tarjetas Intel e1000e y e1000 mediante un servicio systemd. Si has sufrido esa tarjeta, sabes de qué va |
| All Templates | Crea cualquiera de las plantillas LXC gratuitas disponibles, con la contraseña guardada en un fichero .creds |
Varias de estas son puro trabajo repetitivo de operación: el post-install de repositorios, la limpieza de kernels, el fstrim, la salud de discos. Y ojo con Kernel Pin, que es de los que salva un fin de semana: si actualizas el nodo y el kernel nuevo deja de llevarse bien con tu tarjeta o con tu passthrough de GPU, fijar el anterior y arrancar es cuestión de un minuto.
Todo lo anterior es cierto y sigue siendo cierto esto otro: estás ejecutando como root, en tu hipervisor, un script que descargas en ese mismo instante. Sin firma, sin fijar versión, sin revisión previa. Si la cuenta de GitHub cayera, si un pull request colara algo, si la resolución DNS de tu nodo apuntara a donde no debe, el resultado es control total del anfitrión y de todo lo que corre encima.
En un homelab, eso da igual. En una plataforma con clientes dentro, no. Nuestro criterio es este, y no tiene nada de heroico:
Leemos el script antes. La ficha de cada uno enlaza su código fuente. Son unas decenas de líneas y se leen en dos minutos. Buscas de dónde descarga, qué repositorios añade, qué abre al exterior y con qué contraseñas se queda. Ese rato es lo único que separa «me fío» de «lo he mirado».
Lo marcado como TESTING se queda en el laboratorio. Y aquí hay un truco que casi nadie cuenta: los scripts en pruebas no están en el repositorio principal, están en ProxmoxVED. Se ve en la propia URL del comando. Si en la línea que vas a pegar pone ProxmoxVED en vez de ProxmoxVE, eso no va a un nodo de producción. Es la comprobación más barata del mundo y funciona incluso cuando no has entrado en la web.
Nada queda expuesto sin revisar la configuración con la que lo dejan. Un script te deja el servicio corriendo, no endurecido. Contraseñas por defecto, puertos, TLS, qué escucha en qué interfaz: eso se repasa siempre, y va detrás de un proxy inverso y de las reglas de cortafuegos que correspondan.
No sustituyen a nuestro procedimiento. Un contenedor creado así arranca rápido, pero cuando el servicio entra en producción de un cliente pasa por lo mismo que todo lo demás: inventario, copias en Proxmox Backup Server, monitorización, actualizaciones y responsables. Aceleran el arranque, no la responsabilidad.
Hay un quinto punto que conviene tener presente: estos contenedores no son infraestructura como código. Nacen de una sesión interactiva, y si nadie apunta cómo se creó, dentro de un año nadie sabrá reproducirlo. Para lo que va a durar, el camino es plantillas y cloud-init o directamente Terraform u OpenTofu. Los Helper-Scripts son excelentes para llegar antes al primer «funciona»; no son el sitio donde vive la definición de tu plataforma.
De algún sitio salen esos 2,2 millones. Salen de una telemetría que el proyecto incorpora y que conviene conocer antes de que aparezca en una auditoría.
Es opt-in explícito: la primera vez que ejecutas un script sale un diálogo preguntándolo, y si no dices que sí, la variable se queda en no y no se envía nada. La preferencia se guarda en /usr/local/community-scripts/diagnostics y se puede cambiar luego desde el menú de ajustes o editando el fichero a mano:
# /usr/local/community-scripts/diagnostics
DIAGNOSTICS=noSi la activas, lo que viaja a telemetry.community-scripts.org es esto: tamaño de disco, número de núcleos, memoria, tipo y versión del sistema operativo, nombre de la aplicación, método de instalación, versión de Proxmox VE, estado final y código de salida. En caso de fallo, además, un extracto acotado del error —el proyecto lo limita a 60 líneas y 10 KB— para poder depurar. No se envían direcciones IP, nombres de host ni contraseñas, y el identificador de sesión es un UUID aleatorio.
Dicho de otro modo: es razonable y está documentado, pero es una decisión que se toma, no algo que se descubre. En nodos de cliente va desactivada, sin más discusión, igual que cualquier otro envío de datos hacia fuera que no hayamos acordado.
Cuando Proxmox publicó su build oficial para ARM64 el 5 de agosto de 2026, el proyecto anunció soporte al día siguiente. Los ports que existían por separado se archivaron y el trabajo se consolidó en el repositorio principal.
Hoy cada ficha declara sus arquitecturas. La mayoría de lo que hemos mirado lleva amd64 y arm64 —PostgreSQL, MongoDB, MariaDB, Docker, Gitea, Grafana, Vaultwarden—, pero no todo: Authentik y MinIO siguen siendo solo amd64. Si estás montando sobre Ampere o sobre un Raspberry Pi de laboratorio, esa línea de la ficha es la primera que hay que mirar.
Conviene saber también que ahora mismo el proyecto tiene temporalmente cerrada la entrada de scripts nuevos en el repositorio de pruebas mientras completa una migración interna. Las correcciones a los existentes siguen su curso normal.
El proyecto lo creó tteck. Su repositorio original nació el 30 de noviembre de 2021 y llegó a 15.169 estrellas.
En noviembre de 2024 anunció que estaba en cuidados paliativos con un cáncer terminal. Murió pocos días después. Quien lo comunicó, el 13 de noviembre, fue Angie, su mujer, escribiendo en el GitHub del proyecto: «he passed away a few days ago». Esa discusión acumuló más de quinientos comentarios de gente que había aprendido Proxmox con sus scripts.
El repositorio original está archivado desde entonces. La comunidad lo recogió, creó community-scripts/ProxmoxVE y siguió. Casi dos años después el proyecto tiene equipo, ciclo de publicación, repositorio de pruebas separado, política de seguridad y una infraestructura que pagan los mantenedores de su bolsillo. El 30% de las donaciones va a investigación del cáncer y cuidados paliativos, porque era la causa que importaba a tteck.
Hay un detalle que a mí me parece el mejor de toda la historia. Si abres hoy el script que gestiona los repositorios tras una instalación limpia, el que ejecuta media comunidad de Proxmox cada vez que monta un nodo, la primera línea sigue diciendo esto:
# Copyright (c) 2021-2026 tteck
# Author: tteckster | MickLesk (CanbiZ)
# License: MITNadie le ha quitado el nombre. Y nunca se supo su nombre real. Solo hay dos millones y pico de instalaciones que existen porque a alguien le pareció que merecía la pena resolverle el problema a desconocidos.
Lo usamos, sobre todo para levantar bases de datos deprisa —MongoDB y PostgreSQL— y para servicios internos que nos ahorran trabajo, como BentoPDF. Y usamos las herramientas de host bastante más de lo que usamos el catálogo de aplicaciones: el post-install de repositorios, la limpieza de kernels, la salud de discos y el fstrim son parte del día a día.
El criterio, resumido en una frase: un Helper-Script es una forma rapidísima de llegar al primer arranque, y no es un método de despliegue. Sirve para probar una idea esta tarde, para montar un entorno de laboratorio, para no perder media mañana en algo que alguien ya resolvió. Lo que va a estar corriendo dentro de dos años en la plataforma de un cliente se define en otro sitio, con contenedores o máquinas según lo que toque, con acceso al hipervisor endurecido y con copias que alguien ha probado a restaurar.
Es la misma distinción que hacíamos con ProxMenux y con ProxSave: las herramientas de la comunidad alrededor de Proxmox son buenísimas, y precisamente por eso hay que tener claro cuál es su sitio.
Si estás montando una plataforma sobre Proxmox y quieres que alguien se ocupe de la parte aburrida —la que va después del primer arranque—, mira nuestros servicios gestionados o cuéntanos qué tienes montado.
Son scripts de shell mantenidos por la comunidad que crean un contenedor LXC o una máquina virtual en Proxmox VE con un servicio ya instalado y configurado, a partir de un único comando pegado en la shell del nodo. También incluyen herramientas para mantener el propio hipervisor.
Depende de con qué criterio. Son código sin firmar que se descarga en el momento y se ejecuta como root en el hipervisor. En un laboratorio no pasa nada; en infraestructura con clientes hay que leer el script antes, descartar lo marcado como TESTING, revisar la configuración con la que dejan el servicio y no saltarse el procedimiento propio de puesta en producción.
Por la URL del comando. Los estables descargan de community-scripts/ProxmoxVE; los que están en pruebas, de community-scripts/ProxmoxVED. Si ves esa D final, ese script no va a un nodo de producción.
A 5 de septiembre de 2026, el repositorio contiene 590 scripts de LXC, 16 de máquina virtual y 76 herramientas para el host y para contenedores existentes. El catálogo web contabiliza unas 730 entradas porque desglosa además las plantillas TurnKey.
Solo si lo autorizas. La telemetría es opt-in y pregunta en la primera ejecución. Si la activas, envía recursos del contenedor, sistema operativo, versión de Proxmox, nombre de la aplicación y estado final, sin IP ni nombres de host. Se desactiva poniendo DIAGNOSTICS=no en /usr/local/community-scripts/diagnostics.
Sí. El proyecto declara soporte para Proxmox VE 8.4 y la serie 9.x, y añadió ARM64 en agosto de 2026, al día siguiente de que Proxmox publicara su build oficial. Cada ficha indica sus arquitecturas: la mayoría cubre amd64 y arm64, pero algunos, como Authentik o MinIO, siguen siendo solo amd64.
No. Un contenedor creado con un Helper-Script nace de una sesión interactiva y no queda descrito en ningún sitio. Para lo que va a durar en el tiempo, la definición de la infraestructura debe vivir en plantillas o en infraestructura como código; los Helper-Scripts sirven para llegar antes al primer arranque.
misc/api.func y misc/build.func — funcionamiento y campos de la telemetría, y el diálogo de consentimiento.
Cómo funciona Proxmox Backup Server por dentro y cómo se monta bien: troceado en chunks y deduplicación global, incrementales para siempre con el dirty bitmap de QEMU, verificación programada, retención con prune y recolección de basura, réplica offsite con sync jobs, S3 y cinta, y los tres caminos de restauración. Con el dimensionado del servidor, los fallos que vemos repetirse y en qué casos Veeam sigue teniendo sentido.
Proxmox Backup Server hace que los backups ocupen una fracción de lo esperado y se puedan guardar muchos más de lo que imaginas. Detrás hay tres piezas que conviene entender para confiar en tus copias: la deduplicación que ahorra el espacio, la verificación que detecta la corrupción silenciosa antes de que la necesites, y las políticas de retención que deciden cuánto historia guardas. Las explicamos una a una.
Asignar a tus VMs más CPU y RAM de la que el servidor tiene físicamente —overcommit— es lo que permite meter más máquinas en el mismo hardware. Con la CPU suele salir bien; con la memoria, hecho a la ligera, es la receta de un servidor que muere de golpe. Explicamos por qué la CPU se sobreasigna con tranquilidad y la RAM con mucho cuidado, y las herramientas (ballooning, KSM) para hacerlo con cabeza.