Heroku ahora está en modo de ingeniería de mantenimiento, y eso es un tipo de riesgo distinto a una subida de precio
El 6 de febrero de 2026, el director de producto de Heroku, Nitin T Bhat, publicó un texto corto titulado “An Update on Heroku”, anunciando que la plataforma pasaba a lo que Salesforce llama un modelo de ingeniería de mantenimiento. El texto es específico sobre lo que eso significa en la práctica: los contratos Enterprise Account ya no se ofrecerán a clientes nuevos, y el enfoque de ingeniería de aquí en adelante es “estabilidad, seguridad, confiabilidad y soporte”, con una declaración explícita de que esto llega “en lugar de introducir funciones nuevas”. Los clientes actuales, dice el texto, no ven ningún cambio inmediato: el precio, la facturación y el servicio del día a día siguen igual, y los contratos Enterprise existentes se siguen honrando y pueden renovarse. El propio encuadre de Salesforce para este giro es que está redirigiendo la inversión de producto e ingeniería hacia “las áreas donde podemos entregar el mayor valor de largo plazo al cliente”, específicamente productos de IA empresarial, que es la verdadera razón de negocio detrás del cambio, declarada con claridad en vez de inferida.
Esta es una historia distinta a los cambios de precio que otras plataformas han hecho este año, y merece tratarse distinto. Un precio que sube o una asignación de ancho de banda que se recorta es una cuestión de costo: haces la cuenta, decides si el nuevo número todavía funciona. Un software que deja de avanzar es un tipo de riesgo distinto, más lento, y vale la pena ser preciso sobre lo que realmente cambia en el día a día, en lugar de caer en “no hay nada de qué preocuparse” o “Heroku está muerto”, ninguno de los cuales es exacto.
¿Qué significa realmente “ingeniería de mantenimiento” para los usuarios de Heroku?
El término en sí no es exótico. Es un modo reconocido en el software comercial de vida larga: un producto que ya pasó su fase de crecimiento recibe un equipo más pequeño y dedicado cuyo trabajo es mantenerlo funcionando correctamente, parchado y seguro, sin el equipo que normalmente construiría lo que sigue. El propio texto de Heroku tiene cuidado de aclarar que esto no es un aviso de cierre. Las apps que ya están corriendo siguen corriendo. Los pipelines, los equipos y el ecosistema existente de add-ons se señalan explícitamente como no afectados. La facturación no cambia para los clientes que pagan con tarjeta de crédito a través del panel. Nada de esto es relaciones públicas; coincide con lo que significa la ingeniería de mantenimiento en cualquier otro lado donde se usa, y la redacción de Heroku evita exagerar o minimizar el asunto.
Lo que el texto sí confirma, directamente, es la parte que importa para cualquiera que esté planeando en torno a Heroku para los próximos años: sin funciones nuevas. No “menos”, no “un ritmo más lento”, la postura declarada es que el desarrollo de nuevas capacidades ya no es lo que hace el equipo. Combinado con la ausencia de contratos Enterprise nuevos para clientes nuevos, la lectura práctica es que Heroku como producto, a partir de febrero de 2026, no es algo que un equipo deba esperar que se mantenga al día con los desarrollos del resto del ecosistema de plataformas. Sea cual sea la forma que tenga el ecosistema de buildpacks en dos años, las regiones que agreguen las plataformas competidoras, o la función de base de datos administrada que se vuelva estándar en otros lados, la respuesta de Heroku a todo eso muy probablemente sea “eso no es algo que estemos construyendo”, porque el equipo que haría ese trabajo ya no lo está haciendo.
Qué cuesta esto en la práctica, para un equipo que sigue ahí hoy
Para un equipo con una app estable, crecimiento modesto, y sin planes de agregar nuevos tipos de carga de trabajo, esto genuinamente podría no importar durante bastante tiempo. El texto es honesto en que la funcionalidad existente sigue funcionando, y “estabilidad, seguridad, confiabilidad y soporte” es un compromiso real, no uno vacío, asumiendo que Salesforce lo cumpla. Los parches de seguridad para el stack de buildpacks existente, las correcciones de errores para funciones existentes, todo eso sigue explícitamente dentro del alcance.
La exposición aparece en unos cuantos lugares específicos y previsibles. El soporte de nuevos frameworks o entornos de ejecución de lenguajes es el primero: un equipo que adopta una versión nueva de un framework, o un entorno de ejecución que Heroku todavía no soporta, no tiene razón para esperar que Heroku lo agregue, porque eso es trabajo de función nueva por definición. Las regiones nuevas son el segundo: la expansión de infraestructura es desarrollo de producto, y una empresa en modo de mantenimiento no tiene razón declarada para construir regiones nuevas, lo cual importa para cualquier equipo cuyos requisitos de latencia o cumplimiento cambien a lo largo de la vida del producto. El tercero, y el que se acumula en silencio, es la capacidad de respuesta ante errores que no son críticos de seguridad: “estabilidad y confiabilidad” cubre mantener el comportamiento existente correcto, pero un error no crítico, incómodo más que peligroso, es justo el tipo de problema que un equipo más pequeño enfocado en mantenimiento razonablemente despriorizaría, porque para eso sirve una hoja de ruta recortada. Ninguno de estos es catastrófico por sí solo. Juntos, a lo largo de dos o tres años, describen una plataforma que se va quedando atrás en silencio respecto a la parte del ecosistema que todavía se desarrolla activamente, mientras sigue funcionando correctamente para exactamente la carga de trabajo que ya soportaba el día del anuncio.
Por qué esto es un riesgo estructural propio de rentar todo el stack
El punto más profundo no es sobre Heroku en particular, es sobre lo que significa depender por completo de la hoja de ruta de producto de una sola empresa para tu propia infraestructura. En una plataforma totalmente administrada, un cliente no tiene ninguna vía para seguir avanzando en las partes del servicio que valora si las prioridades del proveedor cambian. No hay un servidor que parchar uno mismo, ni una capa de infraestructura debajo del producto que el cliente todavía controle, todo es la hoja de ruta del proveedor, y cuando esa hoja de ruta se repriorizan, las capacidades futuras de cada cliente se repriorizan junto con ella, sin ninguna forma de optar por quedar fuera salvo abandonar la plataforma por completo.
Ese es el riesgo específico que representa la ingeniería de mantenimiento, y vale la pena ser justos sobre por qué Salesforce tomó esta decisión: una empresa de software empresarial en 2026 que redirige inversión hacia IA empresarial es una decisión de negocio racional dado el mercado, y Heroku, con casi dos décadas, es un producto maduro de forma bien conocida en lugar de una apuesta de crecimiento. Nada en la decisión es imprudente o deshonesto, el propio anuncio es inusualmente directo sobre qué cambia y por qué. El riesgo no es que Salesforce haya hecho algo mal. Es que cualquier cliente que esté completamente dentro del stack administrado de una sola empresa no tiene ninguna palanca que mover cuando las prioridades internas de esa empresa cambian, porque la infraestructura nunca fue suya para empezar.
Qué cambia un modelo de servidor propio respecto a este riesgo específico
Una plataforma que corre en servidores que el cliente posee no puede eliminar por completo este riesgo, el software del plano de control en sí lo sigue construyendo una empresa con su propia hoja de ruta y sus propias prioridades que podrían cambiar. Pero sí cambia lo que realmente está en juego si eso pasa. El servidor en sí, una máquina Linux ordinaria en DigitalOcean, Hetzner o Vultr, corriendo un contenedor Docker común detrás de un proxy inverso estándar, no se vuelve obsoleto porque cambie la hoja de ruta del plano de control. Si Railyard dejara de lanzar funciones nuevas mañana, las apps ya desplegadas siguen corriendo sobre infraestructura que el cliente ya posee y controla directamente por SSH, sin depender del desarrollo continuo de Railyard para seguir sirviendo tráfico. El peor escenario para un cliente en esa situación es perder el acceso a un panel y cierta comodidad de automatización, no perder la infraestructura donde realmente corre la app, porque esa infraestructura nunca fue del proveedor para empezar.
Esa es la respuesta estructural a “qué pasa si la empresa detrás de mi plataforma la despriorizan”, y es una respuesta notablemente distinta a cualquier cosa disponible para un cliente en una plataforma totalmente administrada. No requiere que Railyard, ni ninguna plataforma de servidor propio, prometa que esto nunca va a pasar aquí; requiere que la arquitectura haga sobrevivible la consecuencia si llega a pasar, lo cual es una garantía que un stack rentado no puede ofrecer sin importar qué tan bien administrado esté el proveedor.
La conclusión honesta
El anuncio de Heroku de febrero de 2026 no es una crisis para quien corre ahí hoy, y no es deshonesto ni está mal comunicado, si acaso es una declaración más directa que la que dan la mayoría de las empresas al despriorizar un producto maduro. La lección real es sobre el tipo de riesgo en sí: un equipo que depende por completo de una plataforma administrada también depende, por construcción, de que las decisiones internas de hoja de ruta de esa única empresa se mantengan alineadas indefinidamente con las propias necesidades del equipo, sin red si dejan de estarlo. Esa es una propiedad estructural real de rentar todo el stack, independiente de qué tan buenas o malas sean las intenciones de cualquier proveedor en particular, y vale la pena sopesarla en sus propios términos, por separado de cómo se vean el precio o el conjunto de funciones actuales el día que un equipo se registra.
Preguntas frecuentes
¿Cuándo entró Heroku en modo de ingeniería de mantenimiento? El director de producto de Heroku, Nitin T Bhat, anunció este cambio el 6 de febrero de 2026, en un texto titulado “An Update on Heroku”.
¿Va a cerrar Heroku? No. Las apps, pipelines, equipos y add-ons existentes siguen funcionando, y los clientes que pagan con tarjeta de crédito no ven ningún cambio en precio ni facturación. Ingeniería de mantenimiento significa sin funciones nuevas y sin contratos Enterprise nuevos para clientes nuevos, no un cierre.
¿Agregará Heroku funciones o regiones nuevas? El anuncio es explícito en que el desarrollo de funciones nuevas ya no es el enfoque del equipo, lo cual también significa que no debería esperarse soporte de nuevas regiones ni de nuevos frameworks o entornos de ejecución.
¿Es esto un riesgo mayor que una subida de precio? Es un tipo de riesgo distinto. Una subida de precio es una cuestión de costo que puedes calcular una sola vez. Una plataforma que deja de avanzar es un riesgo que se acumula lentamente durante años, mientras el resto del ecosistema sigue lanzando novedades y una plataforma congelada no.
Fuentes
- Heroku: “An Update on Heroku”, por Nitin T Bhat, director de producto, publicado el 6 de febrero de 2026, el anuncio propio de Heroku y Salesforce
- DeployHQ: “Heroku Enters Sustaining Engineering Mode: What It Means and When to Consider Alternatives”, análisis de las implicaciones prácticas
- DevClass: “Heroku future in doubt as Salesforce freezes features to focus on AI”, cobertura independiente del anuncio de febrero de 2026
- La propia página de cómo funciona de Railyard sobre correr aplicaciones directamente en infraestructura que tú controlas
Mira cómo se compara Railyard específicamente para un equipo que está evaluando un cambio: Compara Railyard con Heroku, o mira cómo corre Railyard sobre servidores que tú posees.