Sunsetting and Deprecation at Heroku

Software erosion is what happens to your app without your knowledge or consent: it was working at one point, and then doesn't work anymore. When this happens you have to invest energy diagnosing and resolving the problem. Over a year ago Heroku's CTO, Adam Wiggins, first wrote about erosion-resistance on Heroku. Part of erosion-resistance is communication, and knowing what to expect moving into the future. This post will clarify what we mean by erosion-resistance, and help you understand what to expect when one of our features is deprecated or is sunset.

Erosion Resistance

Erosion-resistance means that your apps are protected against accidental or unannounced changes because there is an explicit contract between your app and the platform. Heroku insulates you from erosion by providing a transparent, managed service. We give you early visibility and full details on what's happening with your app, and options for how to respond to any changes. In many cases we can take care of system changes for you automatically, but when we can't, we tell you what your options are, how to proceed, and how much time you have.

To keep your application stable Heroku applies fixes and improvements, such as backwards-compatible updates released by maintainers, to the software on our platform. This protects applications on our platform without interrupting them. Occasionally security patches are introduced to operating systems and sometimes to programming languages. By using the Heroku platform, you can be confident that the underlying software you are using is safe and stable.

If a backwards-incompatible change needs to be applied to our platform we will always communicate the change ahead of time and provide sufficient information so that you can take the necessary steps to fix any incompatibilities. These changes are communicated through our deprecation and sunsetting process.

Deprecation Notices

When Heroku deprecates a product or service, we are actively suggesting that you no longer use that feature. Deprecations may be communicated through notices coming from the Heroku CLI, banners in our Dev Center, or messages on our website. These notices may be accompanied by blog posts, changelog entries, official tweets, or direct emails when appropriate. Deprecation of a product will typically suggest using a more recent, stable, or feature rich product, so you can have the best experience using Heroku. These notices will not affect currently running apps. If, however, only a few applications are using a feature in production, Heroku may choose to sunset the feature.

Sunsetting a Product

As a product is sunset, it will be gradually phased out until it can be deactivated or removed from our system. We will only sunset products that have seen significantly decreased usage, and we will not deactivate heavily used features. Any product being sunset will have been deprecated for some time and will begin with an announcement similar to the deprecation but including additional information such as the date of the product's deactivation.

If possible, we will migrate any affected users to a comparable product. A good example of this is the Cron Add-on. Cron was deprecated in April of 2012, and after a majority of its users transitioned away from the product it was sunset. Any users left using Cron were automatically migrated to the superior Scheduler Add-on.

If we sunset a product you are using, and we cannot automatically migrate, there are several things you can expect from Heroku. You will receive communication of the changes along with a plan moving forward. This will include a time-line with enough time to make any changes needed. Our goal is always to provide the best experience, to our developers, and to give the highest level of support possible.


At Heroku, we seek to be the most powerful platform to the largest number of users. By providing a strong contract with our platform, you can be confident using Heroku, and be prepared for when change happens. To stay up to date with our current erosion-resistance policies, you can always check our erosion-resistance documentation on the Dev Center.

Announcing Heroku Enterprise for Java

A year ago we we launched Java support with the ability to deploy Maven based Java applications using Heroku’s familiar git based workflow. Many customers, like Banjo, have since taken advantage of the new capabilities and built a wide variety of Java applications on the platform.

With the introduction of Java support, we are seeing growing interest from larger enterprises who are often heavy Java users and who are looking for a platform like Heroku to increase the speed of application delivery.

Today, we are announcing Heroku Enterprise for Java, a new product that makes it simpler than ever for enterprise developers to create, deploy and manage Java web applications using their preferred tools and processes. The product is priced at a monthly subscription fee per production application making it easy for the business to align investment with value.

Let us look at the features in detail.

Full stack Java

The vast majority of Java web apps use a baseline set of components: A JDK, a Tomcat web app container, a SQL database and a caching layer to handle session state. Heroku Enterprise for Java includes these baseline components, pre-configured and pre-integrated out of the box.

OpenJDK 6, 7 or 8

You can choose the Java environment that you need whether it is version 6, 7, or the upcoming OpenJDK 8. Read more...

Tomcat 7 web app container

The open source Apache Tomcat container is the most popular way to run Java web applications. Heroku supports Tomcat 7 deployment through WAR files and Maven builds. Read more...

Memcache backed distributed HTTP session state

For maximum scalability Heroku applications can use a Memcache store for distributed session state. This alleviates the scalability limitations associated with typical session replication strategies. Externalized session state alleviates memory and replication overhead while providing durability across application updates. Read more...

Production Heroku PostgreSQL database

Heroku Enterprise for Java includes a Heroku Postgres production database because almost every Java web application stores data in a SQL database. Read more...

Continuous Delivery

Built-in best practices for rapidly deploying new application versions

Deploy and Test - then Promote

With Heroku Enterprise for Java you can instantly deploy Java web apps to staging environments where those applications can be tested and then promoted to production. This provides a major simplification over the usual deployment workflows for enterprise apps.

Continuous Integration Plug-in for Atlassian Bamboo

