Heroku auto-hospedado en 2026: el estado del segmento

El 28 de noviembre de 2022, Salesforce apagó el plan gratuito de Heroku. La empresa que compró Heroku en 2010 cumplió el aviso publicado tres meses antes — todas las dynos free, todos los bancos hobby, todos los redises gratuitos fueron terminados en la misma ventana. Cientos de miles de hobby projects, MVPs, demos de portfolio y prototipos universitarios desaparecieron del aire de una sola vez.

La reacción fue previsible. Quien tenía cobro en la tarjeta migró al plan pago y siguió. Quien no tenía buscó otro lugar. Y en las semanas siguientes, un movimiento que existía en estado adormecido desde 2013 explotó: "Heroku auto-hospedado".

En 2026, tres años y medio después, el segmento maduró. Hay al menos seis productos serios disputando atención, más un puñado de proyectos hospedados que se venden como "Heroku-like" sin el auto. Este post es el mapa.

Por qué "Heroku auto-hospedado" se volvió una categoría

Lo primero que necesita decirse es que Heroku resolvió el problema correcto. En 2010, deploy de aplicación web tenía dos formas: subir tarball a un servidor que tú administrabas, o pagar caro para que alguien administre por ti. Heroku inventó el tercer camino — git push heroku main, slider de escala, base gestionada embebida, certificado emitido automáticamente, sub-dominio funcional en segundos.

Ese patrón quedó. El concepto de "deploy es un push, escala es un slider, TLS es automático" se volvió la expectativa-base de cualquier desarrollador formado después de 2012. Todo lo que vino después — Render, Railway, Fly.io, Vercel para frontend, Cloud Run, App Runner — es variación encima de ese modelo.

Pero tres cosas cambiaron entre 2010 y 2022.

Cloud bare-metal se volvió barato. En 2010, un servidor virtual decente costaba US$40/mes. En 2026, US$5/mes compra un VPS con 1 vCPU, 2 GB de RAM, 50 GB de disco y 2 TB de tráfico — más que suficiente para ejecutar cinco aplicaciones pequeñas. La economía de cerrar dynos para ejecutar containers propios se invirtió.

Docker se volvió estándar. La gran virtud de Heroku original eran los "buildpacks" — recetas que tomaban tu código Ruby o Node y producían un artefacto aislado listo para ejecutar. Docker volvió ese encapsulamiento commodity. Hoy cualquiera produce una imagen reproducible en tres líneas de Dockerfile, y cualquier servidor con 100 MB de RAM libre puede hospedarla.

La comunidad aprendió a operar. En 2010, "ejecutar un servidor Linux" era oficio de SRE. En 2026, cualquier desarrollador full-stack ya configuró nginx, lidió con certbot, montó systemd unit, debugueó OOM-killer por dmesg. El nivel medio subió. Aquello que justificaba pagar US$25/mes para que Heroku cuide se volvió un ejercicio de una tarde.

Cuando el gratuito murió, montar "tu propio Heroku" dejó de ser ejercicio de orgullo de hacker y se volvió cuenta de panadería. US$10/mes de VPS contra US$25/mes mínimo en el Heroku-pago — y eso por aplicación. Cinco aplicaciones en Heroku cuestan US$125/mes. Cinco aplicaciones en un VPS de US$10/mes siguen costando US$10/mes.

La categoría que respondió a esa cuenta tiene cinco subgéneros distintos hoy. Vale la pena separar.

El segmento en 2026

Single-server simple — "instalo en un VPS y olvido"

El subgénero más antiguo y más habitado. La premisa es directa: un único servidor, un instalador, un panel o CLI, y tienes dynos. Sin cluster, sin alta disponibilidad, sin complicación.

Dokku es el abuelito del segmento, activo desde 2013. El motor es Bash más Docker. UX es mayoritariamente CLI — empujas código vía git remoto, construye con buildpacks Heroku-compatibles, sube el container, registra en el router interno. La comunidad es pequeña pero leal, el producto es estable, y la curva de aprendizaje es empinada en los primeros días y plana después de eso. Quien pasó de esos primeros días raramente cambia. Está fuera de moda en el sentido de que la comunidad nueva prefiere paneles web — pero el producto sigue siendo sólido, con más de doce años de operación real en producción en miles de instalaciones por el mundo.

Caprover ocupa el medio del espectro. Panel web, sistema de plugins, instalación razonablemente fácil. El producto tiene cerca de trece mil estrellas en repositorios públicos y una comunidad activa, aunque menor que la de los competidores más nuevos. La evolución es más lenta — releases vienen en cadencia mensual o bimestral, y features grandes tardan. Para quien prioriza estabilidad sobre novedades, es una elección defendible.

