--cap-drop=ALL, no-new-privileges, usuario sin privilegios y límites de CPU y RAM.nvidia-smi --gpu-reset en Linux.curl | bash.Prestar una GPU debería ser fácil y no lo es. Un compañero necesita reproducir un fallo en la Jetson que tienes en la mesa, un estudiante necesita cuatro horas de la workstation del laboratorio, alguien de otro equipo quiere lanzar un entrenamiento pequeño en la máquina de pruebas que está parada. Y lo que en teoría son diez minutos se convierte en crear un usuario, generar claves, revisar sudoers, decidir si abres el puerto o montas un túnel, y acordarte dentro de dos semanas de quitarlo todo.
Ese trabajo es proporcional a la infraestructura, no a la tarea. Y en la mayoría de los casos la tarea es pequeña.
RunSnack, del desarrollador Manuel Herrador, ataca exactamente ese desajuste. El anfitrión ejecuta un script, el script levanta un contenedor y devuelve un enlace. Quien recibe el enlace abre una terminal en el navegador, con la GPU del anfitrión disponible. No hay cuentas que crear, ni cliente que instalar, ni plataforma en medio cobrando comisión.
En Linux y macOS, el instalador:
chmod +x snackup.sh
./snackup.shEn Windows hay un equivalente en PowerShell, snackup.ps1.
El script comprueba que Docker esté disponible, pregunta cuántos núcleos y cuánta memoria quieres ceder, permite fijar opcionalmente un horario de acceso, descarga la imagen del agente —unos 1,4 GB la primera vez— y arranca el contenedor. Al terminar, imprime el enlace.
La detección de plataforma la hace él. En x86_64 usa la imagen estándar y --gpus all; en una NVIDIA Jetson cambia a la imagen de JetPack y al runtime de NVIDIA, y en un DGX Spark con Grace Blackwell usa su propia variante. Que se dé cuenta solo de dónde está corriendo es de las cosas que se agradecen cuando el hardware es heterogéneo.
Los dos scripts están publicados bajo Apache 2.0, así que se pueden leer antes de ejecutarlos. Conviene hacerlo, entre otras cosas porque es la única parte del sistema que se puede leer.
Aquí es donde RunSnack sube varios puntos respecto a la media de herramientas parecidas. Su documentación de seguridad no vende aislamiento perfecto: explica exactamente hasta dónde llega.
El contenedor arranca con el sistema de archivos raíz en solo lectura, todas las capabilities de Linux eliminadas (--cap-drop=ALL), no-new-privileges activo, un usuario sin privilegios con uid 1000, montajes tmpfs con nosuid y límites de CPU y memoria. Eso es bastante más de lo que hace la mayoría de la gente cuando entrega una cuenta de invitado en el host, y reduce mucho lo que un usuario remoto puede tocar.
Y a continuación viene la frase importante: un contenedor comparte kernel con el anfitrión. No hay una capa de virtualización entre medias, así que la separación no es la de una máquina virtual. El propio proyecto lo dice en una línea que deberían copiar más herramientas: si necesitas aislamiento a nivel de hipervisor, ejecuta RunSnack dentro de una VM. Es la misma distinción que repasamos al comparar contenedores y máquinas virtuales en Proxmox, y aquí tiene consecuencias concretas.
La otra frontera, más específica y menos conocida, es la GPU.
RunSnack entrega el acelerador entero al contenedor. No usa MIG ni vGPU, entre otras cosas porque ese particionado solo existe en hardware de centro de datos y no en una tarjeta de consumo. La consecuencia la escribe el propio proyecto: la VRAM no se borra de forma fiable cuando una carga libera la memoria, así que datos de una sesión pueden quedar legibles en una asignación posterior. Sin escapar del contenedor, sin explotar nada: simplemente pidiendo memoria.
Su recomendación para cambiar de usuario es tan poco sofisticada como honesta: apagar la máquina del todo unos diez segundos limpia la VRAM, y el contenedor vuelve solo porque queda configurado con --restart unless-stopped. En Linux, y si el hardware lo admite, nvidia-smi --gpu-reset hace el trabajo sin reiniciar.
Traducido a criterio operativo: RunSnack sirve para prestar, no para alquilar. La regla que propone el proyecto es la buena —compártelo solo con alguien a quien le darías una shell— y conviene añadirle otra: en una máquina donde haya datos que no son tuyos, no lo levantes.
Hay un detalle del modelo de código abierto que merece una línea propia, porque no aparece en la primera pantalla de la web.
Los instaladores son abiertos. El agente que establece y mantiene la conexión, no. Va dentro de una imagen publicada en Docker Hub, y el proyecto reconoce explícitamente que esa lógica no está publicada.
Para un laboratorio o un proyecto personal, eso es aceptable. Para una empresa, la pregunta es distinta: vas a ejecutar en un nodo con GPU un binario que no puedes auditar y que abre una conexión saliente para que alguien de fuera entre a una terminal. No es un escándalo —hacemos eso mismo con media docena de agentes propietarios todos los días—, pero es una decisión que se toma por escrito y con un responsable, no con un curl a las once de la noche. El mismo criterio que aplicamos con cualquier agente que se instala en un nodo de producción.
El valor de RunSnack no está en la potencia de la GPU. Está en el acceso a esa máquina concreta.
Un servicio de alquiler de GPU te ofrece cien tarjetas del mismo modelo, y eso resuelve el problema de «necesito cómputo». No resuelve el de «necesito reproducir el fallo en la Jetson que está conectada al robot», ni el de «necesito la workstation que tiene exactamente ese entorno instalado», ni el de «quiero que mi compañero vea lo mismo que veo yo».
| Situación | ¿RunSnack? |
|---|---|
| Prestar unas horas de la GPU del laboratorio a alguien del equipo | Encaja bien |
| Depurar sobre una Jetson o un equipo físico concreto | Es su mejor caso |
| Enseñar algo en directo sin montar cuentas | Encaja |
| Compartir con alguien de fuera de la organización | No, salvo dentro de una VM dedicada |
| Máquina con datos de clientes o de producción | No |
| Alquilar capacidad a desconocidos | No: no hay identidad, ni pagos, ni SLA, ni aislamiento suficiente |
| Multi-inquilino continuo entre equipos | No: eso ya es una plataforma, no un enlace |
Esa última fila es la frontera que nos encontramos en los proyectos. Cuando compartir GPU deja de ser algo puntual y se convierte en algo semanal, con varios equipos y varias cargas, el enlace se queda corto y hace falta lo de siempre: passthrough de la GPU a máquinas virtuales con VFIO e IOMMU, particionado con MIG o vGPU si el hardware lo permite, y una capa de identidad y cuotas por encima. Es más trabajo, y es el trabajo que hay que hacer cuando el aislamiento tiene que aguantar algo más que la confianza.
RunSnack hace bien una cosa pequeña, y la documenta con una honestidad que no abunda: dice dónde está su frontera de seguridad en lugar de vender que no la tiene.
Es un proyecto joven —un autor, cuatro estrellas en GitHub cuando escribimos esto y ninguna versión etiquetada—, así que la recomendación es la de siempre con software recién salido: pruébalo en una máquina que puedas apagar sin que nadie se entere, no en la que sostiene un servicio. Levantarlo dentro de una máquina virtual dedicada, con la GPU pasada a esa VM, resuelve de un golpe la mitad de sus avisos y sigue siendo mucho más rápido que montar accesos SSH.
Y si lo que tienes entre manos no es prestar una tarjeta un rato, sino repartir aceleradores entre varios equipos de forma continua, con aislamiento que aguante una auditoría, cuéntanos cómo lo tienes y lo miramos: ahí la respuesta ya no es un enlace, es una plataforma con GPU dedicada bien dimensionada.
Una herramienta que comparte temporalmente una terminal con acceso a los recursos de una máquina, incluida su GPU NVIDIA, mediante un enlace que se abre en el navegador. La sesión se ejecuta dentro de un contenedor Docker en el equipo anfitrión.
No. El anfitrión ejecuta el instalador, decide cuánta CPU y RAM cede y comparte el enlace resultante. Quien lo recibe no necesita cuenta ni software adicional.
Depende de con quién. El contenedor arranca endurecido —raíz en solo lectura, sin capabilities, sin escalada de privilegios, usuario sin permisos—, pero comparte kernel con el anfitrión y la GPU se entrega entera. El propio proyecto recomienda usarlo solo con personas de confianza y, si hace falta aislamiento real, ejecutarlo dentro de una máquina virtual.
Que pueden seguir ahí. Sin MIG ni vGPU, la VRAM no se borra de forma fiable entre cargas, así que una sesión posterior podría leer restos de la anterior. Para limpiarla, el proyecto recomienda apagar la máquina unos segundos o usar nvidia-smi --gpu-reset en Linux.
Solo en parte. Los scripts de instalación están en GitHub bajo Apache 2.0, pero el agente que gestiona la conexión viaja dentro de una imagen de Docker Hub y no es de código abierto.
No está pensado para eso. No hay identidad, ni pagos, ni garantías de disponibilidad, ni el aislamiento que exigiría compartir hardware con desconocidos. Su caso es prestar una máquina concreta a alguien que ya conoces.
snackup.sh y snackup.ps1, licencia Apache 2.0 de los scripts, imagen del agente cerrada, plataformas soportadas y estado del proyecto.
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.
Proxmox VE deja crear snapshots desde cualquier sitio, pero no hay una vista de todos los del clúster. ProxSnap, escrito en Rust por el autor de ProxLB, lista, filtra por fecha y borra snapshots viejos desde la API. Qué hace de verdad, qué cuesta un snapshot olvidado según el almacenamiento, y cómo montar una política sin llevarte por delante algo que hacía falta.
La microsegmentación es la estrategia; escribir las reglas es el oficio. Aquí bajamos al detalle práctico del firewall de Proxmox: el orden en que se evalúan las reglas, la dirección del tráfico, los grupos y los IPSets que lo hacen mantenible, y el NAT del SDN —SNAT de salida y redirección de puertos— que a veces sigue haciendo falta aunque IPv6 sea el futuro.