Qué es Heroku, cómo funcionan los dynos y para qué sirve
Publicado el 2026-10-26 por frfrand
Guía práctica sobre qué es heroku, cómo funcionan los dynos y para qué sirve con ejemplos y comparativa de infraestructura.
Heroku popularizó una idea buenísima: que desplegar una aplicación no debería empezar por aprender a configurar Linux. Subís tu código, indicás cómo arranca y la plataforma lo ejecuta. Lo que conviene entender es qué son los dynos y qué cosas se pagan o administran por separado.
No te voy a vender la idea de que una plataforma es perfecta para todos. Lo útil es entender qué trabajo te ahorra, qué trabajo sigue siendo tuyo y cuánto te puede costar mantenerla cuando el proyecto deja de ser una prueba.
Heroku: qué es lo que realmente te ofrece
Un dyno es una unidad de ejecución para tus procesos. Podés tener un proceso web, otro que trabaja con una cola y add-ons para componentes como bases de datos. Eso simplifica muchas tareas, pero su modelo de ejecución no equivale a tener root dentro de un VPS.
Un ejemplo que podrías tener mañana
Imaginá un chatbot que recibe mensajes por webhook y genera respuestas con un proveedor de IA. El receptor web puede vivir en un proceso; la generación, en un worker. El error sería meter ambos en una única petición HTTP y esperar que nunca se corte.
Cómo empezar sin complicarte de más
- Prepará tu aplicación con dependencias y comando de arranque declarados, por ejemplo mediante un
Procfilecuando aplica. - Conectá el proyecto al flujo de despliegue compatible con Heroku y probá una versión de staging.
- Configurá variables privadas y el add-on o servicio externo de PostgreSQL si tu app lo necesita.
- Separá dynos web de workers cuando tengas tareas prolongadas, como generar informes.
- Revisá logs, consumo, persistencia de archivos y costos antes de invitar usuarios reales.
El quinto paso suele ser el que se saltea: abrir la aplicación desde otro dispositivo, ejecutar una operación que escriba datos, revisar un log y volver a comprobarla después de reiniciar. Eso vale más que una captura donde el panel dice «deployed».
El error que evitaría
El sistema de archivos de los dynos no es un almacén permanente para archivos subidos por usuarios. Tampoco alcanza con mirar el precio de un dyno: agregá la base, las colas, el almacenamiento y otros add-ons.
Hay otra regla simple: si el proyecto tiene clientes o pagos, no experimentes con migraciones directamente sobre la única copia de la base. Probá en un entorno separado, guardá una copia verificable y prepará cómo volver atrás.
¿Cómo resolvería lo mismo en ArduMaker?
En ArduMaker esos procesos pueden convivir en un VPS y administrarse mediante servicios separados; PostgreSQL o Redis se despliegan dentro de la misma infraestructura cuando corresponda. Tenés root y más margen para instalar herramientas, pero la operación del servidor deja de estar completamente abstraída.
En un caso típico, podrías crear el VPS en ArduMaker, conectar el repositorio Git, instalar o gestionar PostgreSQL según la aplicación, definir el proceso de ejecución y publicar un dominio HTTPS. Si hay un worker que tarda varios minutos, separalo del servicio HTTP. Y si el proyecto tiene varios clientes, organizalos por Empresa para evitar permisos y recursos mezclados.
| Necesidad | Heroku | ArduMaker |
|---|---|---|
| Modelo principal | Un dyno es una unidad de ejecución para tus procesos | VPS con herramientas de administración, Git, servicios y MCP |
| Acceso al sistema | Depende de la plataforma o del servidor donde se instala | Administración del entorno VPS |
| Base de datos y trabajadores | Dependen del producto y su configuración | Pueden ejecutarse en el VPS según los recursos disponibles |
| Mantenimiento | Compartido o asumido por vos según el servicio | Aplicación y sistema requieren control y mantenimiento |
Qué miraría antes de pagar o migrar
No elegiría por una única cifra en la página de precios. Anotá CPU, RAM, almacenamiento persistente, tráfico, copias, soporte y tiempo de mantenimiento. Si tenés que sumar una base gestionada, un servicio de workers o un panel con licencia, incluilos. Si querés redundancia entre servidores, también hay que diseñarla: un VPS por sí solo no es alta disponibilidad.
Entonces, ¿cuál usaría?
Heroku tiene sentido para equipos que priorizan su experiencia PaaS y su ecosistema. ArduMaker puede convenir cuando la app necesita varias piezas persistentes y acceso al sistema con un plan de VPS.
Una prueba honesta: publicá una API mínima, conectala a una base, detené el proceso para ver qué registra el sistema y probá recuperarla. La plataforma con la que tu equipo pueda repetir esos pasos sin sufrir suele ser la que más valor te aporta.
Fuentes y lecturas para seguir
- Documentación oficial de Heroku
- Comparación de Heroku con ArduMaker
- Cómo funcionan los VPS y para qué sirven
La idea final: primero resolvé un problema real con la herramienta. Después compará cuánto esfuerzo te lleva mantenerlo. Ahí aparece la diferencia entre una demo y una aplicación que podés entregar a un cliente.