Ply vs Docker: Menos RAM, Mismo Rendimiento

En pocas palabras: Ply es un runtime Linux de 5 MB creado por iluxav en agosto de 2024 que elimina el daemon de Docker. Con solo 22 MB de RAM, permite ejecutar apps en VPS pequeños mediante imágenes mínimas y builds determinísticos.

En agosto de 2024, iluxav comenzó a trabajar en ply, un runtime y gestor de paquetes para Linux que permite ejecutar aplicaciones en contenedores mediante un único binario estático de aproximadamente 5 MB. A diferencia de Docker, ply elimina la necesidad de un daemon permanente y utiliza imágenes mínimas (4 KiB) basadas en paquetes compartidos, reduciendo el consumo de memoria del runtime a 22 MB frente a los 145-185 MB de dockerd. Ya lo cubrimos antes en configurar hardware Apple en Linux.

¿Por qué los desarrolladores buscan alternativas más simples a Docker?

Ponele que querés subir una app Next.js con Redis a un droplet barato. Pasás tres horas configurando Dockerfile, compose y permisos, cuando tu aplicación real apenas necesita 200 MB. El problema no es la app, es la infraestructura alrededor de ella. Durante años, la tendencia fue hacer cada vez más pesados los “andamios” necesarios para correr código simple. La frustración es palpable. Herramientas diseñadas para orquestar clústeres enteros terminan consumiendo más CPU y RAM que la propia aplicación. Si alguna vez intentaste usar Coolify o CapRover en un servidor modesto, sabés que el sistema operativo pasa más tiempo gestionando la plataforma que sirviendo tus datos. No me cierra del todo pagar por potencia extra solo para mantener vivo un daemon que no aporta valor directo al usuario final. ¿Y qué pasó cuando alguien decidió cortar ese nudo? Iluxav construyó ply justamente para devolverle al desarrollo web la sensación de “ejecutar un programa”. Un binario, un comando, cero overhead innecesario.

¿Qué es ply y cómo funciona su arquitectura de un solo binario?

Ply es un runtime de contenedores y gestor de paquetes para Linux distribuido como un único ejecutable estático de ~5 MB. Su diseño abandona el modelo cliente-servidor de Docker (donde el CLI habla con un daemon `dockerd`) para operar directamente sobre el kernel mediante namespaces, seccomp y cgroups. Fijate que la magia está en la separación de responsabilidades. En Docker, cada imagen lleva consigo capas completas del sistema base (Debian, Alpine, etc.). En ply, las dependencias del sistema y los runtimes de lenguaje (Node, Python) son paquetes globales compartidos. Cuando definís tu app en un archivo TOML, ply baja el paquete de Node 22 una sola vez a un store local. Si tenés diez apps distintas en el mismo servidor, todas apuntan a esa misma copia. El flujo es brutalmente simple:

• Definición: Escribís un manifiesto TOML declarando qué necesitás.
• Build: Genera una imagen squashfs de apenas unos KB (tu código + lockfile).
• Ejecución: Montás la imagen read-only, superponés una capa writable y corré el entrypoint.

Al no haber daemon, si cerrás la terminal con Ctrl-C, la app muere inmediatamente. Sin zombies, sin logs huérfanos, sin procesos fantasma consumiendo ciclos. Es tan minimalista que casi parece trampa, pero los benchmarks demuestran que rinde igual o mejor que las soluciones tradicionales.

Comparativa técnica: ¿Ply ofrece mejor rendimiento que Docker en servidores pequeños?

