Is Heroku shutting down?

No. Heroku announced a transition to sustaining engineering mode in February 2026, which means the platform is in maintenance mode: security patches, operational continuity, and support for existing customers. What ends is active feature development and new enterprise contracts for new customers.

The platform runs. Credit card customers continue without interruption. Existing enterprise contracts are honored and can renew.

The distinction that matters for planning: Heroku is no longer being built. It's being preserved. For teams making 12 to 36 month infrastructure decisions, that matters. For teams with stable workloads and no near-term compliance or enterprise pressure, it changes relatively little in the immediate term.

→ See: What's Happening at Heroku

What does "sustaining engineering" mean in practice for feature velocity and roadmap?

Sustaining engineering is a product lifecycle term for maintenance mode. The engineering team's focus shifts from shipping new capabilities to keeping existing capabilities running: patching security vulnerabilities, maintaining operational stability, and preserving what already works.

In practice: features that were missing before the announcement are still missing. Long-standing roadmap requests are unlikely to ship. Compliance gaps that exist today are unlikely to close. Platform capabilities that were on the horizon are off the table.

For teams that were waiting on specific features, this is a definitive answer. For teams evaluating Heroku for new deployments, the announcement is a clear signal to evaluate elsewhere instead.

→ See: What's Happening at Heroku

If nothing changes for current customers, why should I do anything?

Because "nothing changes today" and "nothing changes over the next three years" are very different statements.

Today's operational picture is stable. The long-term planning picture is not. A platform in sustaining mode doesn't improve relative to its alternatives. The innovation gap between Heroku and actively developing platforms only widens. Compliance posture that doesn't evolve becomes relatively weaker as auditor expectations and enterprise requirements advance.

The teams that get into trouble are the ones that defer every decision until a forcing event makes it urgent: an outage, an audit, an enterprise deal with security requirements the platform can't cleanly answer. At that point the decision is no longer deliberate. A controlled migration is far cheaper than an emergency one.

The productive response to "nothing changes today" isn't action. It's planning.

→ See: Should You Migrate?

Who should stay on Heroku and what minimum planning should they do?

Staying is rational when production is stable, costs are predictable, compliance pressure is low, and no major architecture changes are planned in the next 12 months. Small teams with simple workloads and no enterprise sales cycle have the least urgency.

Staying intentionally requires a decision, not just inertia. At minimum: write a one-page internal memo documenting what you're running, what you're paying, what your compliance exposure is, and what conditions would trigger a migration evaluation. Inventory your add-ons and databases. Set a 12 to 24 month planning horizon. Review it quarterly.

The difference between "staying by choice" and "staying by default" is that memo.

→ See: Should You Migrate?

What are the strongest triggers to plan a migration vs. migrate immediately?

Plan but don't rush:

• Cost trending upward but not yet a crisis

• Platform stagnation creating friction but not blocking work

• Enterprise deals starting to include security reviews

• Compliance requirements slowly rising

• Sustaining engineering announcement adding weight to existing doubts

Delay increases risk:

• First enterprise deal with a formal security questionnaire your current platform can't cleanly answer

• SOC 2 or HITRUST in scope

• Major contract renewal approaching (start evaluating before, not at, the renewal)

• Major architecture refactor underway (natural migration window)

• Compliance gaps that can't close under a frozen roadmap

Even "migrate now" should mean a phased, controlled migration. Urgency is not a reason to skip the inventory and rollback planning.

→ See: Should You Migrate?

What's the hardest part of migrating off Heroku and how do we reduce downtime?

The hardest part is almost always the database migration, not the application migration. Moving a large Postgres database with minimal downtime requires either accepting a maintenance window (dump and restore) or setting up logical replication, which has its own complexity on Heroku due to limited direct replication control.

The second-hardest part is discovering what you didn't inventory: build-time secrets that aren't in your run-time config, add-on behavior that your application code assumes, and APM agents that stop working in the new environment.

