O Heroku agora está em modo de engenharia de manutenção, e isso é um tipo de risco diferente de um aumento de preço

Em 6 de fevereiro de 2026, o diretor de produto do Heroku, Nitin T Bhat, publicou um texto curto intitulado “An Update on Heroku”, anunciando que a plataforma estava passando para o que a Salesforce chama de modelo de engenharia de manutenção. O texto é específico sobre o que isso significa na prática: contratos Enterprise Account não serão mais oferecidos a novos clientes, e o foco de engenharia daqui em diante é “estabilidade, segurança, confiabilidade e suporte”, com uma declaração explícita de que isso vem “em vez de introduzir novos recursos”. Os clientes atuais, diz o texto, não veem nenhuma mudança imediata: preço, cobrança e serviço do dia a dia continuam os mesmos, e os contratos Enterprise existentes continuam sendo honrados e podem ser renovados. O próprio enquadramento da Salesforce para essa virada é que ela está redirecionando investimento de produto e engenharia para “as áreas onde podemos entregar o maior valor de longo prazo ao cliente”, especificamente produtos de IA empresarial, que é a verdadeira razão de negócio por trás da mudança, declarada com clareza em vez de inferida.

Essa é uma história diferente das mudanças de preço que outras plataformas fizeram este ano, e merece ser tratada diferente. Um preço que sobe ou uma alocação de banda que é cortada é uma questão de custo: você faz a conta, decide se o novo número ainda funciona. Um software que para de avançar é um tipo de risco diferente, mais lento, e vale a pena ser preciso sobre o que isso realmente muda no dia a dia, em vez de cair em “não há nada com que se preocupar” ou “o Heroku está morto”, nenhum dos dois exato.

O que “engenharia de manutenção” realmente significa para usuários do Heroku?

O termo em si não é exótico. É um modo reconhecido em software comercial de vida longa: um produto que já passou da fase de crescimento recebe uma equipe menor e dedicada cujo trabalho é mantê-lo funcionando corretamente, atualizado e seguro, sem a equipe que normalmente construiria o que vem a seguir. O próprio texto do Heroku tem o cuidado de deixar claro que isso não é um aviso de encerramento. As aplicações que já estão rodando continuam rodando. Pipelines, equipes e o ecossistema existente de add-ons são explicitamente apontados como não afetados. A cobrança não muda para clientes que pagam com cartão de crédito pelo painel. Nada disso é discurso de marketing; combina com o que engenharia de manutenção significa em qualquer outro lugar onde é usada, e a redação do Heroku evita exagerar ou minimizar a questão.

O que o texto confirma diretamente é a parte que importa para quem está planejando em torno do Heroku para os próximos anos: nenhum recurso novo. Não “menos”, não “um ritmo mais lento”, a postura declarada é que o desenvolvimento de novas capacidades não é mais o que a equipe faz. Combinado com a ausência de novos contratos Enterprise para novos clientes, a leitura prática é que o Heroku como produto, a partir de fevereiro de 2026, não é algo que uma equipe deveria esperar que acompanhe o ritmo dos desenvolvimentos do resto do ecossistema de plataformas. Seja qual for a cara do ecossistema de buildpacks daqui a dois anos, quais regiões as plataformas concorrentes adicionarem, ou qual recurso de banco de dados administrado se tornar padrão em outros lugares, a resposta do Heroku a tudo isso muito provavelmente será “isso não é algo que estamos construindo”, porque a equipe que faria esse trabalho não está mais fazendo esse trabalho.

O que isso custa na prática, para uma equipe que ainda está lá hoje

Para uma equipe com uma aplicação estável, crescimento modesto, e sem planos de adicionar novos tipos de carga de trabalho, isso genuinamente pode não importar por bastante tempo. O texto é honesto ao dizer que a funcionalidade existente continua funcionando, e “estabilidade, segurança, confiabilidade e suporte” é um compromisso real, não uma casca vazia, assumindo que a Salesforce cumpra. Correções de segurança para o stack de buildpacks existente, correções de bugs para recursos existentes, tudo isso continua explicitamente dentro do escopo.

A exposição aparece em alguns lugares específicos e previsíveis. O suporte a novos frameworks ou runtimes de linguagem é o primeiro: uma equipe que adota uma versão nova de um framework, ou um runtime de linguagem que o Heroku ainda não suporta, não tem razão para esperar que o Heroku o adicione, porque isso é trabalho de recurso novo por definição. Novas regiões são o segundo: expansão de infraestrutura é desenvolvimento de produto, e uma empresa em modo de manutenção não tem razão declarada para construir novas regiões, o que importa para qualquer equipe cujos requisitos de latência ou conformidade mudem ao longo da vida do produto. O terceiro, e o que se acumula em silêncio, é a capacidade de resposta a bugs que não são críticos de segurança: “estabilidade e confiabilidade” cobre manter o comportamento existente correto, mas um bug não crítico, incômodo mais do que perigoso, é exatamente o tipo de problema que uma equipe menor focada em manutenção razoavelmente despriorizaria, porque é para isso que serve um roadmap reduzido. Nenhum desses pontos é catastrófico sozinho. Juntos, ao longo de dois ou três anos, descrevem uma plataforma que fica silenciosamente para trás em relação à parte do ecossistema ainda ativamente desenvolvida, enquanto continua funcionando corretamente para exatamente a carga de trabalho que já suportava no dia do anúncio.

Por que isso é um risco estrutural próprio de alugar toda a pilha