Acá viene lo bueno. Las cifras publicadas en el artículo original muestran una paridad funcional casi absoluta en throughput, pero una divergencia masiva en eficiencia de recursos. | Métrica | Ply | Docker | Diferencia | | :— | :— | :— | :— | | Throughput HTTP | 726k req/s | 714k req/s | Ply +1.7% | | Latencia p99 | < 0.01 ms diff | Referencia | Prácticamente idéntica | | Memoria Runtime | 22 MB | 145 – 185 MB | Ply usa ~80% menos | | CPU Idle | 0.0 seg | Variable | Ply tiene proceso padre mínimo | | Tamaño Imagen Hello World | 4 KiB | ~100+ MiB | Reducción drástica | Ojo con esto: el benchmark de ply también tuvo sus tropiezos. La primera versión usaba un relay de usuariospace para publicar puertos, lo que hundía el rendimiento a 0.62 veces el de Docker. Al migrar a reglas `nftables DNAT` (la misma técnica que usa Docker), el cuello de botella desapareció. Para un equipo pequeño o un proyecto personal, esos 160 MB de RAM ahorrados son oro puro. En un VPS de 512 MB, Docker puede ocupar el 30% de la memoria disponible antes de cargar tu primera línea de código. Con ply, ese espacio queda libre para la aplicación real.

¿Cómo gestionar dependencias e imágenes de forma determinística con Ply?

Docker piensa en capas apiladas. Cada paso de un Dockerfile deja un diff en el filesystem. Si querés saber qué hay dentro, terminás leyendo líneas ilegibles y adivinando qué instaló el script de turno. Ply piensa en paquetes nombrados y versionados. Toma prestado lo mejor de otros ecosistemas:

• Cargo (Rust): Para el formato de manifiesto y lockfile legible.
• Go: Para la selección mínima de versiones, evitando sorpresas del solver.
• Nix: Porque un paquete ES su hash de contenido. Determinismo absoluto.
• Homebrew: Para dar a cada paquete su propio prefijo, eliminando conflictos de rutas.

El resultado es que podés abrir el lockfile de ply y leer exactamente qué versión de Node o Debian satisface la dependencia. No hay scripts de instalación ocultos (`post-install hooks`) que puedan romper tu build silenciosamente. Buildear la misma app dos veces produce imágenes byte-idénticas. Esto simplifica enormemente la auditoría de seguridad y la reproducción de entornos.

Guía rápida: Desplegando una app Next.js y Redis en un droplet de $6

Si te interesa probar esto en producción ya, el escenario ideal es un DigitalOcean Droplet básico (1 vCPU, 512 MB RAM). Según la fuente, el autor logró correr un dashboard, Redis y una app Next.js compilada desde cero en esta máquina limitada. Pasos clave observados en el caso de uso:

1. Instalación: Ejecutás el script oficial. Cero configuración compleja.
2. Swap: Activás un swap file de 2 GB (`sudo ply setup –swap 2G`). Crucial para compilar en RAM baja.
3. Build aislado: Ply crea un contenedor temporal para la compilación, limitado al 60% de la RAM física. Así, el servidor sigue respondiendo mientras se construye la nueva versión.
4. Despliegue declarativo: Colocás archivos en `/var/lib/ply/deployments/`. Un timer reconcilia el estado. Si la nueva instancia falla el health check, vuelve a la anterior automáticamente.

Los tiempos de build fueron de 209 segundos en frío y 80 segundos incrementales. Lento comparado con CI/CD dedicada, pero viable para proyectos donde el costo del servidor importa más que la velocidad de entrega. Además, al ser todo archivos, podés integrar ply con agentes de IA o scripts bash simples sin necesidad de APIs complejas.

Limitaciones actuales: ¿Cuándo NO deberías usar Ply todavía?

Seamos honestos: ply es pre-1.0. Está en fase beta temprana y tiene flaquezas claras que hoy descartan su uso corporativo generalizado.

• Ecosistema limitado: Docker Hub tiene millones de imágenes listas para usar. Ply soporta importación, pero solo ha probado 21 casos de uso comunes (bases de datos, proxies). Si tu stack depende de una librería obscure, vas a tener que empaquetarla vos.
• Solo Linux: Funciona nativamente en x86_64 y arm64. En Apple Silicon hay soporte experimental vía VMs, y en Windows dependés de WSL2. No esperes una experiencia fluida multiplataforma todavía.
• No es orquestador: Ply se detiene en un host. Si necesitás escalar horizontalmente entre múltiples máquinas, Kubernetes sigue siendo el rey. Ply no pretende competir ahí.
• Bugs desconocidos: El autor admite que probaron en entornos limpios y encontraron errores que no veían en sus laptops. La estabilidad no está garantizada.