To reduce downtime: run environments in parallel with a side-by-side migration, lower DNS TTL 48 to 72 hours before cutover, and treat the cutover window like a production incident with pre-defined rollback triggers. DNS-based cutover means rollback is a DNS change, not a database restore.

→ See: Migration Guide

How should we evaluate alternatives if we're in a regulated or HIPAA environment?

Start with the compliance non-negotiables before anything else: BAA availability, isolation model, encryption at rest and in transit, and audit logging depth. These should be confirmed before you invest time in developer experience evaluation.

The key distinction is between compliance as a platform default versus compliance as an add-on tier. On platforms where compliance is a default, isolation and audit evidence are produced automatically. On platforms where compliance is a tier, you're layering controls onto infrastructure that wasn't designed with compliance as the primary assumption.

For teams with formal audit requirements or expanding enterprise deals, the distinction matters in practice. Heroku Shield is an add-on tier. Aptible is a platform default.

Also evaluate: what audit evidence does the platform produce automatically? What do you have to build yourself? For teams going through annual audits and enterprise security questionnaires repeatedly, the difference in evidence generation effort compounds quickly.

→ See: Heroku and HIPAA, Heroku vs. Aptible

Should we move to a Heroku-like PaaS or go straight to AWS/GCP?

Depends on whether you have, or want to hire, platform engineering capacity.

A Heroku-like PaaS (Render, Railway, Fly.io) preserves the managed infrastructure model. Lower operational burden, lower complexity, less control. The right choice if your team doesn't want to own networking, IAM, CI/CD governance, and observability as permanent engineering work.

AWS or GCP gives you maximum control and maximum responsibility. The right choice if you have engineers who can own the platform layer and your architecture requires capabilities that PaaS platforms don't expose. The trap is underestimating the fully-loaded cost: a platform engineer who can own this stack costs more annually than the infrastructure savings at most startup scales.

Most teams that leave Heroku for AWS and regret it did so because they underestimated the operational responsibility transfer. Most teams that move to a Heroku-like PaaS first and later move to AWS do so deliberately, after they've grown into the operational maturity the cloud requires.

→ See: PaaS Alternatives, DIY Cloud

How do we migrate Postgres safely: dump and restore vs. logical replication?

Dump and restore is simpler and more reliable. It requires a maintenance window while the restore runs. For databases under roughly 10GB, this is often the right choice: enable maintenance mode, capture a backup with heroku pg:backups:capture, download and restore to the target database, validate, switch connection strings. The downtime window is predictable and the process is well-understood.

Logical replication minimizes downtime for larger databases or low-downtime-tolerance applications. Continuous replication runs until you're ready to cut over, then you freeze writes briefly, validate sync, and switch. The complication on Heroku: direct replication control is not available to customers by default. For larger databases you may need to contact Heroku support to get WAL archives exposed in S3. Plan for this lead time explicitly.

Regardless of strategy: test the restore before you need it, define rollback triggers in advance, and don't migrate the database during peak traffic hours.

→ See: Migration Guide

Where does Aptible fit compared to other Heroku alternatives for regulated teams?

Aptible is the compliance-first lane of the Heroku alternatives landscape. It's purpose-built for regulated production workloads where compliance is a first-class requirement at the platform level, not a premium tier.

The practical difference from Heroku Shield: isolation and audit evidence are platform defaults on Aptible, not configurations. Every environment produces audit history automatically. HITRUST R2 certification covers a substantially broader compliance framework than SOC 2 alone. The BAA doesn't require enterprise contract negotiation.

Where Aptible fits and where it doesn't: digital health startups, healthcare SaaS, teams in active enterprise deal cycles, organizations handling PHI with formal audit requirements. It's not the right choice for hobby projects, pre-product teams, or teams that need maximum cloud flexibility with a dedicated platform engineering team.

For teams currently on Heroku Shield, the comparison is direct: similar pricing category, compliance posture that's a platform default rather than an add-on tier, and an active roadmap.

→ See: Heroku vs. Aptible

Is Heroku still a good choice for new projects?

For new enterprise deployments: no. Heroku is no longer accepting new enterprise contracts for new customers. That path is closed.