Heroku Enterprise for Java enables automated deployment of tested applications (i.e. Continuous Delivery) through a plug-in for Atlassian's Bamboo CI solution. Read more...

Continuous Delivery

Dynamic Runtime Environments

Create and scale complete, self-healing environments

Managed and instantly scalable environments for production and staging

A key enabler for continuous delivery is the ability to seamlessly provision and manage many different environments. This is a core feature of the Heroku platform where a new environment can be brought up with a simple heroku create. Heroku Enterprise for Java includes a full set of development, testing, staging and production environments that can be easily manipulated from the Eclipse IDE, web interface or command line tool.

Native Java Tools

Heroku Enterprise for Java works with tools you know and trust

Eclipse-based development using the new Heroku Eclipse plug-in

For developers who use IDE workflows the new Heroku Eclipse plug-in makes it easy to create, deploy, and manage their Heroku apps entirely within Eclipse. Read more...

Eclipse plugin

WAR based deployment of Java web apps

Java web applications are often packaged into WAR files and deployed to a container. Heroku now supports the deployment of WAR files to a Tomcat 7 container from the command line and from Eclipse. Read more...

WAR based deployment

Enterprise-Grade Support

Enterprise-grade applications need enterprise-level support. Heroku Enterprise for Java includes SLA based support over tickets or email for quick resolution of deployment or operational problems.

Heroku Enterprise for Java is available now!

Learn more...

Presenting the Heroku Dashboard

Here at Heroku, we focus our energy on developer experience and productivity. Historically, this has revolved around command-line tools like the Heroku Toolbelt. As a polyglot platform, we have developers that come from all backgrounds — some that prefer command-line workflows and others that prefer web interface. Most use a bit of both.

Today, we're introducing a new first-class interface to our platform: the Heroku Dashboard.

App Awareness and Discoverability

The new Heroku Dashboard features a fresh look and feel, optimized for readability and workflow efficiency.

The more apps you deploy to Heroku, the harder keeping track of them becomes. With Dashboard, you can instantly filter your apps not only by name, but also by stack, and buildpack.

App List

If there's an app you access frequently, you can favorite it. This moves it to the top of your app list permanently.


The new Activity view displays all code, config, and resource changes by every developer working on an app.


Additionally, if you specify an app's GitHub repo then you'll have clickable links to a diff of every deploy. Collaboration has never been easier.

New Horizons

As of today, the Dashboard is the default web experience for everyone on the platform.

Watch closely for updates and new features. Dashboard is a great foundation that allows for quick iterations and experimentation — a standard Heroku app that consumes our public API.

Introducing the Heroku Partner Directory

In 2007, Los Angeles web development shop Bitscribe loved the productivity gains they found by developing using agile methodologies. What they didn’t like was the labor-intensive process necessary to deploy applications. Bitscribe principals James, Adam, and Orion decided to build a company just to solve this problem. They called it "Heroku", a combination of the words "hero" and "haiku".

Hundreds of development shops from small shops like Bitscribe to large GSIs like Accenture now rely on Heroku so they can focus on building apps instead of deploying and running them. Many of these shops are now official partners. Their expertise ranges from web and mobile development, project management, design and agile training.

Find Partners in Our New Directory

From Fortune 500 companies to startups, we're finding there are a lot of companies who benefit from the agility these service partners can provide. We’re proud to announce a new Partner Directory as well as a revamped Partner Program.

Whether your company needs a few extra developers or an entire team for a big budget project, the Heroku Directory has you covered. Each company featured in the Directory is vetted by our team here at Heroku and is therefore familiar with best practices on our platform. Search for partners by language, competency, or geography, and check out samples of work. If you see a potential match, simply contact that company from their listing.

Become a Partner

We know there are a lot more dev shops using Heroku who can benefit significantly from this program. If your company is a development shop and would like to be featured, please apply at our website, It's fast, easy, and free.

Premium Support through Gold and Platinum Tiers

Some development shops deploy business critical applications for large companies and need a higher level of support and flexibility from Heroku. We now have new Gold and Platinum partner tiers that offer access to a named Technical Account Manager and co-branding options. Please contact us at partners(at) for more information.

As a company created to solve the problems of a development shop, Heroku strives to offer the best experience for our current and future partners and their customers. Take a look at our revamped Partner Program and let us know how we are doing.

Design of the Status Site

A couple months ago, we launched a completely redesigned Heroku status site. Since design is important to us and, we think, to many of you, we're taking a break from our usual blog posts to dig into the Heroku approach to visual product design.

Read on to experience the twists and turns on the way to the final design and let us know in the comments if you want to see more posts like this.

Old Status Site New Status Site

The Premise

For platform providers, a status site is a way to build trust with your customers, and in some cases, future customers. Heroku is no different. Our existing status site hadn't been updated in over two years and was showing its age. We took this as an opportunity to go back to basics; drafting up user personas and goals. The previous status site was designed around the persona of a Heroku user checking to see if Heroku is working this very second. We realized there is an equally important persona — a user or prospect trying to understand how reliable the platform is.

