Heroku Enters Sustaining Engineering - What It Means and Where Your Rails App Can Go Next
On February 6, 2026, Heroku announced it is transitioning to a "sustaining engineering model," focused on stability, security, reliability, and support, rather than introducing new features. Heroku describes itself as remaining "actively supported" and "production ready," but new Enterprise Account contracts will no longer be offered to new customers.
If your Rails application is running on Heroku today, it's worth understanding what this means and considering your options.
What "Sustaining Engineering" Actually Means
Let's look at what was actually announced.
Salesforce's SVP and GM Nitin T. Bhat described Heroku's new status as "an actively supported, production ready platform, with an emphasis on maintaining quality and operational excellence rather than introducing new features." Existing customers can continue to use the platform and renew subscriptions. Customers who pay via credit card in the Heroku dashboard, both existing and new, can continue with no changes to pricing, billing, service, or day-to-day usage.
But new Enterprise Account contracts are no longer available to new customers. New feature development is explicitly de emphasised in favour of stability, security, reliability, and support. Salesforce's public messaging strongly emphasises Agentforce and enterprise AI; given Heroku's shift to sustaining engineering, it's reasonable to infer Heroku is no longer a growth investment.
If you've been in this industry long enough, you've seen similar patterns before. When a platform shifts to sustaining engineering with no new enterprise sales, the long term trajectory tends to be a gradual wind down, even if no shutdown date is set. Analysts at Greyhound Research have described sustaining engineering as "rarely a stable equilibrium, rather a holding pattern" before eventual absorption or shutdown (InfoWorld). Independent analyst Michael Warrilow told The Register that Heroku's "exorbitant pricing killed it and Agentforce put the nail in the coffin," advising migration. Similar precedents include IBM's Bluemix shifting to maintenance before being absorbed into Red Hat OpenShift, and VMware's Pivotal Cloud Foundry entering sustain mode before being folded into Tanzu.
The question for Rails teams isn't whether Heroku will shut down imminently, nothing in the announcement suggests that. The question is whether building on a platform with feature development de emphasised is the right long term choice.
Why This Matters for Rails Teams
Heroku and Rails have a shared history. Heroku began in 2007 with Ruby as its initial focus. For over a decade, git push heroku main was the canonical deployment story for Rails developers.
But the platform has been showing signs of decline for years. Free plans were removed on November 28, 2022. That same year, stolen OAuth user tokens issued to Heroku's GitHub integration were abused to download data from repositories at multiple organisations, and the incident drew public criticism of Heroku's communications from parts of the developer community. The June 10, 2025 incident caused up to approximately 24 hours of downtime for many customers. The Heroku-20 stack reached end of life on April 30, 2025, with builds blocked from May 1, 2025 until apps upgrade stacks.
Meanwhile, the Rails ecosystem has moved forward. Rails 8.1.2 (released January 2026) highlights Kamal deployment improvements, including registry free Kamal deployments. Ruby 4.0.x is the current stable series (4.0.0 released December 25, 2025; 4.0.1 patch released January 13, 2026). YJIT, the just in time compiler that Shopify has publicly described as production ready since Ruby 3.2, continues to deliver meaningful performance improvements. It is enabled by default in recent Rails versions. Ruby 4.0 also introduces experimental features like ZJIT (a next-generation JIT compiler, not yet recommended for production) and Ruby Box (an isolation mechanism for definitions). The community is increasingly building for a world beyond Heroku.
If you're still deploying to Heroku, you're building on a platform where feature investment is de emphasised while the tools and alternatives around it are maturing rapidly.
The Migration Options
Every Rails application is different, but the realistic migration targets fall into three categories: self hosted deployment with Kamal, managed PaaS alternatives, and cloud infrastructure.
Option 1: Kamal (The Rails Native Choice)
Kamal is a deployment tool created by the team at 37signals, the company behind Basecamp, HEY, and Ruby on Rails. Rails 8.1 highlights Kamal deployment improvements (including registry free deployments), and Kamal uses Docker containers deployed over SSH to any server you control.
What you get:
Rolling deployments designed to minimise downtime, with health checks to verify each deploy. Automatic SSL certificate management via Let's Encrypt through kamal-proxy. Support for running multiple apps on the same host (kamal proxy routes traffic based on hostname). A YAML based configuration (config/deploy.yml) that defines your deployment infrastructure, including built-in accessory service management for databases, Redis, and other services alongside your application.
What it costs:
A Hetzner CPX11 server starts at approximately €4.49/month (excluding VAT; pricing varies by location and IPv4 options). A DigitalOcean 2 GiB basic droplet runs $12/month. These are significantly cheaper than equivalent Heroku configurations, though exact savings depend on your specific Heroku plan, add ons, and usage.
Kamal is the toolkit 37signals uses to run HEY and all their formerly cloud hosted applications on their own hardware, which provides confidence in its maturity at scale.
The trade-off:
You own the infrastructure. That means you're responsible for server updates, security patches, monitoring, and scaling. Kamal focuses on deployment; kamal-proxy exposes a Prometheus metrics endpoint, but you'll typically add separate tooling for log aggregation and dashboards. Docker familiarity is strongly helpful (and often necessary for troubleshooting). You'll need a container registry, though Rails 8.1 introduced registry-free deployment support via a local registry approach.
More suitable for: Teams with some infrastructure experience who want maximum control and significant cost savings. Rails 8 applications that want to stay close to the framework's conventions.
Option 2: Managed PaaS (The Heroku-Like Experience)
If the reason you chose Heroku was the simplicity of git push deployment and not having to think about servers, several platforms now offer a comparable experience.
Render provides the closest Heroku like workflow (in my experience, yours may vary). Push to deploy workflows, managed PostgreSQL with point in time recovery (on paid tiers), built in metrics and logging, and plan based pricing plus usage based compute costs prorated to the second. Render abstracts away the underlying cloud infrastructure entirely.
Fly.io deploys applications as lightweight VMs across multiple regions worldwide, close to your users. The CLI-first approach gives you more control than Render, and it excels at latency-sensitive, globally distributed workloads. Pricing is usage based with VMs starting under $2/month for the smallest tier.
Railway offers a visual, canvas based deployment experience with usage based pricing. It's fast to set up and has a strong template marketplace, though teams with production scale requirements may find gaps in areas like job orchestration and advanced observability.
The trade-off:
You're trading one managed platform for another. The vendor lock in concern doesn't disappear; it just shifts. These platforms are all competing in a fast-moving market. Pricing can change, features can evolve, and none of them have the operating history that Heroku built since 2007.
More suitable for: Small teams, MVPs, applications where deployment simplicity matters more than cost optimisation or infrastructure control.
Option 3: Cloud Infrastructure (AWS, GCP, DigitalOcean)
For larger applications or teams with existing cloud infrastructure, deploying directly to AWS (ECS, Elastic Beanstalk, or EC2), GCP (Cloud Run, GKE), or DigitalOcean (App Platform, managed Kubernetes) provides the most flexibility.
The trade-off:
Maximum control and scalability, but significantly more operational complexity. This is the right choice if you have dedicated DevOps capacity or if your application's requirements have outgrown what simpler platforms can offer.
More suitable for: Enterprise applications, teams with dedicated infrastructure engineers, applications with specific compliance or scaling requirements.
Self Hosted PaaS (The Middle Ground)
Worth mentioning: tools like Dokku, Coolify, and Dokploy offer a self-hosted PaaS experience. Dokku has been around since 2013 and provides a Heroku compatible git push workflow using Heroku buildpacks on your own server. Coolify is an open-source, self-hostable alternative to Heroku with a web dashboard, Git integration, automatic SSL, and support for deploying to any server via SSH. These strike a balance between the simplicity of a PaaS and the cost savings of self-hosting.
A Practical Migration Framework
Having migrated Rails applications off various platforms over the years, here's the approach I recommend:
1. Audit your Heroku dependencies.
List every Heroku add on you use: Postgres, Redis, Elasticsearch, monitoring, logging, email, scheduled jobs. Each one needs a replacement. Some, like Postgres, are straightforward. Others, like Heroku Connect for Salesforce data sync, require more careful planning.
2. Containerise your application.
Rails 7.1 introduced improved first-party Docker support, including a production ready Dockerfile template generated by rails new. For older versions, create a multi-stage Dockerfile that builds your assets and runs Puma. Test it locally before you deploy anywhere.
3. Extract your data.
Heroku's PGBackups feature uses the native pg_dump tool to create backup files, making it straightforward to export to other PostgreSQL installations. You can also run pg_dump directly against your Heroku Postgres database. Plan for downtime during the final data migration, or use logical replication for zero-downtime migration if your dataset is large.
4. Set up your target environment.
Whether it's Kamal on a VPS, Render, or AWS, get your application running with a copy of your production data before you switch DNS.
5. Run parallel environments.
Keep Heroku running while your new environment is tested. Route a percentage of traffic to the new setup if possible. Monitor error rates, response times, and background job throughput.
6. Cut over.
Update DNS, verify everything works, and decommission Heroku. Keep your Heroku app available as a fallback for at least a week.
My Recommendation
For most small Rails apps, Kamal on a VPS is the right answer. It aligns with where Rails is heading as a framework. It reduces recurring platform fees. It gives you full control over your infrastructure. And with Rails 8.1 highlighting Kamal deployment improvements and documenting registry free workflows, the community support and documentation are stronger than ever.
If your team genuinely doesn't want to manage servers, Render is the strongest Heroku alternative. It offers the closest experience to what Heroku provided at its best, without the uncertainty of a platform in sustaining mode.
The one option I'd caution against is staying on Heroku indefinitely without a contingency plan. While the platform remains operational today, the risk profile has changed: feature development is de emphasised, new Enterprise Account contracts are no longer offered to new customers, and Salesforce's investment priorities have clearly shifted.
Need help migrating off Heroku?
I help Rails teams plan and execute platform migrations, from Heroku to Kamal, Render, or cloud infrastructure, without risking production. Whether you need a full migration or just a technical assessment to understand your options, get in touch at wm@wagnermatos.co.uk.