For self-serve, non-regulated, small-scale projects: it can still work in the near term, but you'd be adopting a platform at the beginning of its maintenance phase rather than the middle of its growth. The developer experience is mature. The tradeoff is that you'd be building on infrastructure with a frozen roadmap from day one, with better alternatives available at comparable or lower cost.

For regulated workloads: no. The compliance posture under sustaining engineering is frozen, which means any gaps that exist today will still exist when your audit scope expands.

The short version: for new projects, the alternatives are better choices than they were two years ago, and Heroku's competitive position relative to them has only weakened since February 2026.

Has Heroku pricing changed since the sustaining engineering announcement?

No pricing changes have been announced as part of the sustaining engineering transition. Existing customers continue under current pricing terms.

The value question has changed, though. Paying a PaaS premium for a platform that was actively building meant that premium included future capabilities. Under sustaining engineering, the premium covers maintenance and stability. Whether that trade still makes sense depends on your workload and what you were counting on the roadmap to deliver.

→ See: Heroku Pricing

Can I stay on Heroku long term safely?

Safely, with the right definition of "long term." Heroku will continue to run. Security patches will ship. The operational picture for existing customers is stable.

What changes over time: the gap between Heroku and actively developing alternatives widens. Compliance posture that doesn't evolve becomes harder to defend in enterprise reviews. Features that don't ship create permanent workarounds. The longer you stay, the larger the migration surface area grows.

"Long term" with a plan is very different from "long term" by inertia. If you stay intentionally, with a documented platform assumption, a defined exit condition, and a quarterly review, that's a rational choice. If you stay because you keep deferring the decision, you're accumulating optionality cost every quarter.

→ See: Should You Migrate?

What are the risks of waiting too long to migrate?

The primary risk is losing control over the timing. Teams that migrate under pressure (an audit finding, a lost enterprise deal, a major outage, a contract renewal with no runway) make worse decisions than teams that migrate on a planned schedule.

Secondary risks that compound over time:

• Migration surface area grows as the architecture becomes more complex

• Compliance gaps that didn't matter at early scale become hard limits at growth stage

• Enterprise deals that require security posture changes become blockers instead of catalysts

• A platform with a frozen roadmap falls further behind alternatives, widening the technical gap you eventually have to close

The cost of planning is low. The cost of an emergency migration is high. The option value of having evaluated alternatives before you need to move is real.

→ See: Should You Migrate?

How much engineering effort does a Heroku migration typically require?

It depends heavily on stack complexity.

Solo or small team (one to three engineers), simple stack: days to a week. A single web process, a managed Postgres, a handful of add-ons, a Dockerfile. This is one of the most manageable migrations in infrastructure.

Mid-size SaaS team (four to fifteen engineers): one to four weeks. Multiple services, worker processes, CI/CD coordination, database replication, and some organizational alignment add scope. The technical work is often less than the coordination work.

Regulated or security-focused team: four to eight weeks minimum, often longer. Compliance documentation, BAA transitions, audit trail continuity, networking redesign, and more internal stakeholders all extend the timeline. Trying to compress below four weeks typically means skipping compliance steps.

For all profiles: the database migration is the critical path item. Start planning it before you start anything else.

→ See: Migration Guide

Will migrating off Heroku require rewriting our application?

No. A Heroku migration is a platform abstraction replacement, not an application rewrite. Application code doesn't change. Database schemas don't change. Core runtime doesn't change.

What changes: the build system (buildpacks become a Dockerfile), the deployment workflow (git push becomes CI-driven image deploy), how secrets are managed, and how add-ons map to managed service equivalents on the target platform.

The most common surprise is build-time secrets. If your current build process consumes secrets that Heroku injects silently (private registry credentials, npm auth tokens), those won't automatically be available in your new build environment. Document them before you start.

→ See: Migration Guide

Are there free or low-cost Heroku alternatives?

Yes, at small scale.

• Fly.io: shared CPU instances starting at roughly $1.94/month for 256MB RAM. The cheapest per-compute option in the PaaS lane.