¿Reemplaza a Docker? No. ¿Reemplaza a Kubernetes? Ni cerca. Pero para el nicho de “app monolítica pequeña en VPS económico”, zafa por poco y promete mucho.

Errores comunes al migrar a Ply

• Esperar compatibilidad total con Docker Compose: Aunque la sintaxis TOML es parecida, la lógica de red y volúmenes difiere. No copies y pegues archivos YAML esperando que funcionen mágicamente.
• Ignorar el swap en servidores de 512MB: Sin configurar el swap correctamente, los builds de Next.js o Rust fallarán por OOM (Out of Memory). Ply facilita esto, pero no lo hace automático si no ejecutás el setup inicial.
• Usar ply para microservicios complejos: La gestión de servicios interdependientes (`DATABASE_URL={db.url}`) es potente, pero si tenés decenas de servicios con latencias críticas entre sí, la falta de una malla de servicio robusta te va a doler.

Preguntas Frecuentes

¿Qué es ply y para qué sirve?

Ply es un runtime de contenedores ligero para Linux que permite ejecutar aplicaciones aisladas sin necesidad de un daemon central. Sirve para desplegar apps web, bases de datos y herramientas internas en servidores virtuales (VPS) de bajo costo, reduciendo significativamente el consumo de memoria y CPU comparado con Docker. En distribuciones optimizadas para Mac profundizamos sobre esto.

¿Ply consume menos recursos que Docker?

Sí, drásticamente. Mientras que el daemon de Docker ocupa entre 145 MB y 185 MB de RAM, el runtime de ply se mantiene en unos 22 MB. Además, al compartir dependencias del sistema entre aplicaciones, evita la duplicación de bibliotecas que infla el tamaño de las imágenes Docker. Para más detalles técnicos, mirá evitar caídas por errores de DNS.

¿Cómo despliego una app en un VPS barato con ply?

Instalás el binario único, creás un archivo TOML definiendo tu app y sus dependencias (ej. Node, Redis), y ejecutás `ply build` seguido de `ply run`. Para servidores con poca RAM (como 512 MB), recomendás configurar un archivo de swap usando `sudo ply setup –swap 2G` para permitir compilaciones locales sin caídas. Tema relacionado: automatizar despliegues con CI/CD.

¿Ply reemplaza a Kubernetes o Docker Swarm?

No. Ply está diseñado explícitamente para funcionar en un solo host. No ofrece orquestación multi-nodo, balanceo de carga global ni auto-scaling entre diferentes servidores. Para arquitecturas distribuidas grandes, Kubernetes sigue siendo la opción estándar; ply es para el nodo individual.

Conclusión

Ply no busca ganar la guerra contra Docker en empresas Fortune 500, sino recuperar la simplicidad perdida en el desarrollo indie y los equipos pequeños. Al demostrar que se puede obtener rendimiento comparable con una fracción de los recursos, plantea una pregunta incómoda para la industria: ¿cuánto pagamos realmente por la conveniencia de los daemons y las capas infinitas? Si tenés un proyecto personal, una herramienta interna o un MVP en un VPS económico, vale la pena experimentar con ply. Solo acordate de tratarlo como software beta: leé el changelog, probá en staging y reportá bugs. Para hosting regional en Latinoamérica, servicios como donweb.com ofrecen la infraestructura básica donde este tipo de optimizaciones de recursos tienen mayor impacto en el costo mensual.

Fuentes

• I wanted a simpler way to run apps on a VPS, so I built ply – Dev.to
• Repository oficial de Ply – GitHub
• Documentación comparativa Ply vs Docker – Plybox.sh