Coolify es el líder actual de mindshare. Por encima de cuarenta mil estrellas, panel web moderno, ecosistema de plugins activo, comunidad ruidosa en foros y en chat. El producto evolucionó rápido entre 2023 y 2025, agregando soporte a base gestionada embebida, deploy vía git, certificados automáticos, monitoreo de containers. Es la recomendación default que circula en foros de indie hackers hoy.

El defecto principal de Coolify, y la razón de que aparezca también en la sección sobre trampas más abajo, es arquitectural: fue diseñado single-server first. Multi-server fue añadido después, pero el panel central sigue siendo un único proceso en un único servidor. Si ese servidor se cae, pierdes acceso a todos los demás.

Single-server moderno — "deploy sin panel"

Subgénero más nuevo, con filosofía opuesta a la anterior. En lugar de panel web, herramienta de línea de comando que opera por SSH.

Kamal es el representante casi exclusivo. Salió del equipo de 37signals en 2024, escrito por gente cercana a DHH. La premisa es radical: ningún panel, ningún control plane, ningún agente residente en los servidores. Escribes un archivo de configuración, corres kamal deploy, hace SSH en cada servidor, hace pull de la imagen, cambia el container y sigue. DHH publicó en 2024 que economizó cerca de tres millones de dólares al año migrando los apps propios de Basecamp y de HEY de la cloud a hardware propio con Kamal. Donde la tesis del "sin orquestación" empieza a doler está en HeroCtl vs Kamal.

La virtud es la transparencia absoluta — no hay nada sucediendo que no veas en el terminal. El defecto es que multi-server no es orquestación, es deploy paralelo. No hay elección de líder, no hay rebalanceo, no hay failover. Cada servidor es un destino independiente. Si uno se cae, notificas tu monitoreo y rehaces el deploy excluyendo aquel host.

Para un equipo pequeño operando dos o tres aplicaciones en tres a cinco servidores, con hábitos disciplinados de deploy, Kamal es elegante. Para cualquier cosa que necesite "si un servidor se cae, el cluster decide qué hacer solo", no es la herramienta correcta.

Cloud-native moderno — "Heroku reembrulhado"

Dokploy es el producto más reciente que entró en la conversación. Por encima de diez mil estrellas, en crecimiento rápido, UX visualmente parecida con Coolify pero arquitectura subyacente sobre Docker Swarm. Atractivo principal: multi-server real "fuera de la caja", sin necesitar montar a mano. La lectura punto a punto de la elección técnica que Dokploy hizo está en HeroCtl vs Dokploy.

El defecto estructural es la fundación. Docker Swarm está en modo de mantenimiento hace años — Docker Inc. no invierte en features nuevas desde 2019, y el roadmap público es esencialmente "mantener funcionando". Construir producto nuevo encima de tecnología en mantenimiento es una apuesta. Si Swarm fuera discontinuada formalmente, Dokploy necesita migrar de fundación entera o reescribir — y el usuario paga esa cuenta en mitad de camino. El ecosistema de plugins aún es menor que el de Coolify, pero viene subiendo rápido.

Hospedado-pero-prefiero-self-hosted — "Vercel/Render pero en mi servidor"

Técnicamente fuera de la categoría del título del post, pero vale la pena mencionar porque muchos equipos comparan. Quien busca "alternativa a Heroku" frecuentemente acaba no en el auto-hospedado, y sí en otro hospedado.

Render es el sucesor más directo de Heroku en el espíritu. UX limpia, precios previsibles, free tier generoso (pero no infinito — tiene suspensión automática por inactividad). Base Postgres y Redis gestionadas, deploy vía git, build logs en el panel. El precio sube de forma lineal con uso real, sin trampas grandes. Es la elección obvia para quien quiere "Heroku que funciona en 2026" sin preocuparse con servidor.

Railway es hospedado, foco más fuerte en devs solo, precio por uso de recursos (CPU/RAM/tráfico) en lugar de tier fijo. Funciona bien para hobby project que no va a escalar; puede ponerse caro rápido si olvidas un worker corriendo.

Fly.io tiene propuesta diferente: hospedaje distribuido en múltiples regiones, primitivas más crudas, próxima a "VM como servicio con TLS automático" que de "PaaS al estilo Heroku". Es la elección de quien quiere baja latencia mundial sin montarlo a mano. La curva de aprendizaje es mayor que Render o Railway.