• Railway: $5/month hobby tier that covers multiple services. Usage-based billing after that.

• Render: free tier for static sites; web services start at $7/month. No sleeping on paid tiers.

All three are meaningfully cheaper than Heroku Standard dynos at equivalent workload sizes. At medium scale the comparison depends on your specific workload shape and add-on dependencies.

Note: none of the free or low-cost tiers are appropriate for regulated workloads. HIPAA-eligible configurations on any of these platforms require paid plans and explicit compliance configuration.

→ See: PaaS Alternatives, Heroku Pricing

What is the safest migration path for a HIPAA workload?

The safest path is to a platform where compliance posture is a default, not a configuration. That means either a compliance-first PaaS or a carefully configured DIY cloud environment.

For most regulated startups without dedicated platform engineering: Aptible. Compliance is structural rather than an add-on tier, the BAA process is straightforward, and the migration path from Heroku is well-documented. See Aptible's Heroku migration docs.

For teams with simpler HIPAA requirements and cost sensitivity: Render's HIPAA workspace ($250/month on Org/Enterprise plans) offers a self-serve BAA and SOC 2 Type II. It's a viable option for teams unlikely to need HITRUST or complex audit evidence generation.

For teams with platform engineering capacity: AWS with ECS/Fargate is viable, but you own all compliance configuration and evidence generation.

For Shield-specific migrations, the planning requirements are more involved. See Migrating from Heroku Shield.

How do we evaluate vendor lock-in when choosing a Heroku alternative?

The main lock-in concern with any PaaS is portability. Container-based platforms (Aptible, Render, Fly.io) give you the most portable foundation: your Dockerfile and application code run the same on any container-friendly platform. If you ever need to move again, the migration is repeatable.

Platforms with proprietary buildpacks or tight coupling to platform-specific add-ons create stickier migrations. The lesson from Heroku itself: the more you rely on platform-specific abstractions (Heroku's add-on ecosystem, buildpack-specific behavior, Heroku's release phase mechanics), the larger your migration surface area when you eventually move.

Practical rule: standardize on Docker early, keep your application's dependencies on platform-specific features explicit, and use managed services that can be replaced independently (external Postgres, Redis) rather than tightly platform-coupled versions where possible.

→ See: Compare Platforms

Should we migrate before renewing our Heroku contract?

Yes, if you're an enterprise customer with a renewal approaching. Leverage requires runway.

If you start evaluating alternatives at the renewal conversation, you have no negotiating position and no time to run a proper evaluation. If you've already validated an alternative and know your migration timeline, you have real options: renew if it makes sense, or move on your schedule rather than under renewal pressure.

The same logic applies to any contract-dependent decision. The teams that get the best outcomes are the ones that make infrastructure decisions proactively, before the timeline is set by someone else's deadline.

→ See: Should You Migrate?

Can we migrate without redesigning our CI/CD?

Yes. This is one of the most important tactical points in the migration guide.

Migration and CI/CD redesign are two separate projects. You can migrate to a new platform while keeping your existing deployment workflow intact, and modernize the CI/CD pipeline afterward. Most platforms support this: you deploy a Dockerfile the same way you'd deploy to any container environment, and your existing pipeline can drive it.

Trying to simultaneously move platforms and redesign your deployment pipeline is the most common reason Heroku migrations take longer and cost more than expected. Two simultaneous changes mean two sets of variables when things go wrong.

Lift and shift first. Modernize after you're stable on the new platform.

→ See: Migration Guide

How do we preserve review apps?

Most Heroku-like alternatives have a comparable feature:

• Render: Service Previews (single-service) and Preview Environments (multi-service, configured via render.yaml). The mechanics differ from Heroku's Review Apps but accomplish the same goal.

• Fly.io: Preview deployments via GitHub Actions integration. More setup required than Heroku.

• Railway: Ephemeral environments per PR are supported.

