Salesforce Is Winding Down Heroku: What You Need to Know

Introduction: Salesforce Is Winding Down Heroku

Heroku has been a beloved platform among developers, startups, and enterprises for its simplicity in deploying, managing, and scaling applications. Acquired by Salesforce in 2010 for $212 million, Heroku became the face of Platform as a Service (PaaS), offering a frictionless way to go from code to cloud without worrying about infrastructure. However, recent announcements and strategic moves from Salesforce indicate that the company is gradually winding down Heroku as an independent, fully featured platform.

This blog post breaks down what is happening, why it matters, and what you as a developer or business leader need to do next.

What is changing with Heroku?

Salesforce has not officially used the phrase “winding down” in a single press release, but a series of decisions over the past two years paint a clear picture. In 2026, Heroku announced the elimination of its free plans, including free dynos and free Heroku Postgres databases. This move displaced hundreds of thousands of hobbyist developers and small projects. More recently, Salesforce has stopped major feature development on Heroku, redirected internal engineering resources toward Salesforce’s core cloud offerings, and quietly increased pricing for remaining services.

Additionally, Heroku’s once-thriving third-party add-on ecosystem has seen a mass exodus of providers. Many popular add-ons, such as Redis, logging tools, and monitoring services, are no longer available or have moved to paid-only, high-cost tiers. Support response times have also lengthened, and Salesforce has not committed to any major new runtime or language updates beyond basic maintenance.

In early 2026, Salesforce began offering migration credits to move Heroku workloads to other Salesforce clouds, specifically Salesforce Functions and Einstein GPT’s custom model hosting. This is a strong signal that Heroku’s underlying infrastructure will be gradually decommissioned or repurposed for internal Salesforce use only.

Why Is Salesforce Doing This?

Strategic Shift to Core Offerings

Salesforce’s primary revenue comes from Customer Relationship Management (CRM), marketing automation, and enterprise AI tools. Heroku, despite its popularity, never became a significant profit centre. By winding down Heroku, Salesforce can reallocate engineering talent and cloud capacity to higher-margin products like Data Cloud, MuleSoft, and Tableau.

Rise of Container Orchestration and Serverless

When Heroku launched in 2007, PaaS was revolutionary. Today, Kubernetes, AWS ECS, Google Cloud Run, and Azure Container Apps offer similar or better developer experiences at lower costs. Many developers have already migrated to these platforms, making Heroku less relevant for new projects.

Economic Pressure

Heroku’s architecture, based on AWS EC2 and proprietary routing layers, is expensive to maintain. With cloud costs rising globally, Salesforce found it harder to justify subsidising low-margin Heroku plans. Killing free tiers and increasing prices was a natural step before an eventual sunset.

What Does This Mean for Current Heroku Users?

If you are currently running production applications on Heroku, you are not facing an immediate shutdown, but you should plan for a future without Heroku as you know it. Here is what you can expect:

Gradual Feature Degradation

Heroku will likely never officially support new runtimes like Node.js 20+, Python 3.12+, and Java 21. Security patches for existing runtimes will become slower or stop altogether. Heroku’s CLI and dashboard may receive only critical fixes.

Rising Costs

Existing paid plans have already seen price hikes. Expect further increases or new “premium” tiers for basic features like automated backups, log drains, and SSL certificates. Salesforce may also introduce egress fees for data leaving Heroku.

Limited Support

Support tickets for non-critical issues may go unanswered for weeks. Enterprise customers with Salesforce support contracts might get slightly better treatment, but even Salesforce encourages them to migrate to its proprietary hosting solutions.

Migration Options: Where Should You Go?

If you have decided to leave Heroku proactively, you have several strong alternatives. Below are the most viable options, categorised by use case.

For Small Teams and Hobbyists

• Render: Offers a Heroku-like experience with free tiers for small services, native PostgreSQL, Redis, and cron jobs. Deployment is via Git, and pricing is transparent.
• Fly.io: Focuses on global deployment close to users. Supports Dockerfiles and has a generous free allowance.
• Railway: Very similar to Heroku’s original ease of use. One-click templates for popular frameworks and a simple CLI.

For Startups and Growing Businesses

• Google Cloud Run: Fully managed serverless container platform. You pay only for request time and memory. Works with any language that can run in a container.
• AWS App Runner: Amazon’s direct Heroku competitor. Integrates with GitHub and ECR. Less complex than ECS or Kubernetes.
• DigitalOcean App Platform: Includes managed databases, static site hosting, and auto-scaling. Predictable monthly pricing.