Los tres son opciones legítimas. La nota importante es lo que viene en la sección de trampas: free tier de hospedado pisa más cada año, y el camino histórico de Heroku — empezó gratuito, se volvió US$25/mes mínimo — es la previsión default para cualquier plan gratuito de empresa privada.

Cluster real — "necesito alta disponibilidad"

Categoría corta, con pocos productos serios. Aquí la premisa no es "ejecutar deploy en más de un servidor", es "si un servidor se cae, el cluster sigue funcionando solo sin intervención humana". La diferencia es grande, y la mayoría del segmento no atraviesa esa línea.

HeroCtl es el producto que estamos construyendo. Plano de control replicado entre tres o más servidores desde el primer día. Elección automática de coordinador en alrededor de siete segundos cuando el servidor que coordina se cae. Router integrado, certificados automáticos, métricas y logs embebidos en el propio binario. Modelo comercial con Community gratuito permanente, Business y Enterprise pagos con precio publicado. Franja ideal: de uno a quinientos servidores.

La diferencia operacional importa cuando el cliente entra. Mientras el panel central de un Coolify multi-server es un punto único de fallo, en HeroCtl no hay central — cualquiera de los tres primeros servidores puede coordinar, y la transición entre ellos es automática.

Tabla comparativa

La columna que separa el segmento en dos mitades es "alta disponibilidad real". A la izquierda de ella, todos los productos comparten la misma premisa: multi-server es destino de deploy, no cluster con consenso. A la derecha, el panel/control plane es replicado y sobrevive a la pérdida de cualquier servidor.

Decisión por perfil de uso

Cuatro perfiles cubren la mayoría de los casos.

Solo dev, hobby project, un VPS. Dokku si te gusta CLI y quieres estabilidad. Coolify si prefieres panel web. Kamal si estás en un stack Rails o Node y ya trabajas bien con SSH y archivos de configuración. Cualquiera de los tres resuelve. La elección es más de gusto que de capacidad técnica.

Indie hacker con uno a tres SaaS pequeños, aún un servidor. Coolify o Dokploy. La diferencia práctica es el ecosistema de plugins (Coolify tiene más) y la fundación técnica (Dokploy apuesta en Swarm). Para los próximos doce meses, cualquiera de los dos funciona; la migración entre ellos es factible porque ambos ejecutan containers Docker estándar. La decisión arquitectural importante es diferente: cuando pases de un servidor a dos, vas a sentir el punto único de fallo del panel — y esa es la hora de evaluar si la próxima migración es Dokploy multi-server o un cluster de verdad.

Startup con primer cliente serio, SLA contractual entrando en vigor. HeroCtl. Aquí el panel single-server se vuelve pasivo legal — cualquier SLA escrito en contrato comercial asume que la infraestructura sobrevive a la pérdida de un nodo, y ningún panel single-server hace eso. Puedes intentar montar redundancia manual encima de Coolify o Dokploy, pero el resultado va a ser frágil y costoso de operar. La regla simple es: a la hora en que el contrato con cliente menciona "uptime", el cluster con consenso deja de ser lujo.

Empresa establecida, cincuenta servidores o más, equipo de plataforma con tres personas dedicadas. Aquí la conversación cambia. K8s gestionado en proveedor cloud pasa a ser la opción sensata, porque el ecosistema de operadores es mayor y el equipo tiene competencia para absorber la complejidad. HeroCtl ejecuta en esa franja también — testeamos cientos de nodos en laboratorio, decenas en producción de clientes — pero por encima de cien servidores el techo de nuestra biblioteca de operadores especializados empieza a aparecer.

Las tres trampas del segmento

"Multi-server" no significa "alta disponibilidad real"

La confusión más cara. La mayoría de los paneles lista "multi-server" como feature, y el lector casual interpreta eso como "si un servidor se cae, el sistema sigue funcionando". No es lo que está siendo ofrecido. Multi-server en la mayoría de los paneles significa: el panel central, ejecutando en un servidor único, es capaz de hacer deploy en varios servidores remotos.

Cuando el servidor del panel se cae, pierdes control. Los containers en producción siguen ejecutando — Docker no para por causa de eso — pero ya no logras hacer deploy, leer logs centralizados, reiniciar servicio, escalar. Quedas esperando volver.

Alta disponibilidad real exige consenso entre múltiples servidores: al menos tres procesos del panel ejecutando, elección automática de coordinador, replicación del estado entre ellos. Si el coordinador se cae, otro asume en segundos. Esa es una arquitectura diferente, más cara de construir y más cara de operar. Por eso pocos productos del segmento entregan.

