Heroku DevOps Services, App Maintenance and Migration Planning
Heroku still runs, still gets security patches, and is no longer on a growth roadmap. Heroku's own March 2026 update confirms the platform has "transitioned to a Sustaining Engineering model", with the stated mission of providing "the most stable, secure, and reliable environment for your apps and data". Heroku says it will continue releasing features and functionality, but only those that align with its Sustaining Engineering goals. In practice that means the platform's effort goes into security, stability and reliability rather than into new capability.
That changes what a Heroku engagement is for. Mixcore Studio does two things here. We keep existing Heroku applications healthy, patched and affordable for as long as you choose to stay, and we plan and execute the move when you decide to leave. We do not recommend Heroku for a new build in 2026, and we say so before you spend money finding out. Our team has shipped production software for more than 8 years, and most of this work is ordinary release engineering rather than anything exotic.
What Sustaining Engineering actually means for your app
It is not a shutdown notice, and nothing about your running application changed on the day of the announcement. Pricing is unchanged as well. Eco is $5 a month, Basic $7, Standard-1X $25 for 0.5 GB, Standard-2X $50 for 1 GB, and the Performance tier runs from $250 a month for Performance-M up to $1,500 for Performance-2XL, verified on heroku.com/pricing in August 2026.
What you lose is forward motion. You should not expect major new runtime capabilities, a platform answer to workloads Heroku never covered such as GPU inference, or a roadmap moving toward what your architecture will need in two or three years. The risk is not an outage next quarter. It is standing still while everything around the platform keeps moving, and discovering the cost of that in a year when you also have a product deadline.
Keeping an existing Heroku estate in good order
- Dyno right-sizing — matching dyno type and count to measured load rather than to whatever was provisioned during a launch panic, and removing dynos that no longer serve traffic.
- Add-on audit — every add-on is a separate vendor, a separate bill and a separate migration obstacle later. We list them, price them and mark the ones that have quietly become unused.
- Heroku Postgres care — plan sizing against real connection counts, connection pooling, backups verified by actual restore rather than by the presence of a backup job, and followers where read load justifies them.
- Pipelines and review apps — staging that resembles production, review apps on pull requests, and release-phase migrations that fail safely instead of half-applying.
- OpenTelemetry instrumentation — the CNCF announced OpenTelemetry's graduation on 21 May 2026, with over 12,000 contributors from more than 2,800 companies. Instrumenting with OTel now means your traces, metrics and logs survive both a vendor change and a platform change.
- Credential hygiene — config vars rotated on a schedule, CI credentials made short-lived, and no long-lived tokens sitting in a build environment.
Two dated obligations sit on top of this regardless of which platform you run on. From 11 September 2026 the EU Cyber Resilience Act requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents through the CRA Single Reporting Platform, with a 24-hour early warning, a 72-hour notification, and a final report within 14 days of a fix being available for an exploited vulnerability or within one month of the notification for a severe incident. Separately, the CHAINDROP worm discovered on 4 August 2026 backdoored more than 400 npm packages through stolen maintainer credentials, including keyv at over 600 million monthly downloads (Elastic Security Labs, August 2026). The defences are unglamorous and effective. Short-lived OIDC-based publishing credentials, a soak period before adopting new package versions, npm 12 or later so preinstall hooks are blocked by default, and an SBOM plus SLSA v1.2 provenance produced by the pipeline rather than assembled at audit time.
Planning the exit without panic-migrating
The honest advice for most Heroku customers is to plan the exit rather than rush it. A migration is engineering time taken directly from your product roadmap, and doing it badly during a busy quarter is a worse outcome than staying another year on a platform that still receives security patches.
The sequence we use is inventory first, then a dependency map of everything that relies on Heroku-specific behaviour, then a costed comparison of two or three realistic targets, then one low-risk service moved end to end before anything important follows it. That first move is where you find out what the real cost is, and it is cheap to learn on a background worker instead of on checkout.
Portability is worth pricing while you plan. Under the EU Data Act, cloud switching charges, expressly including egress fees for the switch itself, are completely prohibited in the EU from 12 January 2027. That has made "what does leaving cost" a normal procurement question rather than an awkward one, and it is a reasonable question to ask of whichever platform you move to next.
Where Heroku applications go in 2026
- Render, Railway and Fly.io — closest to the Heroku developer experience, with buildpack or Dockerfile builds and managed Postgres. The usual choice when the goal is to keep the team's workflow intact.
- DigitalOcean App Platform — a managed platform with a straightforward price list and a business still investing. DigitalOcean reported Q2 2026 revenue of $281 million, up 29% year over year, with a record $93 million in incremental ARR (DigitalOcean Q2 2026 results, 4 August 2026).
- Cloudflare Workers and Containers — a good fit for request-and-response workloads and anything latency-sensitive at the edge. Node.js compatibility is on by default for compatibility dates from 4 August 2026, which removes a common porting obstacle.
- Managed container services on a hyperscaler — ECS or Fargate, Cloud Run, Azure Container Apps. Sensible when you already have data or identity on that provider.
- Managed Kubernetes behind a paved road — the right answer at a certain service count and team size, and over-engineering below it. The CNCF 2025 Annual Cloud Native Survey, published 20 January 2026, found 82% of container users now run Kubernetes in production. Kubernetes also carries an upgrade treadmill. Version 1.34 reaches end of life on 27 October 2026 and 1.35 on 28 February 2027.
We will not put a five-service application on a bespoke Kubernetes cluster and call it modernisation. If a managed platform does the job, that is the recommendation, and we will give you the operating cost of each option in engineer-hours per month rather than in adjectives.
What actually breaks when you leave Heroku
- Ephemeral filesystem assumptions — code that writes to disk and relies on that disk disappearing, or worse, code that quietly relies on it persisting between requests on the same dyno.
- The 30-second request limit — applications shaped around it often hide long operations in odd places, and those need to become proper background jobs on the way out.
- Buildpacks — slug builds become container images. This is usually a day of work and occasionally a week, depending on native dependencies and asset pipelines.
- Add-ons — each one is an independent decision. Redis, mail delivery, log drains, schedulers and monitoring all need a replacement chosen and tested, not assumed.
- Config vars — a flat list of environment variables becomes a secrets manager with rotation and access control, which is an improvement that still costs time.
- Release phase and the Procfile — migrations, worker definitions and scheduled jobs move into whatever the new platform's deployment model is, and the failure behaviour is rarely identical.
- Heroku Postgres — the database cutover is the part that needs a rehearsal. Extensions, connection limits, logical replication or dump-and-restore, and a cutover window with a tested rollback.
When staying on Heroku is the right call
If you run a small internal tool on a $25 a month Standard-1X dyno, traffic is flat, the stack is stable and nobody is asking for new capabilities, migrating is probably a poor use of money. The engineering days required will exceed several years of hosting savings, and the platform is still being patched. Staying is a defensible decision, provided it is a decision rather than an oversight, and provided somebody has written down the conditions that would change it.
Move sooner if any of the following is true. You need capabilities the platform is unlikely to add, particularly around GPU or inference workloads. You are growing into the upper Performance tiers, where the price comparison against managed containers stops being close. Or your architecture is heading somewhere a platform in maintenance mode cannot follow, in which case the migration is going to happen anyway and doing it deliberately costs less than doing it under pressure.
The other honest caveat is about cost discipline generally. The Flexera 2026 State of the Cloud Report estimates 29% of IaaS and PaaS spend is wasted, the first increase after five years of decline. Moving off Heroku onto a platform with more knobs will not reduce your bill by itself. It reduces the bill only if someone owns the numbers afterwards, which is a scope item we would rather agree up front than discover later.
Our expertise
- Dyno and add-on audit
- Heroku Postgres migration
- Costed exit planning
- Pipelines and release automation
- Cost and capacity review
- Supply chain and CRA readiness
Frequently asked questions
Is Heroku shutting down?
No. Heroku's March 2026 update confirms the platform has moved to a Sustaining Engineering model, which means the effort goes into security, stability and reliability rather than into new platform capability. Existing applications keep running and keep receiving patches, and list pricing is unchanged. What ended is the forward roadmap.
Do we need to migrate off Heroku right now?
For most applications, no. The platform is still patched, so an unplanned rush is usually the worse outcome. The sensible approach is to plan the exit, price it, and write down the conditions that would trigger it. Move sooner if you need capabilities the platform is unlikely to add, or if you are growing into the upper Performance tiers where the price comparison stops being close.
Where do you migrate Heroku applications to?
It depends on how much of the Heroku developer experience you want to keep. Render, Railway and Fly.io are the closest equivalents. DigitalOcean App Platform suits teams that want a simple price list. Cloudflare Workers and Containers fit request-and-response workloads well. Managed container services such as Fargate, Cloud Run or Azure Container Apps make sense when your data already lives with that provider. Managed Kubernetes is the right answer at a certain scale and over-engineering below it.
What usually breaks when moving an application off Heroku?
The recurring items are assumptions about the ephemeral filesystem, code shaped around the 30-second request limit, buildpacks becoming container images, add-ons that each need an individually chosen replacement, config vars becoming a proper secrets manager, release-phase migrations moving into a new deployment model, and the Heroku Postgres cutover. The database is the part that needs a rehearsal and a tested rollback.
How long does a Heroku migration take, and who operates it afterwards?
A single well-understood service typically moves in a few weeks including rehearsal. A multi-service application with several add-ons and a large Postgres database is usually a few months, and the add-on replacements often take longer than the application itself. We hand over runbooks, infrastructure as code and OpenTelemetry-based monitoring so your own team can operate the result, rather than leaving you dependent on the agency that performed the move.
Contacts
We are always happy to talk with you.
Feel free to contact us in any suitable way
Request a quote
Let's discuss your project!
Please, provide us with a brief description of what you
already have and what you are going to achieve.
Mail us contact@brainiacminds.com