For Enterprises Already Using AWS or Azure

• Azure Container Apps: Built on Kubernetes but abstracts away complexity. Supports revisions, auto-scaling to zero, and Dapr for microservices.
• AWS ECS with Copilot: Amazon’s open-source tool that gives a Heroku-like “docker-compose up” experience on ECS/Fargate.
• Kubernetes with DevSpace or Skaffold: More work upfront but maximum control. Ideal for teams with dedicated DevOps.

For Salesforce-Bound Teams

If your organisation insists on staying within the Salesforce ecosystem, consider the following:

• Salesforce Functions: Hosts Node.js and Java functions that integrate directly with Salesforce records. However, it is not a general-purpose PaaS.
• MuleSoft Composer: For integration workflows only, not full applications.
• Tableau Cloud: Only for analytics and dashboards.

Be aware that none of these replace Heroku’s ability to run arbitrary web applications, background workers, or custom APIs.

Step-by-Step Migration Plan

To leave Heroku without downtime, follow this structured approach.

Step 1: Inventory Your Heroku Resources

List all applications, add-ons (databases, Redis, logging, etc.), environment variables, and custom domains. Identify which apps are mission-critical and which can be retired.

Step 2: Containerize Your Applications

Heroku uses buildpacks, but most modern platforms prefer Docker. Write a Dockerfile for each app. Start with Heroku’s own Docker deployment guide or use tools like heroku-to-docker scripts available on GitHub.

Step 3: Choose a Target Platform

Based on your budget, team size, and compliance needs, select one of the options from the previous section. For most small-to-medium teams, Render or Google Cloud Run offers the smoothest transition.

Step 4: Migrate Data

Heroku Postgres databases can be dumped using pg_dump and restored to a new PostgreSQL instance on your target platform. For Redis, use redis-cli --rdb or backup via add-on providers. Schedule a maintenance window if your app cannot handle read/write splitting.

Step 5: Update DNS and SSL

Point your custom domain’s CNAME or ALIAS record to the new platform’s endpoint. Provision SSL certificates (most platforms automate this via Let’s Encrypt). Test thoroughly before removing Heroku’s DNS entries.

Step 6: Deploy and Validate

Run both Heroku and new environments in parallel for a few days. Use a proxy or weighted DNS to shift a small percentage of traffic to the new platform. Monitor error rates, latency, and database consistency.

Step 7: Decommission Heroku

Once you are confident, delete Heroku apps, but keep database backups for at least 30 days. Cancel paid add-ons and dynos to stop billing.

Common Pitfalls to Avoid

• Underestimating Environment Variables: Heroku config vars are easy to use, but some platforms require them to be stored in secret managers or CI/CD settings. Plan accordingly.
• Forgetting Cron Jobs: Heroku Scheduler is a simple add-on. On other platforms, you may need to set up a separate worker service with a scheduler like Cloud Scheduler, AWS EventBridge, or a Kubernetes CronJob.
• Assuming Buildpack Equivalents: Not every platform supports Heroku-style buildpacks. Converting to Docker can reveal hidden dependencies on Heroku’s filesystem, like ephemeral disc writes or hardcoded ports.
• Ignoring Logging and Monitoring: Heroku’s built-in log dashboard is basic but functional. On new platforms, set up structured logging and a monitoring tool (e.g., DataDog, New Relic, or open-source Prometheus/Grafana) before cutting over.

Is There Any Reason to Stay on Heroku?

For a small number of legacy applications that are tightly coupled to Heroku’s add-ons (e.g., Heroku Connect for Salesforce data sync or Heroku Private Spaces for VPC peering), a short-term stay might make sense. Additionally, if your organization has a multi-year contract with Salesforce that includes Heroku credits, you can continue running unsupported workloads until the contract ends.

However, staying is a risky bet. Without security updates for runtimes and databases, your application could become vulnerable. And as Heroku’s infrastructure ages, performance degradation and outages may become more frequent.

Conclusion

Salesforce is not pulling the plug on Heroku overnight, but the writing is on the wall. The elimination of free tiers, lack of new features, rising costs, and internal redirection of engineering resources all point to a slow but definite wind-down. As a responsible developer or technical leader, you should begin planning your migration now.

The remarkable news is that the modern cloud ecosystem offers many excellent alternatives, from fully managed serverless platforms like Google Cloud Run to simpler Heroku-like experiences on Render or Fly.io. By containerising your applications and choosing a future-proof platform, you can not only replace Heroku’s functionality but also often improve performance and reduce costs.