The key difference from Heroku: most alternatives require more explicit configuration to set up preview environments, whereas Heroku's Review Apps worked relatively automatically once configured in the pipeline. Budget time to set this up deliberately during the migration, and validate that preview environments have the right data (mocked vs. staging) before treating it as done.

→ See: Migration Guide, PaaS Alternatives

How do we avoid secrets drift during migration?

Secrets drift happens when different environments have different versions of secrets, or when secrets exist in one environment but not another. During a migration, it's easy to copy run-time config vars and miss build-time secrets entirely.

Before you start:

1. Audit every environment variable in every Heroku environment (production, staging, review apps, CI).

2. Explicitly distinguish run-time config vars from build-time secrets. Heroku injects both transparently; your target platform may handle them differently.

3. Document which secrets are environment-specific and which are shared.

4. Migrate secrets to your target platform before you build there. Don't discover missing build secrets when your CI fails.

After cutover, establish a process for secrets rotation that applies consistently across both platforms until you've fully decommissioned Heroku.

→ See: Migration Guide

How do we switch traffic safely using DNS?

Lower your DNS TTL well before cutover, not on the day of. If your TTL is set to 24 hours and you switch DNS, you have up to 24 hours of lag before all traffic routes to the new platform. Clients that cached the old address before the switch continue hitting the old platform.

The practical sequence:

1. At least 48 to 72 hours before your cutover window: lower DNS TTL to 60 seconds for all relevant domains.

2. Confirm the TTL change has propagated before the cutover window.

3. On cutover day: complete your database migration, verify the new environment is live and healthy, then switch DNS.

4. Monitor error rates and latency aggressively for the first two to four hours.

5. If rollback is needed: switch DNS back. Because TTL is 60 seconds, rollback takes effect quickly.

DNS-based cutover is the recommended approach because rollback is fast and doesn't require database changes. Load balancer or application-level cutover is slower to roll back.

→ See: Migration Guide

How much internal alignment is required?

Depends on team size and what you're migrating.

For solo developers or very small teams: minimal. One person can make the decision and execute it. The main alignment work is notifying stakeholders of the cutover window.

For mid-size teams: moderate. Engineers need to know the new deploy workflow. On-call rotation needs to account for new failure modes. Finance needs to approve the new infrastructure cost. A one-page decision doc and a brief team sync are usually sufficient.

For regulated teams or organizations with enterprise customers: more. Security teams need to validate the new platform's compliance posture. Legal needs to confirm BAA status before PHI touches the new environment. Customer success may need to communicate the infrastructure change to enterprise customers. Start these conversations early.

The alignment work is often more time-consuming than the technical work. Budget for it.

→ See: Should You Migrate?

What's different about migrating off Heroku Shield compared to standard Heroku?

Migrating from Heroku Shield involves additional considerations around Private Spaces, database services, network isolation, BAA coordination, and audit validation. The process remains manageable, but compliance-sensitive workloads require more structured planning.

→ See: Migrating from Heroku Shield

Can we migrate off Heroku Shield without losing our HIPAA posture?

Yes, but it requires careful mapping of isolation boundaries, encryption configuration, database migration strategy, and audit trail continuity. A planned migration preserves compliance posture and often strengthens it.

→ See: Migrating from Heroku Shield

Next steps

This FAQ covers the most common questions across the guide. Use the links below to go deeper on whichever area is most relevant to your situation.

Deciding whether to migrate

Should You Migrate?: Framework for making the decision deliberately, including when staying is rational and when delaying increases risk.

Understanding what changed

What's Happening at Heroku: Plain-language breakdown of the February 2026 announcement and what sustaining engineering means in practice.

Evaluating your options

Compare Platforms: Four-lane breakdown of the alternative landscape with recommended shortlists by team profile.

Planning the migration

Migration Guide: Inventory, secrets, database migration strategy, cutover sequencing, and common mistakes.

Compliance and HIPAA

Heroku and HIPAA: What Shield covers, where teams hit gaps, and what changes under sustaining engineering.

Migrating from Heroku Shield: Compliance-specific migration planning for Shield environments.