Cedar is the Default Heroku Stack

The Heroku Cedar stack went public beta last year with a series of blog posts. Since then, over 80,000 developers have deployed over 4.5 million times, to apps written in dozens of different programming languages and frameworks. Today, over 75 percent of Heroku app development activity is on the Cedar stack. Production apps like Banjo, Rapportive, PageLever, do.com, and Project Zebra run on Cedar; some of these serve hundreds of millions or even billions of requests per month.

Cedar features a streamlined HTTP stack allowing for advanced HTTP capabilities, heroku run for execution of arbitrary one-off dynos, Procfile and the process model for execution of any type of worker process. Most importantly, Cedar is a polyglot platform with official support for Clojure, Java, Node.js, Python, Ruby, and Scala, and extensibility for unlimited others via buildpacks.

You can still create applications on one of our other stacks using heroku create --stack, but we recommend Cedar for all new apps. If you have applications under active development running on Aspen or Bamboo, we recommend migrating to Cedar.

Cedar Goes GA

As of today, the Cedar stack is now in general availability.

Cedar features a streamlined HTTP stack allowing for advanced HTTP capabilities, heroku run for execution of arbitrary one-off dynos, Procfile and the process model for execution of any type of worker process. Most importantly, Cedar is a polyglot platform with official support for Clojure, Java, Node.js, Python, Ruby, and Scala, and extensibility for unlimited others via buildpacks.

The Dev Center team has spent the last few months “Cedar-izing” our developer documentation, so now most articles describe use of Heroku on the Cedar platform. (Aspen and Bamboo remain documented in their own section.)

Cedar is the most powerful, performant, and reliable of the three Heroku runtime stacks. In a few weeks, we'll be making it the default. But don't wait for that; even in the meantime we recommend using heroku create --stack cedar for all new apps, especially those in production. If you have applications under active development running on Aspen or Bamboo, we recommend migrating to Cedar.

New Heroku Status Site

Developers like you deploy code to hundreds of thousands of apps every month on the Heroku platform. Some of these are production apps which serve hundreds of millions or even billions of requests per month. Uptime of the platform is critical for such apps.

We want to achieve the sustained reliability that these apps require. But when there are incidents that impact uptime, we want to maximize our transparency and accountability to you and all developers on the platform.

Today, we’re launching a completely redesigned status.heroku.com, which provides real-time status of the platform, the ability to sign up for email or SMS notification of incidents, and recent uptime history in both visual and numeric formats.

Status Site

Let’s zoom in on each of these points.

Incident monitoring: The circles at the top show green (all systems go), yellow (intermittent errors or partial impact), or red (major outage of specified component). The boxes below describe the incident in detail and show how long it’s been happening. This page uses Pusher to refresh the page automatically as we post updates, without requiring you to continually reload to track progress of an in-progress incident.

Proactive Alerts: Click “Subscribe to Notifications” in the upper right corner to receive notifications on platform incidents in a variety of formats: email, SMS, Twitter, or RSS.

Uptime numbers for the last month: At the top, you’ll see uptime numbers for the previous month. This provides an at-a-glance answer to the question of “How stable has Heroku been lately?” Our numbers here haven’t been as good as we’d like in the last few months, but by posting them publicly here we intend to create the transparency and accountability that will help drive us to improve. After all, you make what you measure.

Timeline: Most status sites, including the previous implementation of the Heroku status site, list incidents in a blog-like format. For the new Heroku status site, we took the opportunity to try something more innovative, and the result was the timeline view. Incidents are displayed on a vertical timeline. When the platform is performing normally, the timeline is green. When an incident occurs, a red or yellow bar sized to the duration of the incident is plotted against the timeline. By scrolling down the timeline, you can get a feel for the duration and frequency of recent incidents, without needing to scrutinize each one individually.

Production vs Development: There are two circles for status, two uptime numbers, and two timelines. Why the separation? Heroku’s operational efforts always prioritize continuity of service for existing production applications over service for development/prototype/hobby apps, or the ability to take development actions (such as deploying new code) against production apps. If you can’t push code to your app for ten minutes, it’s an annoyance. If your production app stops serving traffic to your users for ten minutes, that’s a much bigger problem. Today, production apps are defined as any app running two or more dynos with a production-grade database.

API: Like other parts of the Heroku platform, the new status site has its own API. Use this to create a custom monitoring tool, your own front-end, or whatever you like.

Documentation can be found in the Dev Center.

This new status site is more than just eye candy: we’ve provided transparency and demonstrated our accountability for the uptime of the Heroku platform. It’s our goal to earn a long-term track record of reliability, one that is deserving of the critical production apps which many of you have entrusted us with.

We’d like to extend a big thank-you to the approximately 350 people who helped us beta test the new status site. If you’d like to help us test future beta releases of Heroku products, sign up for our private beta list.

SSL Endpoint GA

Earlier this month we released the public beta of an improved SSL solution, SSL Endpoint. We've received positive feedback from everyone using the new SSL solution.

Based on this strong positive response and adoption during the beta, we're officially moving SSL Endpoint to general availability starting today. It is now the recommended option for any app which needs SSL on a custom domain.

In conjunction with SSL Endpoint's GA status, we're consolidating and simplifying our SSL product lineup by deprecating all of the older SSL add-ons: SNI, Hostname SSL, and IP SSL. SSL Endpoint is easier to use, more robust, faster to provision, and offers more features (such as certificate rollback and client IP address as an HTTP header).

Beginning June 18, 2012, these other SSL add-ons will no longer be provisionable via heroku addons:add. Applications that already have these add-ons installed will continue to function normally, and we'll continue to fully support the SSL capabilities for those apps on an ongoing basis.

For steps in migrating to the SSL Endpoint add-on please read here.

Multiple Ruby Version Support on Heroku

Maximizing parity between development and production environments is a best practice for minimizing surprises at deployment time. The version of language VM you're using is no exception. One approach to this is to specify it using the same dependency management tool used to specify the versions of libraries your app uses. Clojure uses this technique with Leinigen, Scala with SBT, and Node.js with NPM. In each case, Heroku reads the dependency file during slug compile and uses the version of the language that you specify.

Today, we're pleased to announce that we've added support for specifying a Ruby version to Gem Bundler, the dependency management tool for Ruby. This will allow you to specify a version of Ruby to be used in your Ruby app on Heroku.

Try it out:

$ gem install bundler --pre

In your Gemfile:

source 'http://rubygems.org'

ruby '1.9.3'
gem  'rails', '3.2.3'

Then:

$ bundle install
$ git add Gemfile
$ git commit -m 'use Ruby 1.9.3'
$ git push heroku master

Prove that you're running 1.9.3:

$ heroku run 'ruby -v'
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

$ heroku run 'ruby -e "puts RUBY_VERSION"'
1.9.3

Patch Versions

While you can specify the version of Ruby for you app, you can't specify a patch version, such as Ruby 1.9.2-p290. Ruby patches often include important bug and security fixes and are extremely compatible. Heroku will provide the most secure patch level of whatever minor version number you request.

Thanks

Thanks to Terence Lee Heroku Ruby team member and bundler maintainer for the additional support of ruby versions to the Heroku Ruby Buildpack and orchestrated the release of Bundler 1.2.0. Also thanks to Yehuda Katz and the entire Bundler team for helping get this release out the door.

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