La pregunta concreta para hacer al evaluar cualquier producto: "si el servidor donde ejecuta el panel fuera apagado ahora, ¿en cuánto tiempo el sistema vuelve a aceptar deploys, y esa vuelta es automática o manual?". Si la respuesta involucra a un humano abriendo SSH en algún lugar, no es alta disponibilidad.

"Plugin ecosystem" puede ser dependencia disfrazada

Los paneles con tienda de plugins parecen completos: instalas un plugin para tener Postgres gestionado, otro para Redis, otro para Sentry-like, otro para backup automático, otro para monitoreo. Cada uno resuelve un pedazo, y el conjunto suma un Heroku.

El problema aparece dos años después. El plugin de backup fue escrito por un voluntario en 2024 y paró de recibir commits en 2025. La versión nueva del panel rompió compatibilidad con él y nadie actualizó. Lo descubres en la hora que necesitas restaurar un backup — y la restauración nunca fue testeada con la versión actual.

Ese patrón se repite para cada plugin. Cuanto más funcionalidades dependan del ecosistema externo, mayor la superficie de riesgo. La defensa estructural es simple: da preferencia a productos con batería incluida — donde Postgres, métricas, logs, certificados, enrutamiento son parte del producto principal y mantenidos por el mismo equipo que mantiene el resto. Plugin es cómodo en el corto plazo y costoso en el medio.

"Free tier" del hospedado no es gratuito largo plazo

Render, Railway, Fly.io tienen planes gratuitos generosos hoy. Heroku tenía en 2021. La historia del segmento muestra un patrón consistente: free tiers de empresas privadas pisan más cada ronda de levantamiento de capital. Primero suspende por inactividad, después reduce cota, después añade límite de horas, después transforma en trial de treinta días, después encierra.

No es maldad — es matemática de negocio. Hospedar workload cuesta dinero, y el inversor cobra retorno. La única excepción estructural es hospedaje subsidiado por otro producto de la misma empresa (cloud cubriendo PaaS gratuita para atraer desarrolladores al cloud principal), e incluso esas cambian cuando cambia el CFO.

Auto-hospedado es la única defensa estructural. Pagas la cuenta del VPS directo al proveedor de infraestructura, sin intermediario. Cuando el intermediario desaparece, tu aplicación no desaparece junto.

Cuándo quedarse en Heroku, Render o Railway sin ironía

Vale la pena decir con claridad: no todo equipo necesita salir de hospedaje gestionado. Hay tres situaciones en las que quedarse es la decisión correcta.

Equipo pequeño sin competencia operacional disponible para cuidar de servidor. Si la equipa entera son dos desarrolladores de producto, ninguno con experiencia previa en Linux/Docker/networking, el coste cognitivo de operar infraestructura es mayor que la economía mensual. Paga los US$200/mes de Render y mantén foco en producto.

Aplicación cuyo coste de plataforma es despreciable comparado al revenue. Si la empresa factura US$50k/mes y la cuenta de Heroku es US$300, optimizar esa cuenta es trabajo mal alocado. El retorno marginal de migrar es bajo, y el riesgo operacional no compensa.

Equipo alocado en producto, no en infra. Algunas startups son tan dependientes de iteración rápida en producto que cualquier hora gastada en infra es hora robada del diferencial competitivo. Para esas, el trade-off de pagar a más para no pensar en servidor es valor real, no desperdicio.

La regla simple: si la infra es commodity invisible para tu negocio, deja que alguien cobre por ser invisible para ti. Si la infra es capacidad que diferencia el producto (latencia baja, regiones específicas, compliance específico, uptime contractual), el control compensa el trabajo.

HeroCtl en el segmento

Posicionamiento honesto: HeroCtl no compite con Dokku o Coolify en el caso de hobby project en un VPS. Para ese caso, es más máquina de la que necesitas. Un indie hacker con una aplicación Django en un servidor de US$5/mes debe usar Dokku o Coolify y seguir el día.

Donde HeroCtl compite es donde Coolify multi-server, Dokploy y Nomad también compiten: el caso de cliente serio con SLA, en que single-server se vuelve pasivo legal. Aquí la diferencia que ofrecemos es cluster con consenso desde el primer día, batería incluida en lugar de cinco productos para montar (router, certificados, métricas, logs y criptografía entre servicios ya en el binario), y contrato comercial publicado y congelado — sin cambio retroactivo de términos.