O ponto mais profundo não é sobre o Heroku em particular, é sobre o que significa depender por completo do roadmap de produto de uma única empresa para sua própria infraestrutura. Em uma plataforma totalmente administrada, um cliente não tem nenhum caminho para continuar avançando as partes do serviço que valoriza se as prioridades do fornecedor mudarem. Não há servidor para corrigir por conta própria, nenhuma camada de infraestrutura abaixo do produto que o cliente ainda controle, é inteiramente o roadmap do fornecedor, e quando esse roadmap é repriorizado, as capacidades futuras de cada cliente são repriorizadas junto, sem forma de optar por ficar de fora a não ser abandonando a plataforma por completo.

Esse é o risco específico que a engenharia de manutenção representa, e vale a pena ser justo sobre por que a Salesforce tomou essa decisão: uma empresa de software empresarial em 2026 redirecionando investimento para IA empresarial é uma decisão de negócio racional dado o mercado, e o Heroku, com quase duas décadas, é um produto maduro de forma bem conhecida em vez de uma aposta de crescimento. Nada na decisão é imprudente ou desonesto, o próprio anúncio é incomumente direto sobre o que muda e por quê. O risco não é que a Salesforce tenha feito algo errado. É que qualquer cliente totalmente dentro da pilha administrada de uma única empresa não tem nenhuma alavanca para puxar quando as prioridades internas dessa empresa mudam, porque a infraestrutura nunca foi dele para começar.

O que um modelo de servidor próprio muda nesse risco específico

Uma plataforma que roda em servidores que o cliente possui não pode eliminar por completo esse risco, o próprio software do plano de controle ainda é construído por uma empresa com seu próprio roadmap e suas próprias prioridades que podem mudar. Mas muda o que realmente está em jogo se isso acontecer. O servidor em si, uma máquina Linux comum na DigitalOcean, Hetzner ou Vultr, rodando um contêiner Docker comum atrás de um proxy reverso padrão, não fica obsoleto porque o roadmap do plano de controle mudou. Se a Railyard parasse de lançar recursos novos amanhã, as aplicações já implantadas continuam rodando em infraestrutura que o cliente já possui e controla diretamente por SSH, sem depender do desenvolvimento contínuo da Railyard para continuar servindo tráfego. O pior cenário para um cliente nessa situação é perder o acesso a um painel e alguma conveniência de automação, não perder a infraestrutura onde a aplicação realmente roda, porque essa infraestrutura nunca foi do fornecedor para começar.

Essa é a resposta estrutural para “o que acontece se a empresa por trás da minha plataforma a despriorizar”, e é uma resposta notavelmente diferente de qualquer coisa disponível para um cliente em uma plataforma totalmente administrada. Não exige que a Railyard, ou qualquer plataforma de servidor próprio, prometa que isso nunca vai acontecer aqui; exige que a arquitetura torne a consequência sobrevivível se acontecer, o que é uma garantia que uma pilha alugada não pode oferecer não importa quão bem administrado seja o fornecedor.

A conclusão honesta

O anúncio do Heroku de fevereiro de 2026 não é uma crise para quem roda lá hoje, e não é desonesto nem mal comunicado, se alguma coisa é uma declaração mais direta do que a maioria das empresas dá ao despriorizar um produto maduro. A lição real é sobre o tipo de risco em si: uma equipe que depende por completo de uma plataforma administrada também depende, por construção, de que as decisões internas de roadmap dessa única empresa permaneçam alinhadas indefinidamente com as próprias necessidades da equipe, sem rede de proteção se deixarem de estar. Essa é uma propriedade estrutural real de alugar toda a pilha, independente de quão boas ou más sejam as intenções de qualquer fornecedor em particular, e vale a pena pesá-la em seus próprios termos, separadamente de como o preço ou o conjunto de recursos atuais parecem no dia em que uma equipe se cadastra.

Perguntas frequentes

Quando o Heroku entrou em modo de engenharia de manutenção? O diretor de produto do Heroku, Nitin T Bhat, anunciou essa mudança em 6 de fevereiro de 2026, em um texto intitulado “An Update on Heroku”.

O Heroku vai fechar? Não. Aplicações, pipelines, equipes e add-ons existentes continuam funcionando, e clientes que pagam com cartão de crédito não veem nenhuma mudança de preço ou cobrança. Engenharia de manutenção significa nenhum recurso novo e nenhum contrato Enterprise novo para novos clientes, não um encerramento.

O Heroku vai adicionar recursos ou regiões novas? O anúncio é explícito ao dizer que o desenvolvimento de recursos novos não é mais o foco da equipe, o que também significa que não se deve esperar suporte a novas regiões nem a novos frameworks ou runtimes.

Isso é um risco maior do que um aumento de preço? É um tipo de risco diferente. Um aumento de preço é uma questão de custo que você pode calcular uma única vez. Uma plataforma que para de avançar é um risco que se acumula lentamente ao longo de anos, enquanto o resto do ecossistema continua lançando novidades e uma plataforma congelada não.

Fontes

• Heroku: “An Update on Heroku”, por Nitin T Bhat, diretor de produto, publicado em 6 de fevereiro de 2026, o anúncio próprio do Heroku e da Salesforce
• DeployHQ: “Heroku Enters Sustaining Engineering Mode: What It Means and When to Consider Alternatives”, análise das implicações práticas
• DevClass: “Heroku future in doubt as Salesforce freezes features to focus on AI”, cobertura independente do anúncio de fevereiro de 2026
• A própria página de como funciona da Railyard sobre rodar aplicações diretamente em infraestrutura que você controla

Veja como a Railyard se compara especificamente para uma equipe avaliando uma mudança: Compare a Railyard com o Heroku, ou veja como a Railyard roda em servidores que você possui.