Of the many things we could improve, we focused on three primary areas:

  • Status is as much about uptime as it is downtime.

  • We wanted to increase transparency.

  • We needed to streamline the admin experience (which we won't show here).

When it came time to start visual designs, we did some research to get a sense of existing solutions and user expectations. After some intensive brainstorming, we came up with the idea of a timeline.

A timeline felt like the perfect device for what we were trying to achieve. Not only does it show downtime and uptime in proportion to one another, but it includes a really key piece of information: time to resolution.


It started as just a hypothesis, and we needed to test that hypothesis with real customers as quickly as possible. It's easy to get tied down by visual design and lose focus on what really matters: the product. Instead of spending a lot of time in an image editor like Photoshop making the page look beautiful, we wanted a working prototype with real data from the get-go. Setting aside visual design and best practices, we created a simple Sinatra application using spaghetti code and inline styles, with read-only access to a live database:

First Prototype

We tested the first pass with our customer advisory board by inviting them to do a 5-minute OpenHallway user study. It was important to set the right expectations (and context) for this survey:

This prototype is not representative of final visuals.

OpenHallway allowed us to capture the screen and audio of our testers and follow alongside them as they explored the site. Incidentally, our first tests had way too many questions and instructions. Eventually we converged on five simple questions:

  • What are your first impressions?
  • Is it clear what the page is about?
  • Does it quickly convey the current platform status?
  • Does the page increase or decrease your trust in Heroku?
  • How does this site compare to the old status site?

We also added keyboard shortcuts so our testers could simulate outages and scheduled maintenance ('o' and 'm' if you want to follow along).


When we reviewed the OpenHallway videos, we noticed a concerning trend; several people commented that there was "too much whitespace". We knew we had taken a risky approach with the timeline and wanted to make sure we weren't committing too early to a design and ignoring actual user needs, so we (incorrectly) interpreted this to mean that the timeline wasn't working.

In an effort to clear ourselves from an arbitrary commitment, we took a step back. Simplify the constraints. Think mobile. We asked ourselves what the status site would look like if we only had 320x480 pixels.

Mobile Prototype


Following this promising direction, we created a fully-responsive version that would work for iPhones, iPads, and desktops. We added a little more information in this version; and even more information as you increased screen real estate. But in all these versions, the timeline was gone.

Responsive Prototype

This again looked promising, but it was hardcoded and no longer using live data, so we started wiring it up to live data. Then a surprising thing happened and we realized that the site completely failed to satisfy our first goal of visually conveying uptime as well as downtime. In fact, once we had live data in there, we realized that if 3 consecutive days had something minor happen, like a single shared database server offline that affected significantly less than 1% of our users, it looked like our entire platform was down for 72 hours straight! It was so bad, we knew it didn't even deserve to go through customer validation.


In a last ditch effort to save the responsive design, we tried adding a timeline back into it.

Hybrid Prototype

At this point, the design had all of the "features" we needed. It showed a simple list view if you were on an iPhone, added a timeline for anything larger, and progressively added more information as the screen widened. It seemed like a design win, and fit with our new guiding principles of mobile-first and responsive design. Besides, it was fun to resize the screen and see it change! (Give it a try!)

There was only one problem: we didn't like it. It's hard to describe exactly why; it wasn't clear enough, the emphasis was in the wrong place, the meta data (Affected, Scale, and Duration) was supposed to add value but seemed to distract from the overall site. Design had been replaced by detail.


So we took another step back. We took what we had learned so far and re-applied it to our initial gut reaction — the timeline.

Bezier Prototype

We added some meta information (e.g. duration), but not all of it (e.g. scale). We realized the App Operations / Tools split was very important to our users, but didn't go far enough. Too much counted as App Operations that had no impact on our paying customers, such as the unidling of 1-dyno free apps, or the free shared database offering. We thought about having one status light for each major component of our platform, such as routing or git push, but the complexity didn't add enough value. We then toyed with the idea of splitting based on Production vs Development instead, and it turned out to be such a great fit that we split the timeline into two columns to show it.

By this time, we had already approached all of our customer advisory board and needed more fresh eyes to look at it, so we invited random beta users to do the OpenHallway studies. This time, the comments were different: we had a winner.

We called this version bezier because we intended on having bezier curves to join the incidents with their timeline markers. We didn't get around to implementing them until later in the beta process, but when we did, it really brought the design together, simplifying a lot of hacks we put in place to handle overlapping incidents.

Here's the JSFiddle sandbox we used to get the right shape for the curves. It's not exactly how we implemented it, but it's where we started, and just knowing it was feasible let us move on with the design.

Beta and Release

All of the designs above were intended as throwaways since they were prototypes solely designed to be validated with customers. But as sometimes happens, we got such great response from the last design, that we decided to go into beta with the design largely unchanged.

Status Beta

We're happy with the final design; we use it internally and even have it up on a big screen in our office. But like anything we build, this is a perpetual work-in-progress. The new status site provides more value than the previous one, but we're going to continue iterating and improving, so keep the feedback coming!

Browse the blog archives or subscribe to the full-text feed.