Announcing Follow

Today we’re releasing the ability to follow your Heroku Postgres Database into General Availability: this lets you easily create multiple read-only asynchronous replicas of your database, known as followers.

After an extended beta period during which over 3,000 followers were created, many of which help power core Heroku systems, we’re excited to make the ability to safely and easily scale out access to your data available to all Heroku Postgres users.

Followers enable some great use cases:

One use case that has historically been challenging in database management is setting up a read replica, often referred to as a read slave. Traditionally this would require significant effort to provision, setup and configure machines and databases. Due to the time involved in this, most application developers opt for scaling up their database, rather than horizontally scaling out, an approach that can sustain significantly larger growth. During times of intense load, this leaves developers with no option to quickly reduce the load on their database without incurring significant downtime, resulting in databases becoming a liability, as opposed to adding value to a developer’s toolbox.

Follow Icon

When you follow a database you are given an entirely new follower which maintains a relationship to its leader. Your follower receives asynchronous updates from its leader and is often just seconds behind. Followers can be created with any of our production-tier plans. And with the recent release of our $50/mo Crane and $100/mo Kappa plans, these features are now available to an even wider audience than ever before. Creating a follower from an existing production database is as simple as:

$ heroku addons:add heroku-postgresql:crane --follow HEROKU_POSTGRESQL_LAVENDER
Adding heroku-postgresql:crane on craig... done, v114 ($50/mo)
Follower will become available for read-only queries when up-to-date
Use `heroku pg:wait` to track status
Use `heroku addons:docs heroku-postgresql:crane` to view documentation.

This command creates a new Heroku Postgres follower of a crane plan which is following a Heroku Postgres Database named Lavender. Followers can also easily be created by selecting from within the Followers area of the Heroku Postgres management dashboard:

Heroku Postgres Follower Creation


Heroku strives to provide tooling that empowers our customers to build and scale applications more easily; the ability to follow your database is a clear step in that direction. We’ve already seen 3 great use cases as outlined above, and we’re excited to see how the community takes this to the next level. If you're using a Production Heroku Database use follow to scale your database without fear! Visit Heroku Postgres to learn more about Heroku Postgres and to start creating followers today.

Heroku Office Hours, Wed 10/17 at 3pm PDT

This Wednesday 10/17 from 3-5pm we will be holding office hours for customers and users in our San Francisco office.

This is an opportunity for you to come meet us and ask questions about developing your apps on Heroku. It is an opportunity for us to learn more about you and your needs.

.@heroku's front door.   /cc @maddox @rtomayko

Heroku engineers, product managers, and designers will be available to chat with you about your code, application, business, or whatever else you want. Maybe you're a new user, and have some getting started questions. Perhaps you've been using Heroku for ages and have a high level architectural question. Or maybe you just want to shake someone's hand from the Heroku Postgres team. Either way stop by our offices at 321 11th Street (at the corner of Folsom). We are next to Slims. We look forward to seeing you.

View Larger Map

Upgrading to the Heroku Toolbelt

Heroku Toolbelt

The original version of the Heroku command-line tool was available as a Ruby gem. This made it easy to install on all platforms with just one command: gem install heroku. While we love this simplicity, it depends on a system install of Rubygems. To get this experience on widely varying development environments, we created the Heroku Toolbelt, a one-click installer for every major platform.

Going forward we will be sunsetting support for the heroku gem in favor of the Toolbelt. If you're already using the Toolbelt, you're fine to stop reading now. To verify whether you're using the gem or Toolbelt, use heroku version:

$ heroku version
heroku-toolbelt/2.32.11 (universal-darwin12.0) ruby/1.9.3 autoupdate

If the output includes heroku-toolbelt, you're all set.

Advantages of the Toolbelt

The Toolbelt is a self-contained installer that gives you everything you need to use Heroku. Some advantages of the Toolbelt include:

  • The Toolbelt is much faster, shaving several seconds off the startup of each heroku command.

  • The Toolbelt packages its own dependencies and will not conflict with your existing development tools.

  • The Toolbelt automatically keeps itself up to date with the latest available bug fixes, security updates, and new features.

Sunsetting the Gem

Starting today, all users still using the gem will see reminders to upgrade to the Toolbelt. This reminder will appear at most once daily when running a heroku command.

On December 1, 2012, we will stop releasing new updates to the heroku gem.

If you are using the heroku gem in your app to programatically access the Heroku API, we encourage you to migrate your code to the heroku-api gem. Existing versions of the heroku gem will remain on so any code referencing these gems should continue to function as long as the API they reference is available.

We encourage all users to upgrade to the Toolbelt today to take advantage of this new, streamlined CLI experience.

Sunsetting the Argent Aspen Stack

Heroku's Aspen stack is the product that launched our company and inspired a new class of cloud services. After much deliberation and careful thought, we have decided to sunset the Aspen stack by Thursday, November 22nd. We ask application owners still using Aspen to migrate to Cedar.

Since Aspen's launch over four years ago, Rails has seen the introduction of Bundler for dependency management, the asset pipeline, and a major framework re-write. Heroku has also grown, and with the introduction of the Cedar stack, we have moved beyond our humble origins and have become a true polyglot platform.

The Aspen stack was a prototype that served as a living vision of what a platform that focused on developer productivity and happiness could achieve. While there are many things developers loved about Aspen, the limitations have grown more apparent with time. On Aspen: Ruby is the only supported language, the version is locked, and there is no support for Rails beyond 3.0. As a result the number of apps left on Aspen is very small and decreasing steadily. Heroku has deployed over a million applications and taken all of the lessons learned running Aspen and Bamboo to build our most robust stack ever: Cedar.

The Future of Heroku

Cedar gives users the flexibility to install extra dependencies, run custom buildpacks, and it has built-in support for many popular programming languages and frameworks in addition to Ruby and Rails.

Although we are sunsetting Aspen, applications running on Bamboo or Cedar will not be affected. Heroku is betting big on the Cedar stack - it's our most advanced and flexible stack, and we have no plans to replace Cedar.

Heroku is proud to be an erosion resistant platform and has run a large number of Aspen apps for years with no need for change or deployment. Although Heroku protects you from accidental change, when change needs to happen you deserve to know. Because of this we have outlined our deprecation and sunsetting policy to let you know what to expect. While the Aspen stack has proved to be stable, most developers have chosen to move their apps to Cedar.

This is the first time Heroku has sunset a stable stack from operation, and we are not taking this process lightly. By sunsetting Aspen we hope to be able to better serve all of our customers' needs and to continue to give migrated applications uninterrupted service.

The Sun Sets

Functionality on the Aspen stack will be gradually diminished as the stack is slowly phased out and we ask application owners to migrate to Cedar. As of now you will not be able to create new Aspen apps; in the future Git pushes will no longer be functional, and add-ons will not be able to be provisioned. On Thursday, November 22nd, all applications that have not requested an extension will no longer be functional. Owners of paid Aspen apps have been individually contacted about this change. We provided migration instructions, a contact for requesting an extension, and many of them have already migrated their apps. If you are an Aspen application owner and you have questions, please contact support.


Since Aspen debuted in 2009, both the Ruby/Rails community and Heroku have grown substantially. Back then, developers spent days or weeks setting up servers, configuring webservers, setting up databases. Heroku turned all that into a single git push heroku master. While we're proud of the legacy Aspen represents, we acknowledge that it's time to retire Heroku's first grand experiment, and turn all our efforts toward the future.

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.

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

Visit the Engineering Blog