El cluster de demostración ejecuta cuatro servidores totalizando cinco vCPUs y diez gigabytes de RAM, con dieciséis containers activos sirviendo cinco sitios. El plano de control ocupa entre 200 y 400 MB por servidor. Comparativamente, el plano de control de una versión gestionada del orquestador grande empieza en alrededor de 700 MB por nodo-maestro antes de que cualquier aplicación suba.

El job spec típico tiene alrededor de cincuenta líneas — describe servicio, ingress, secretos, recursos. El equivalente en el orquestador grande pasa de trescientas líneas para cubrir la misma funcionalidad.

HeroCtl no compite con cloud gestionado en escala de cien nodos o más. La franja ideal es uno a quinientos servidores. Por encima de eso, el ecosistema externo de operadores especializados aún da ventaja al orquestador grande, y ser honesto sobre eso es parte del contrato.

Preguntas que recibimos

¿Puedo migrar de Heroku directo a HeroCtl? Sí, con algunas adaptaciones. Aplicación web stateless con Postgres separado migra fácil — la containerizas con Dockerfile, describes el job en cincuenta líneas, subes. Workers separados (Sidekiq, Celery) se vuelven jobs adicionales en el mismo cluster. Lo que necesita ser repensado es lo que dependía de add-ons gestionados.

¿Y los add-ons (Postgres, Redis, Sentry)? Postgres lo ejecutas como job en el propio cluster, con volume persistente, y cuidas de backup como humano cuida — no hay operador automático que haga eso mejor que tú haciéndolo bien hecho. Redis idem. Sentry self-hosted existe y ejecuta en cualquier cluster Docker — y hay producto comercial hospedado si prefieres no operar. La regla general: datos críticos ejecutan en el cluster, observabilidad puede ejecutar fuera.

¿Cuánto cuesta en comparación? Tomando como base una startup con cinco aplicaciones pequeñas: Heroku-pago sale alrededor de US$125/mes mínimo, sin add-ons. Render sale entre US$50 y US$150 dependiendo del uso. Cluster propio en VPS de tres nodos sale US$30 a US$60/mes total en el proveedor de infraestructura. La economía directa es real, y se vuelve más expresiva conforme las aplicaciones crecen.

¿Y si ya estoy en Coolify? No hay urgencia de migrar mientras operas con un único servidor. La hora de considerar es cuando el panel single-server se vuelve punto único de fallo contractual — primer cliente serio con SLA escrito. Hasta entonces, Coolify funciona bien.

¿Y para una app Django con Celery, o Rails con Sidekiq? Funciona naturalmente. Defines un job para el proceso web y otro job para el proceso de worker, ambos compartiendo la misma imagen pero con comandos diferentes. El cluster orquesta los dos independientemente, y el broker (Redis o similar) es un job más en el mismo cluster.

¿Y para una app Node.js con workers separados? Misma historia. Worker es solo otro proceso, definido como otro job. No hay distinción arquitectural entre "web" y "worker" en el nivel del orquestador — son containers que ejecutan código.

¿Los precios de Business salen cuándo? La página de planes publica los valores. La línea de corte está dibujada para que solo pagues Business cuando la empresa sea grande lo suficiente para que SSO, RBAC granular y auditoría detallada sean exigencias reales — no preferencia. Para todo el resto, Community resuelve, y Community es gratuito permanente sin feature gate artificial.

Cierre

El segmento de "Heroku auto-hospedado" maduró. En 2026, hay productos serios para cada perfil de uso, y la decisión depende menos de "cuál es el mejor" y más de "cuál cabe en mi caso". Hobby project no necesita cluster con consenso. Cliente serio con SLA no cabe en panel single-server.

Para quien está decidiendo ahora, tres recomendaciones finales. Primero, lee el contrato comercial antes de adoptar — huye de términos que permitan cambio retroactivo. Segundo, prefiere batería incluida a ecosistemas de plugins donde sea posible — superficie de riesgo menor. Tercero, prueba el camino de fallo antes del incidente real — apaga un servidor y mira lo que sucede, con calma, durante el día.

Para empezar con HeroCtl en tres servidores Linux:

curl -sSL get.heroctl.com/install.sh | sh

Si quieres leer más antes, hay dos posts adyacentes: HeroCtl vs Coolify explica la comparación directa con el líder de mindshare del segmento single-server, y Por qué creamos HeroCtl explica el raciocinio que llevó a la existencia del producto.

Orquestación de containers, sin ceremonia.