Microservices in Go using Go-kit

Go-kit is a distributed programming toolkit for building microservices. It solves the common problems encountered while building distributed systems, so you can focus on your business logic. This article starts with a bit of background on microservices, then guidance on how to get started with Go-kit, including instructions on getting a basic service up and running on Heroku.

A Brief Intro to Microservices

Traditionally, web applications are built using a monolithic approach where the entire application is built, designed, deployed and maintained as a single unit. When working with a monolithic application various problems can arise over time: it’s easy for abstractions to leak across modules, tightly coupling them together; different parts of the application may need more processing power than others, requiring you to scale excessively; changes involve building and deploying a new version of the entire application; and tests can easily become convoluted and/or take an excruciatingly long

Continue reading “Microservices in Go using Go-kit”

Fork Your Application’s Data (Not Just Your Code) with Heroku Postgres

In the same way Git and Github revolutionized software development by letting you Fork your code with a single click, Heroku Postgres is changing the way you work with database by letting you Fork your data.

The ability to Fork your data is generally available as of today. This exciting technology which is simple, safe (placing no load on your primary database), and robust makes available some exciting new use cases:

  • Analytics reporting
  • Worry-free migrations
  • Trivial cloning of data to development/staging

Read more about our Fork announcement or get started using Fork today and then let us know about your exciting uses at dod-feedback@heroku.com

Facebook and Heroku

We’re delighted to announce that Facebook and Heroku have teamed up to bring you the fastest and easiest way to get your own Facebook app up and running in the cloud.

Facebook apps have long been a major segment on the Heroku platform. From scrappy startups like Cardinal Blue to Hollywood giants like Warner Brothers, Heroku’s scale-out capabilities and friction-free workflow enables these innovative companies to easily deliver great social experiences.
Now, Facebook has created a fantastic new way to start building a live Facebook app instantly, powered by Heroku.

A Quick Tour

Start by going to Facebook Developers. Click Create New App and then Cloud Services → Get Started. A captcha and a button press later, and you’ve got your very own Facebook app running on Heroku! You can git clone the app to start working on it immediately.

This screencast tells the full story:

Detailed instructions available in Getting Started With Your Facebook App on Heroku.

Polyglot Support

Heroku is a polyglot platform, so we’re offering support for the languages that Facebook developers are most likely to use. Apps are created from one of four templates, based on the language choice you make at app creation time: Ruby, Node.js, Python, or PHP.

As part of this launch, we’re including partial support for two new languages: Python and PHP. For now, these languages are only supported for apps created through the Facebook integration.

What This Means

Facebook wanted to make their new app creation process smooth and easy, and knew that they needed to embrace the cloud to do so. As the world’s most mature and powerful cloud application platform, Heroku was the obvious choice.

Our two companies share many product and engineering values, and our teams had a blast working on this together. Our goals were to deliver an integration that:

  • Avoids superfluous steps, like account signup or cutting-and-pasting of config values.
  • Focuses on apps, not servers. When your Facebook app suddenly gets big traffic, the last thing you should be doing is thinking about servers: you need instant scaling.
  • Gets you an app running instantly. Who wants to wait around for minutes while their app "provisions"?
  • Doesn’t force you to make up-front decisions about cost. You don’t need a credit card to get started, and low-volume apps on Heroku are free forever.

For all of the above reasons and more, we believe this makes Facebook and Heroku the perfect combination.

Next Steps

Log in to your Facebook account and visit Facebook Developers to get started.

Further reading:

Play! on Heroku

Developers with experience in both Java and Ruby web development often ask the question: Why is web app development so complicated in Java, and so much simpler in Ruby, with Rails?

There are many ways to answer this question. But importantly, none of them should blame the Java language itself. The people behind Play! Framework proved this by creating a Java based web framework that is as elegant and productive as Rails for Ruby.

It is our pleasure to announce Play! on Heroku in public beta.

Play! on Heroku Quickstart

Download and install Play! version 1.2.3 or later. Then, create a new Play! app:

$ play new helloworld
~        _            _ 
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/   
~ play! 1.2.3, http://www.playframework.org
~ The new application will be created in /Users/jjoergensen/dev/tmp/helloworld
~ What is the application name? [helloworld] 
~ OK, the application is created.
~ Start it with : play run helloworld
~ Have fun!
$ cd helloworld

Create a Procfile:

web: play run --http.port=$PORT $PLAY_OPTS

Commit to Git, then create an app on the [Cedar] stack and deploy:

$ git init
$ git add .
$ git commit -m init

$ heroku create --stack cedar

$ git push heroku master
Counting objects: 30, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (30/30), 35.95 KiB, done.
Total 30 (delta 1), reused 0 (delta 0)

-----> Heroku receiving push
-----> play app detected
-----> Installing Play!..... done
-----> Building Play! application...
       ~        _            _ 
       ~  _ __ | | __ _ _  _| |
       ~ | '_ \| |/ _' | || |_|
       ~ |  __/|_|\____|\__ (_)
       ~ |_|            |__/   
       ~ play! 1.2.3, http://www.playframework.org
       Play! application root found at ./
       Resolving dependencies: .play/play dependencies ./ --forceCopy --sync --silent -Duser.home=/tmp/build_2rgcv7zjrtyul 2>&1
       ~ Resolving dependencies using /tmp/build_2rgcv7zjrtyul/conf/dependencies.yml,
       ~ No dependencies to install
       ~ Done!
       Precompiling: .play/play precompile ./ --silent 2>&1
       Listening for transport dt_socket at address: 8000
       16:14:33,716 INFO  ~ Starting /tmp/build_2rgcv7zjrtyul
       16:14:34,372 INFO  ~ Precompiling ...
       16:14:37,656 INFO  ~ Done.

-----> Discovering process types
       Procfile declares types -> web
-----> Compiled slug size is 26.2MB
-----> Launching... done, v5
       http://blazing-water-545.herokuapp.com deployed to Heroku

Visit your app’s URL to see it running on Heroku.

A Radical Approach to Java Web Framework Design

For as long as developers have been writing web apps in Java, web frameworks have proliferated to try to make web development easier. But no existing frameworks have taken a clean-room approach. They’ve been bound by various self-imposed restrictions such as compatibility with servlet containers, support for JSP, compatibility with the standard Java web app layout, and conformance to Java and OO principles even when they don’t make sense.

Play! is the first Java web framework to start fresh. It is a built-for-deployment framework that borrows heavily from Rails. Play! applications are meant to be deployed, not packaged and distributed. This allows developers to throw away deeply nested Java package structures, control flow in XML, forget about packaging WAR files, and instead structure projects for optimal clarity and developer productivity.

For example, the helloworld app created above contains a single Java class, the controller:

package controllers;

import play.*;
import play.mvc.*;

import java.util.*;

import models.*;

public class Application extends Controller {

    public static void index() {


This class defines a single HTTP entry point processed by the index() method which delegates rendering of output to an index.html template using the render() method.

No boilerplate classes or XML config files are needed. The framework takes a fresh approach to packaging conventions, and uses static code where it makes sense. For example, since controller entry points are stateless, and HTTP-oriented instead of object-oriented, they are implemented as static methods (the index() method above).

Add in developer-convenience features like automatic compilation during development, and you’ll find that Play! is dramatically more productive to work with than any existing Java web framework.

A Containerless World

Jetty has always been at the forefront of containerless deployment, but it has been a lonely place for more than a decade. And the experience can be clunky, because little attention has been paid to optimizing the developer experience for containerless apps. Play! shows how simple and elegant containerless development and deployment can be when it’s directly supported by a framework. Running your app locally is as simple as executing play run. Running it in production is as simple as pushing the entire project to production and executing play run --%prod.

Heroku was designed exactly for this model. Play! applications find a natural home on the Heroku platform. When developing on Heroku, you test your app locally with play run, or foreman start. When you are ready to deploy, you simply push your whole project with git push heroku master and heroku will execute play run in production mode. This results in a deployment workflow with minimal and easily understandable differences between deployment and production. In fact, you can run it locally exactly the same way it runs on Heroku eliminating any problems caused by environment differences.

More Than Just Sugar

One might jump to the conclusion that Play! is overly focused on ease of use at the cost of performance and robustness. After all, isn’t that the reason other frameworks were built on existing, highly optimized libraries?

Look under the covers of Play! and you will find that the start-for-scratch approach gives performance benefits as well. Play! is designed from the ground up to support asynchronous processing of web requests, a technique that is gaining widespread adoption with Node.js, Python’s Twisted, and Ruby’s EventMachine.

Play! uses Netty, a non-blocking I/O protocol library built by the JBoss team. It combines non-blocking I/O with an elegant continuation-based programming model to deliver asynchronous processing of requests.

For example, the rendering of a PDF can be done in the background while suspending the incoming request as simple as this:

public static void generatePDF(Long reportId) {
    Promise<InputStream> pdf = new ReportAsPDFJob(report).now();
    InputStream pdfStream = await(pdf);

Play! also does away with the use of stateful sessions, which are so common in other Java web frameworks. By embracing a share-nothing model, Play! makes it easy to scale out applications horizontally by adding more nodes.

Further Reading

We think you’ll find Play! not only productive, but fun. Dive in and start building apps!

Special Thanks

Special thanks to the Play! Framework team at Zenexity, in particular Guillaume Bort for his support and stewardship and Erwan Loissant for accepting and integration several feature requests.

Polyglot Platform

Programming languages are silos. The libraries, development tools, deployment practices, and even naming schemes associated with one language — say, Ruby — rarely have much carry-over to another language — say, Python, Erlang, Java, or C++.

Professional programmers dedicate their careers to becoming experts in a particular language, making extensive personal investment in learning not only their chosen language’s syntax and libraries, but also the ecosystem of tools and practices from that language’s community. Similarly, companies build up codebases, deployment infrastructure, policies, and tacit knowledge in their engineering staff around a single language.

Deep investment in a single general-purpose programming language has a downside: the law of the instrument. This is completely rational: with so much investment, switching costs are high. But using the wrong tool for the job can heavily dampen developer productivity, and even leads to "religious debates" where programmers assert that their chosen language is the One True Programming Language and the best choice for every purpose.

There’s a better way.

The Modern Age: Polyglot

In contrast to the one-language-per-career programmer, today’s up-and-coming developers can often utilize many languages effectively. Borrowing a term from linguistics, we can call these versatile new developers "polyglot programmers."

The last decade has brought us a renaissance in programming language diversity, with languages like Clojure, Scala, and Go. But many of the languages now gaining popularity have existed for much longer, such as Objective-C, Javascript, and Lua. So what changed in the last few years to awaken the polyglot passions of modern developers?

A parable will illustrate:

Programming enthusiast Joe is browsing Hacker News on a Saturday afternoon, and sees a story about Clojure, a Lisp-like programming language which he keeps hearing about. The comments on the story are filled with positive experiences reported by his peers, so he decides to spend a few hours checking it out.

Within thirty minutes, he’s installed the Clojure language runtime and tools; and downloaded the Peepcode screencast and Pragmatic Studio eBook. With a video describing the language’s core principles running in a background window, Joe tinkers with the basic syntax in the REPL. By the end of the afternoon, Joe has written some simple programs and has a familiarity with both the basic usage of the language, and some of its underlying principles.

From here, it’s a small step for Joe to use Clojure for his next hobby project. And that might lead to using it for a small tool or app at his programming day job, or at his next startup.

Breaking down Joe’s story, we see three factors at play:

  • Programming-centric news aggregators such as Hacker News and the programming subreddit give curious developers exposure to buzz about new languages.
  • Wide availability of easy-to-consume learning materials from sources such as The Pragmatic Bookshelf, O’Reily, Peepcode, along with countless individual blogs, as a way for developers to casually self-educate. Most of these materials can be purchased and downloaded in electronic form instantly; in fact, many programming books are now distributed primarily online, such as the Django book or the CouchDB book
  • The ease of acquiring and installing most modern language runtimes (typically available as open source downloads) allows a developer to get a working toolchain with very low time investment. REPL shells offer an interactive environment for learning the language syntax; some REPLs are even available on the web (see Try Ruby, Try Clojure, Try Python, Simply Scala).

The polyglot tendencies of modern developers can also be seen in the book Seven Languages in Seven Weeks.

Parallels Between Language Communities

With more polyglot programmers than before, there is more cross-talk between language communities than in the past. And whether or not languages are actively sharing ideas, parallels tend to emerge in tools, simply because most languages need to solve similar problems.

For example, a dependency-management system and public repository of libraries are important milestones on the way to a language’s suitability for production use. Tools like REPL shells, embedded webservers, and Rails-like or Sinatra-like web frameworks can now be found in almost every language.

Comparison of Tools and Libraries Across Languages

Dependency Management REPL Embedded Webservers Web Frameworks
Ruby Ruby Gems, Gem Bundler irb Mongrel, Thin Rails, Sinatra
Node.js NPM node http.createServer() Express
Clojure Clojars, Leiningen lein repl Jetty Compojure
Python Virtualenv, Pip python Tornado Django, Pyramid, Flask
Go goinstall yet-another-go-repl http.Handle Web.go
Erlang Rebar erl Yaws, Mochiweb Nitrogen, Chicago Boss
Scala SBT, Scala Tools scala Jetty Lift, Play!
PHP PEAR, PECL php --interactive built-in webserver CakePHP, Symfony
Java Maven, Maven Central none Jetty Spring, Play!
Perl CPAN re.pl Hypnotoad Catalyst, Mojolicious
C Autoconf, Make none Mongoose TreeFrog

There’s more. Most modern apps use the same types of backing services such as datastores (MySQL, PostgreSQL, CouchDB, Redis), caching systems (Memcached, Varnish), and queueing systems (RabbitMQ, Beanstalkd), rather than the language- or framework-specific services of yesteryear (e.g. Erlang’s Mnesia or Zope’s Object Database). There is even convergence on RPC protocols (e.g. REST, AMQP, ZeroMQ, Thrift, Protocol Buffers) and serialization protocols (e.g. XML, Yaml, JSON), making calls between apps written in different languages extremely easy.

Add all these factors together and we see striking parallels across the board between modern web apps, regardless of language used.

The Missing Piece: Deployment Infrastructure

But despite all the convergence between languages during the development cycle, deployment remains its own highly-siloed world. Every language has its own practices, its own tools, and its own terminology for deployment. A Rubyist might use Capistrano to manage deploys, while a Pythonista might use Fabric. Dependency management practices and tools vary wildly not only between languages, but between deploys: one shop might use Chef to install gems system-wide, while another might use Gem Bundler to install gems local to the app. JVM languages (Java, Clojure, Scala, etc) typically expect to be packaged as a WAR to run inside a servlet container such as Tomcat, while scripting languages like Ruby and Python typically use embedded webservers.

The result of all this diversity is that the safe bet, especially for large organizations, is to standardize on a single language and avoid (or even outright forbid) development in any others. Polyglot programming allows using the right tool for the job, offering substantial gains in speed and agility of development; but the switching cost of changing out the entire stack of deployment, scaling, management, and monitoring infrastructure necessary for an app written in a different language creates an intractable obstacle to reaping the benefits of polyglot.

Heroku began working on solving the polyglot deployment infrastructure problem at the start of 2010. Our team was energized by the opportunity we saw here, envisioning a polyglot platform with official support for many languages.

We made an explicit goal to avoid creating mostly separate, language-specific products — Heroku for Ruby, Heroku for Node.js, Heroku for Clojure, and so on — with little relation to each other. Our hypothesis was that it would be possible to create a general-purpose runtime substrate onto which we could layer language-specific workflows to provide a developer experience that felt natural and native for developers from each supported language.

At the same time, we saw the opportunity to bring more normalization and unification to deployment and app management practices across languages. And the developer experience for deploying an app written in any language should always feel like Heroku, with the simplicity, power, and instant-gratification that we are passionate about.

With the launch of Celadon Cedar‘s official support for Ruby, Node.js, and Clojure (and many more to come), we believe we’ve achieved that vision.

Heroku, the Polyglot Platform

Polyglot is as much about recognizing similarities across deployments of different languages as it is about enabling differences among them.

With a truly polyglot platform, choice of programming language is reduced to just syntax and libraries. Uniform deployment infrastructure means that switching languages doesn’t mean fundamentally different deployment endpoints or models. Heroku’s Cedar solves the switching-cost problem: developers can rewrite an app in another language if they choose without changing anything about how it runs, what services it consumes, or how it is monitored and scaled. With Cedar, language choice and deployment infrastructure are orthogonal.

General-purpose tools face the problem of "trying to please everyone pleases no one." Cedar’s approach to solving this is to maintain language-level curation of developer tools, something we call language packs. The owners of each language pack are developers who use and love the language, and are part of its community. It’s of crucial importance that we have real internal users driving the experience for their respective languages.

Implementing the polyglot platform has driven us to find and articulate a universal, language-agnostic interface between the platform and application interfaces. Language-neutral interfaces mean that benefits of the platform accrue to deployments in all languages. For example, logging on Heroku is accessible to and useful for every application, and works out of the box with most languages and web frameworks. Another example is add-ons: most add-ons in the Heroku add-ons catalog are usable from any language available on the Heroku platform, thanks to the language-agonistic configuration via environment variables.


We’re on the cusp of a new golden era for application development: polyglot programming, which enables choosing a specialized language for the problem at hand. But development is only half the story, so it follows naturally that polyglot deployment is needed to complete the picture.

Switching costs on scaling, management, and monitoring infrastructure that historically accompanied a change of language an app was written in have been too high. Heroku Cedar, the polyglot platform, changes all of that. We look forward to announcing official support for more languages in the coming months.

The New Heroku (Part 3 of 4): Visibility & Introspection

Visibility and introspection capabilities are critical for managing and debugging real-world applications. But cloud platforms are often lacking when it comes to visibility. The magical black box is great when it "just works," but not so great when your app breaks and you can’t look inside the box.

Standard introspection tools used in server-based deployments — such as ssh, ps aux, top, tail -f logfile, iostat — aren’t valid in a multi-tenant cloud environment. We need new tools, new approaches. Heroku’s new runtime stack, Celadon Cedar, includes three powerful tools for visibility and introspection: heroku ps, heroku logs, and heroku releases. This post will examine each.

But first, a story.

The Deploy Gone Wrong (A Parable)

The FooBaz Co development team practices continuous deployment, pushing new code to their production app running on Heroku several times a day. Today, happy-go-lucky coder Ned has done a small refactoring which pulls some duplicated code out into a new library, called Utils. The unit tests are all green, and the app looks good running under Foreman on his local workstation; so Ned pushes his changes up to production.

$ git push heroku
-----> Heroku receiving push
-----> Launching... done, v74
       http://foobaz-production.herokuapp.com deployed to Heroku

Ned likes to use the introspection tools at his disposal to check the health of the app following any deploy. He starts by examining the app’s running processes with heroku ps:

$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         crashed for 4s      bundle exec thin start -p $PORT -e..
web.2         crashed for 2s      bundle exec thin start -p $PORT -e..
worker.1      crashed for 3s      bundle exec rake jobs:work
worker.2      crashed for 2s      bundle exec rake jobs:work

Disaster! All the processes in the process formation have crashed. Ned has a red alert on his hands — the production site is down.

Recovering Quickly

Adrenaline pumping, Ned now uses the second introspection tool, heroku logs:

$ heroku logs --ps web.1
2011-06-19T08:35:19+00:00 heroku[web.1]: Starting process with command: `bundle exec thin start -p 38180 -e production`
2011-06-19T08:35:21+00:00 app[web.1]: /app/config/initializers/load_system.rb:12:in `<top (required)>': uninitialized constant Utils (NameError)
2011-06-19T08:35:21+00:00 app[web.1]:   from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.0.7.rc1/lib/rails/engine.rb:201:in `block (2 levels) in <class:Engine>'
2011-06-19T08:35:21+00:00 app[web.1]:   from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.0.7.rc1/lib/rails/engine.rb:200:in `each'
2011-06-19T08:35:21+00:00 app[web.1]:   from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.0.7.rc1/lib/rails/engine.rb:200:in `block in <class:Engine>'

All processes crashed trying to start up, because the Utils module is missing. Ned forgot to add lib/utils.rb to Git.

Ned could press forward by adding the file and pushing again. But the wise move here is to roll back to a known good state, and then think about the fix.

Heroku’s third visibility tool, releases, tracks deploys and other changes. It includes a powerful undo capability: rollback. So Ned takes a deep breath, then runs:

$ heroku rollback
-----> Rolling back to v73... done, v75

Ned checks heroku ps:

$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         up for 1s           bundle exec thin start -p $PORT -e..
web.2         up for 1s           bundle exec thin start -p $PORT -e..
worker.1      starting for 3s     bundle exec rake jobs:work
worker.1      starting for 2s     bundle exec rake jobs:work

The app’s processes are successfully restarting in their previous state. Crisis averted, Ned can now take his time examining what went wrong, and how to fix it, before deploying again.

The Fix

Ned investigates locally and confirms with git status that he forgot to add the file. He adds the file to Git and commits, this time double-checking his work.

He pushes to Heroku again, then uses all three introspection techniques to confirm the newly-deployed app is healthy:

$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         up for 2s           bundle exec thin start -p $PORT -e..
web.2         up for 2s           bundle exec thin start -p $PORT -e..
worker.1      up for 1s           bundle exec rake jobs:work
worker.1      up for 2s           bundle exec rake jobs:work

$ heroku logs
2011-06-19T08:39:17+00:00 heroku[web.1]: Starting process with command: `bundle exec thin start -p 56320 -e production`
2011-06-19T08:39:19+00:00 app[web.1]: >> Using rack adapter
2011-06-19T08:39:19+00:00 app[web.1]: >> Thin web server (v1.2.11 codename Bat-Shit Crazy)
2011-06-19T08:39:19+00:00 app[web.1]: >> Maximum connections set to 1024
2011-06-19T08:39:19+00:00 app[web.1]: >> Listening on, CTRL+C to stop

$ heroku releases
Rel   Change                          By                    When
----  ----------------------          ----------            ----------
v76   Deploy d706b4a                  ned@foobazco.com      1 minute ago
v75   Rollback to v73                 ned@foobazco.com      14 minutes ago
v74   Deploy 20a5742                  ned@foobazco.com      15 minutes ago
v73   Deploy df7bb82                  rick@foobazco.com     2 hours ago

Golden. Ned breathes a sigh of relief, and starts composing an email to his team about how they should really think about using a staging app as protection against this kind of problem in the future.

Now that we’ve seen each of these three visibility tools in action, let’s look at each in more depth.

Visibility Tool #1: ps

heroku ps is a spiritual sister to the unix ps command, and a natural extension of the process model approach to running apps. But where unix’s ps is for a single machine, heroku ps spans all of the app’s processes on the distributed execution environment of the dyno manifold.

A clever trick here is to use the watch command for a realtime display of your app’s process status:

$ watch heroku ps
Every 2.0s: heroku ps                          Sun Jun 19 01:44:55 2011

Process       State               Command
------------  ------------------  ------------------------------
web.1         up for 16h          bundle exec rackup -p $PORT -E $RA..

Leave this running in a terminal as you push code, scale the process formation, change config vars, or add add-ons, and you’ll get a first-hand look at how the Heroku process manager handles your processes.

Dev Center: ps command

Visibility Tool #2: Logs

In server-based deploys, logs often exist as files on disk, which can lead to us thinking of logs as files (hence "logfiles"). A better conceptual model is:

Logs are a stream of time-ordered events aggregated from the output streams of all the app’s running processes, system components, and backing services.

Heroku’s Logplex routes log streams from all of these diverse sources into a single channel, providing the foundation for truly comprehensive logging. Heroku aggregates three categories of logs for your app:

  • App logs – Output from your app, such as: everything you’d normally expect to see in Rails’ production.log, output from Thin, output from Delayed Job.
  • System logs – Messages about actions taken by the Heroku platform infrastructure on behalf of your app, such as: restarting a crashed process, idling or unidling a web dyno, or serving an error page due to a problem in your app.
  • API logs – Messages about administrative actions taken by you and other developers working on your app, such as: deploying new code, scaling the process formation, or toggling maintenance mode.

Filtering down to just API logs is a great way to see what you and other collaborators on the app have been up to:

$ heroku logs --source heroku --ps api
2011-06-18T08:21:37+00:00 heroku[api]: Set maintenance mode on by kate@foobazco.com
2011-06-18T08:21:39+00:00 heroku[api]: Config add ADMIN_PASSWORD by kate@foobazco.com
2011-06-18T08:21:39+00:00 heroku[api]: Release v4 created by kate@foobazco.com
2011-06-18T08:21:43+00:00 heroku[api]: Scale to web=4 by kate@foobazco.com
2011-06-18T08:22:01+00:00 heroku[api]: Set maintenance mode off by kate@foobazco.com

If your teammates are actively performing administrative actions on the app, running the above command with the additional argument of --tail will let you watch the events unfold as they happen. Add watch heroku ps and watch heroku releases in terminals paneled to all be visible at once, and you’ve got a mini-mission control for your app.

Dev Center: Logging

Visibility Tool #3: Releases

Releases are a history of changes to your app. New releases are created whenever you deploy new code, change config vars, or change add-ons. Each release stores the full state of the code and config, in addition to audit information such as who made the change and a timestamp.

This is the release history following Ned’s bad deploy and subsequent recovery:

$ heroku releases
Rel   Change                          By                    When
----  ----------------------          ----------            ----------
v76   Deploy d706b4a                  ned@foobazco.com      1 minute ago
v75   Rollback to v73                 ned@foobazco.com      14 minutes ago
v74   Deploy 20a5742                  ned@foobazco.com      15 minutes ago
v73   Deploy df7bb82                  rick@foobazco.com     2 hours ago

Starting from the oldest release at the bottom:

  • v73 was a code deploy by a developer named Rick from earlier today. This one ran without problems for about two hours.
  • v74 was Ned’s deploy which was missing a file.
  • v75 was the rollback, which Ned ran just moments after the bad deploy. This is an exact copy of v73 (more on this in a moment).
  • v76 was a deploy of the fixed code. Ned was able to spend some time (about ten minutes) double-checking it; the rollback saved him from needing to rush out a fix under pressure.

The top release is always the currently running one, so in this case, we see that v76 is current and was deployed just one minute ago.

More Than Just An Audit Trail

Releases aren’t just a history of what happened, they are a fundamental unit in the machinery of the Heroku platform. The transaction history is the primary source of record, meaning the release is the canonical source of information about the code and config used to run your app’s processes. This is one way in which the Heroku platform ensures uniformity in the version of code and config used to run all processes in the app’s process formation.

Furthermore, releases are an append-only ledger, a concept taken from financial accounting and applied to transactional systems. A mistake in the ledger can’t be erased, it can only be corrected by a new entry. This is why heroku rollback creates a new release, which is an exact copy the code and config for a previous release.

We’re striving to make releases front-and-center in the output from any command that creates a new release. A release sequence number, such as v10, appears any time you create a new release.

Deploying new code:

$ git push heroku master
-----> Launching... done, v10

Setting a config var:

$ heroku config:add FOO=baz
Adding config vars:
  FOO => baz
Restarting app... done, v11

Rolling back:

$ heroku rollback
-----> Rolling back to v10... done, v12

Adding an add-on:

$ heroku addons:add memcache
-----> Adding memcache to strong-fire-938... done, v13 (free)

And as you’d expect, each of the releases above are now listed in heroku releases:

$ heroku releases
Rel   Change                          By                    When
----  ----------------------          ----------            ----------
v13   Add-on add memcache:5mb         kate@foobazco.com     16 seconds ago
v12   Rollback to v10                 kate@foobazco.com     1 minute ago
v11   Config add FOO                  kate@foobazco.com     1 minute ago
v10   Deploy 20a5742                  kate@foobazco.com     11 minutes ago

Releases and rollback are powerful tools for introspection and management. We encourage all developers using Heroku to get familiar with them.

Dev Center: Releases

The Future

Logging, releases, and ps provide a new level of visibility and introspection on the Heroku cloud application platform. But we’re not done yet.

We know, for example, that long-term archival, search, and analytics capability for logs is crucial for production apps, particularly at large scale. We’re working on improvements to Logplex’s storage and retrieval, as well as capabilities for add-on providers to register themselves as log drains, opening up your app to the world of syslog-as-a-service providers and log analytics tools.

More generally, we’re striving to increase visibility across the board — both in our current introspection tools, and by creating new tools. Visibility may initially seem like a minor concern, but as we’ve seen in this post, it has deep implications the Heroku cloud application platform, and for you as a developer managing your production apps.

The New Heroku (Part 2 of 4): Node.js & New HTTP Capabilities

Node.js has gotten its share of press in the past year, achieving a level of attention some might call hype. Among its touted benefits are performance, high concurrency via a single-threaded event loop, and a parity between client-side and sever-side programming languages which offers the Promethean opportunity of making server-side programming accessible to front-end developers.

But what is Node.js, exactly? It’s not a programming language – it’s simply Javascript. It’s not a VM: it uses the V8 Javascript engine, the same one used by the Chrome web browser. Nor is it simply a set of libraries for Javascript. Nor is it a web framework, though the way it is sweeping the early-adopter developer community is reminiscent of Rails circa 2005.

Most would cite Node’s asynchronous programming model, driven by the reactor pattern, as its key differentiator from other ways of writing server-side code for the web. But even this is not new or unique: Twisted for Python has been around for a decade.

So what makes Node special?

The Right Technology at the Right Time

One part of the reason Node.js has captured the hearts and minds of alpha geeks in web development is because it offers all the things described above – a language, a fast and robust VM, a set of compatible and well-documented libraries, and an async framework – all bundled together into a single, coherent package.

The charismatic leadership of Ryan Dahl may be another part of the answer: strong figureheads are often key elements in driving explosive developer community growth (see: Linux/Linus Torvalds, Rails/David Heinemeier Hansson, Ruby/Matz, Python/Guido van Rossum, Redis/Salvatore Sanfilippo, CouchDB/Damien Katz).

But the primary reason is even simpler: Node.js is the right technology at the right time. Demand for asynchronous capabilities in web apps is being driven by what has become known as "the realtime web." Another label for "realtime" (which has a conflicting definition from computer science) is "evented."

Events, Not Polling

The evented web means users getting updates pushed to them as new data becomes available, rather than having to poll for it. Polling is the software equivalent of nagging – not fun or efficient for either end of the transaction.

The rise of an event-driven web makes the appearance of Node.js timely, because Node.js has evented baked in at a level that no other programming language or framework can match. And Node.js being Javascript – a language born of the web – closes the deal.

Unix daemons (such as the famously-fast Nginx) often use evented programming to maximize concurrency and robustness. The seminal C10K article explores the use of system calls such as kqueue and epoll for evented programming. In scripting languages, evented frameworks such as Twisted for Python and EventMachine for Ruby enjoy popularity.

EventMachine is a fascinating case study to compare against Node.js. Because EventMachine’s reactor takes over the entire execution thread (via EM.run), most vanilla Ruby programs require a rewrite to use it, and the developer is cut off from the vast collection of synchronous libraries found in the Ruby ecosystem. A whole slew of em-* libraries have appeared, effectively creating a sub-language of Ruby. The partial incompatibility between Ruby and em-Ruby is a source of confusion for developers new to evented programming.

This is where Node.js succeeds: pulling together the language, the async framework, and a whole universe of libraries guaranteed to work in the evented model.

Node.js on Heroku/Cedar

Heroku’s new runtime stack, Celadon Cedar, includes first-class support for Node.js apps. A quick taste:


var app = require('express').createServer();

app.get('/', function(request, response) {
  response.send('Hello World!');

app.listen(process.env.PORT || 3000);

NPM has become the community standard for dependency management in Node.js. Writing a package.json declares your app’s dependencies and tells Heroku your app is a Node.js app:


  "name": "node-example",
  "version": "0.0.1",
  "dependencies": {
    "express": "2.2.0"

Read the full Node.js on Heroku/Cedar quickstart guide to dive in and try it for yourself.

New HTTP Routing Stack: herokuapp.com

Because the fate of Node.js is entwined so directly with that of the next-generation HTTP techniques (such as chunked responses and long polling), Cedar comes bundled with a new HTTP stack. The new HTTP stack, which runs on the herokuapp.com domain, provides a more direct connection between the end user’s browser (or other HTTP client) and the app dyno which is serving the request.

Here are two examples of apps which use advanced HTTP features for evented apps:

One caveat: we’ve made the difficult decision to hold off on supporting WebSockets, as the protocol is still in flux and not uniformly supported in modern standards-compliant browsers. Once the WebSockets protocol matures further, we’ll be delighted to support it in the herokuapp.com HTTP stack. In the meantime, use the Socket.IO library, which falls back to the best available transport mechanism given the HTTP stack and browser capabilities for a given HTTP request.

The Future

Node.js is still under rapid development, and staying abreast of new releases can be a challenge. Heroku must balance the goals of being a curated, erosion-resistant platform against keeping pace with extremely active developer communities such as Ruby, Ruby/Rails, and Node.js. We look forward to applying all we’ve learned so far to the highly dynamic world of Node.js.

Ruby 1.9.2 Is Now The Default

Ruby 1.9.2 on Bamboo is now the default for new apps created on Heroku.

As we said back in April: Ruby 1.9.2 as the new gold standard for production Ruby apps. In 2011, we’ve seen more and more developers move to 1.9.2. It’s fast, stable, and sees excellent support throughout the community.

You can always list available stacks with the heroku stack command; and if you want your new app on Ruby 1.8.7 you can run heroku create --stack bamboo-mri-1.8.7 to explicitly ask for the older stack.

Celadon Cedar

Super psyched to announce a major new version of Heroku, the Celadon Cedar stack, going into public beta today (previous stacks were Argent Aspen in 2009, and Badious Bamboo in 2010).

Cedar has many new features and updates, but most importantly introduces a new way of thinking about web application architecture and scaling apps on Heroku: the process model. Check it out:

New stack Celadon Cedar moves into public beta today:

$ heroku create –stack cedar
Creating blazing-galaxy-997… done, stack is cedar
http://blazing-galaxy-997.herokuapp.com/ | git@heroku.com:blazing-galaxy-997.git

Cedar Docs

Define your process types with Procfile:

$ cd myapp/
$ cat Procfile
web: bundle exec rails server mongrel -p $PORT
worker: bundle exec rake resque:work QUEUE=*
urgentworker: bundle exec rake resque:work QUEUE=urgent
tweetscan: bundle exec ruby tweetscan.rb
cron: bundle exec clockwork clock.rb

Process Model

Then scale up dynos independently for each process type:

$ heroku scale web=4 worker=2 urgentworker=2 tweetscan=1 cron=1
Scaling processes… done


Inspect the state of all your app’s dynos across the platform:

$ heroku ps
Process State Command
————- ————— ————————————
web.1 up for 6s bundle exec rails server mongrel …
web.2 up for 5s bundle exec rails server mongrel …
web.3 up for 4s bundle exec rails server mongrel …
web.4 up for 5s bundle exec rails server mongrel …
worker.1 up for 5s QUEUE=* bundle exec rake resque:work
worker.2 up for 4s QUEUE=* bundle exec rake resque:work
urgentworker.1 up for 5s QUEUE=urgent bundle exec rake re …
tweetscan.1 up for 5s bundle exec ruby tweetscan.rb
cron.1 up for 4s bundle exec clockwork clock.rb

ps Command

View detailed, consolidated, real-time logs:

$ heroku logs –tail
2011-05-31 04:04:40 heroku[api] Deploy fee72fc by james@example.com
2011-05-31 04:04:40 heroku[api] Release v5 created by james@example.com
2011-05-31 04:04:41 heroku[slugc] Slug compilation finished
2011-05-31 04:04:41 heroku[web.1] State changed from created to starting
2011-05-31 04:04:42 heroku[web.1] Running process with command: `bundle exec rails server mongrel -p 31878`
2011-05-31 04:04:43 app[web.1] >> Listening on, CTRL+C to stop
2011-05-31 04:04:44 heroku[web.1] State changed from starting to up
2011-05-31 04:04:44 heroku[worker.1] State changed from created to starting
2011-05-31 04:04:45 heroku[worker.1] Running process with command: `QUEUE=* bundle exec rake resque:work`
2011-05-31 04:04:45 heroku[worker.1] State changed from starting to up
2011-05-31 04:04:45 heroku[web.2] Running process with command: `bundle exec rails server mongrel -p 31878`
2011-05-31 04:04:46 heroku[worker.2] Running process with command: `QUEUE=* bundle exec rake resque:work`
2011-05-31 04:04:46 heroku[worker.2] State changed from created to starting
2011-05-31 04:04:47 heroku[web.2] Running process with command: `bundle exec rails server mongrel -p 31878`
2011-05-31 04:04:47 heroku[worker.2] Running process with command: `QUEUE=* bundle exec rake resque:work`
2011-05-31 04:04:48 heroku[router] GET sushi.heroku.com/ dyno=web.1 queue=0 wait=0ms service=8ms bytes=179
2011-05-31 04:04:48 app[web.1] – – [15/May/2011 04:05:03] “GET / HTTP/1.1” 200 1 0.0009
2011-05-31 04:04:49 app[worker.1] (in /app)


Run one-off interactive processes in the cloud:

$ heroku run rake db:migrate
Running `rake db:migrate` attached to terminal… up, ps.1
(in /app)
Migrating to CreateWidgets (20110204210157)
== CreateWidgets: migrating ==================================================
— create_table(:widgets)
-> 0.0120s
== CreateWidgets: migrated (0.0121s) =========================================

$ heroku run ruby scripts/fix_bad_records.rb
Running `ruby scripts/fix_bad_records.rb` attached to terminal… up, ps.2

$ heroku run console
Running `console` attached to terminal… up, ps.3
Loading production environment (Rails 3.0.3)

One-off Processes

Official support for Node.js:

$ cd my-node-app/
$ ls
package.json Procfile web.js
$ cat Procfile
web: node web.js
$ git push heroku master
—–> Heroku receiving push
—–> Node.js app detected
—–> Vendoring node 0.4.7
—–> Installing dependencies with npm 1.0.6
mime@1.2.2 ./node_modules/express/node_modules/mime
connect@1.4.1 ./node_modules/express/node_modules/connect
qs@0.1.0 ./node_modules/express/node_modules/qs
express@2.1.0 ./node_modules/express
Dependencies installed
—–> Discovering process types
Procfile declares types -> web
—–> Compiled slug size is 3.1MB
—–> Launching… done, v4
http://radiant-river-296.herokuapp.com deployed to Heroku
$ heroku ps
Process State Command
———— —————— ——————————————–
web.1 up for 10s node web.js
$ heroku logs
2011-03-10T10:22:30-08:00 heroku[web.1]: State changed from created to starting
2011-03-10T10:22:32-08:00 heroku[web.1]: Running process with command: `node web.js`
2011-03-10T10:22:33-08:00 heroku[web.1]: Listening on 18320
2011-03-10T10:22:34-08:00 heroku[web.1]: State changed from starting to up
$ heroku run node
Running `node` attached to terminal… up, ps.1

Node.js on Cedar


  • Cedar uses an entirely new HTTP stack which fully supports HTTP 1.1, long polling, chunked responses, async multi-connection webservers, and more.
  • Cedar features an unprecedented level of isolation and erosion-resistance, keeping dynos running and healthy, even through patches, updates, deploys, failures, and all kinds of app activity.
  • To make more sense with the new process model, we are switching billing units from dynos to dyno-hours, effective June 1, Pacific time. Free plans will be unaffected, just converting units from first dyno free to first 750 dyno-hours free, per app. With few exceptions, the cost of Heroku will be unchanged or less expensive for all users.

We’re really excited about the foundation all of this lays for the great stuff we’ll be releasing over the coming months. For a list of Cedar features, check out the official press release. We will be following up this post with a detailed look at each of the major new areas over the next couple of weeks.

Enjoy. (And please send us your feedback at cedar@heroku.com.)

The Path Forward: Ruby 1.9.2

At Heroku, we’ve been watching the progress of MRI very carefully for a while now; we added support for 1.9.1 nearly a year ago and 1.9.2 more recently, and we’ve seen thousands of apps created and running successfully on the 1.9 series of VMs. At the same time, we’ve seen the community as a whole recognize the importance of 1.9 by migrating libraries and gems to it and providing resources and tutorials on upgrading.

Today, Heroku is putting our full support behind Ruby 1.9.2 as the future of MRI. It is a stable, battle-tested, production-quality Ruby, and we’re excited to see it become the mainstay for future Ruby development.

What this means today

We encourage all Heroku developers to use Ruby 1.9.2 for new apps. You can create an app on 1.9.2 with the following command:

$ heroku create --stack bamboo-mri-1.9.2

We also encourage developers to port (or at least test) existing apps on 1.9.2, and to contribute bug reports, feedback, and patches to libraries that aren’t currently 1.9.2-compatible:

$ heroku stack:migrate bamboo-mri-1.9.2

As part of this effort, we have also deprecated the bamboo-mri-1.9.1 stack. Apps that are currently running on it will not be affected, but no new 1.9.1 apps can be created, and you are no longer able to migrate to 1.9.1.

What this means going forward

As of now, bamboo-ree-1.8.7 is still the default stack for new Heroku apps. As support for Ruby 1.9.2 continues to improve, we will regularly review this, with the goal of making 1.9.2 the default in the future. We’ll provide plenty of notice before this switch, of course.

Resources for Ruby 1.9.2

There are a number of great resources for learning about and trying out Ruby 1.9.2. Here are some of our favorites, but feel free to leave yours in the comments!

  • Programming Ruby 1.9 – the latest edition of the book that brought Ruby to the English-speaking world.
  • RVM – we recommend RVM for managing your Rubies in development; it makes testing apps against alternate implementations as painless as possible.
  • Upgrading to Ruby 1.9 – David A Black’s summary of the top 10 things to watch out for when moving from 1.8 to 1.9 – and don’t miss the sequel, which contains even more good information.
  • Is It Ruby 1.9? – a community-powered site for monitoring gem compatibility (and be sure to contribute to it!)

New Logging Now in General Availability

In December, we rolled out the public beta of a sweet new logging system for Heroku. The new system combines log output from your app’s processes and Heroku’s system components (such as the HTTP router). With all of your logs collated into a single, time-ordered stream, you get an integrated view of everything happening in your app.

Here’s a sample:

$ heroku logs
2010-10-21T14:11:16-07:00 app[web.2]: Processing PostController#list (for at 2010-10-21 14:11:16) [GET]
2010-10-21T14:11:16-07:00 app[web.2]: Rendering template within layouts/application
2010-10-21T14:11:16-07:00 app[web.2]: Rendering post/list
2010-10-21T14:11:16-07:00 app[web.2]: Rendered includes/_header (0.1ms)
2010-10-21T14:11:16-07:00 app[web.2]: Completed in 150ms (View: 27, DB: 121) | 200 OK [http://myapp.heroku.com/]
2010-10-21T14:11:16-07:00 heroku[router]: GET myapp.heroku.com/ dyno=web.2 queue=0 wait=0ms service=251ms bytes=24523
2010-10-21T14:11:16-07:00 heroku[nginx]: GET / HTTP/1.1 | | 247 | http | 304

Logging comes in three plans:

  • Basic provides access to logs from your app and the Heroku system.
  • Expanded includes feature upgrades such as realtime tail and filtering. It’s free for verified users.
  • Advanced supports high-traffic, production-grade apps with truly powerful features such as unlimited throughput and syslog drains. This plan is priced at $100.

Today we’re taking the beta label off of all the Logging add-on plans and moving them to general availability. All new apps will get basic logging by default, and existing apps can opt in to the new system by installing the logging:basic add-on. Make sure you have the latest Heroku client gem (gem install heroku) to access the client-side features of the new logging system.

Improved Maintenance Mode for All Apps

The improved maintenance mode we described last month is now standard for all existing and new apps.

This new maintenance mode is faster and much more scalable, particularly for apps with more than fifty dynos. It handles maintenance mode at the HTTP router, providing an instantaneous response for turning maintenance mode on or off regardless of the size of your app.

It uses a standard page which serves with an HTTP 503 code. You can use the Custom Error Pages add-on to provide your own maintenance page to the router.

(If you preferred the old maintenance mode, you can manually add it to your app by installing this middleware and setting a MAINTENANCE config var.)

Read the docs for usage instructions on the new maintenance mode.

A New Approach to Errors

When your app is crashed, out of resources, or misbehaving in some other way, Heroku serves error pages to describe the problem. We also have a single page for platform errors, once known as the ouchie guy (pictured right).

While the approach of showing error information directly via the web has worked well enough, there was room for improvement on both developer visibility and professionalism of presentation to end users. With that in mind, we’ve reworked our approach on error handling, making improvements that should make it much easier for you, the developer, to diagnose and correct errors in your app.

This new approach can be broken down into four features:

  1. Consolidated error page
  2. Logging of error codes
  3. Custom Error Pages add-on
  4. Improved maintenance mode

These items are now available in public beta, activated by installing the Custom Error Pages add-on. Once the public beta period is over, items 1, 2, and 4 will become the default for all apps.

Let’s take a tour of this new world of error handling.

Consolidated Error Page

An error being served in a high-traffic app is more likely to be served to an end user than to the application developer; so showing information like “backlog too deep” or “request timed out” is useless and potentially confusing to the viewer. All error pages served over HTTP are now represented by a consolidated error page, and always serve with an HTTP status code of 503.

Logging of Error Codes

Because we’re no longer putting details of the error into the page served via HTTP, you’ll need to get at them some other way. In this new model, error details are now part of your application’s log. We’ve assigned a unique code to each type of error, and they’l be placed alongside the log line produced by the HTTP router. Like this:

18:05:10 heroku[router]: Error H12 (Request timeout) -> GET myapp.heroku.com/errortest dyno=web.1 queue=0 wait=0ms service=30000ms bytes=0

In this example, the dyno spent too long servicing the request and was timed out by the router. Each type of error gets its own error code, with all HTTP errors starting with the letter H. Here’s the complete list of error codes. In the future we’ll be adding codes for other kinds of errors that can occur (for example, errors during deployment).

Note that you’ll need the new logging add-on in order to see error code logging.

Custom Error Pages

The standard error page is unbranded, but you might wish to use an error page styled to match the rest of your site. You can’t do this directly, because these error pages are generated from outside your app. (When your app is broken or overloaded, it’s impossible for it to serve any page.)

The Custom Error Pages add-on gives you the ability to specify a URL to your own error page, which can have any text and style you want. Usage is simple:

$ heroku addons:add custom_error_pages
 Adding custom_error_pages to myapp...done.
 $ heroku config:add ERROR_PAGE_URL=http://s3.amazonaws.com/your_bucket/your_error_page.html

You can put your HTML anywhere, though we recommend S3 for its simplicity and reliability. Full docs for Custom Error Pages.

Improved Maintenance Mode

The final piece of the puzzle is a new maintenance mode, to address problems with our current maintenance mode implementation for apps with more than fifty dynos. This new implementation handles maintenance mode at the HTTP router, providing an instantaneous response for turning maintenance mode on or off regardless of the size of your app. It uses a standard page which serves with an HTTP 503 code. You can use the Custom Error Pages add-on to provide your own maintenance page to the router. (If for some reason you prefer the current maintenance mode, it’s available as Rack middleware.)


During the beta, adding the Custom Error Pages add-on will turn on the consolidated error page, logging of error codes, and the new maintenance mode. When the beta is over, everything other than the add-on itself will become standard for all apps. Custom Error Pages will become a premium-priced feature after the beta, reflecting its nature as useful primarily to production apps with significant investment in their brand image.

We believe these changes will significantly improve the experience of dealing with errors on Heroku. Give it a try and tell us if you agree!

Win a MacBook Air with Heroku + IndexTank

We’re very excited about the growth of the add-on ecosystem following the launch of the provider program — with dozens of add-ons in various stages of release, our developers have access to a wide variety of functionality for their applications. One of the most recent additions to the generally-available add-on catalog is IndexTank, a real-time search-as-a-service with some great features.

In order to celebrate their release, IndexTank is sponsoring a contest over the holiday season. From last week until January 6th, they’re inviting developers to build the best app they can using the IndexTank add-on. You can see the full details over on IndexTank’s blog, but the TL;DR of it is: build something awesome on Heroku with the IndexTank add-on (they’re offering their $300/month plan for free during the contest) and submit it for judging.

If you don’t have a huge dataset to work with, they’ve also got some great suggestions — everything from the Twitter firehose and Wikipedia to open government data from Sunlight Labs. As for prizes, they’re giving away a Macbook Air, a USB mini-monitor, and a t-shirt with a working guitar on it(!).

Sneak away from the family for a little while over the holidays and make something great — get started today!

PostgreSQL 9 Public Beta

At Heroku, we believe PostgreSQL offers the best mix of
powerful features, data integrity, speed, standards compliance, and
open-source code of any SQL database on the planet. That’s why we
were so excited to see the new release of PostgreSQL, version 9.0.1.

The release is described as “the most anticipated PostgreSQL version in five years” for good reason. The release adds over 200 new features and improvements. For more on PostgreSQL 9, see the coverage in Computerworld, Infoworld, and Linux.com as well as the discussion on Hacker News.

Today we are making PostgreSQL 9 available to all Heroku users through our public beta program. It is offered as a dedicated database with specifications identical to our existing Ronin plan. As a beta release, we do not recommend using this for production applications.

This is an excellent opportunity to test the compatibility of your schema and application code with PostgreSQL 9, and to try out its new features. Please note that our implementation does not yet support streaming replication or hot-standbys.

The beta will be available for free provided that you test its compatibility with your application and fill out this brief questionnaire . If you do not fill out the form we will charge the standard Ronin rate of $200 / month. The beta plan will be available for one month, after which we will ask users to migrate to non-beta plans.

To provision PostgreSQL 9 on a new application and restore a PG Backups database backup, use the following commands:

$ sudo gem install heroku     # To install the latest version of the Heroku gem
$ heroku addons:add heroku-postgresql:pg9test --app <your test app name>
$ heroku pg:promote --db HEROKU_POSTGRESQL_PG9TEST_URL --app <your test app name>
$ heroku pgbackups:restore `heroku pgbackups:url --app <your production app name>`

Give it a try and let us know what you think.

Heroku Gets Sweet Logging

Access to application logs on Heroku has historically been one of the least usable functions of the platform. The “heroku logs” command was nothing more than a broadcast fetch of the logfiles for every web and worker dyno in your app. This worked ok for small apps, but the user experience became very poor once you got past five or ten dynos.

I’m incredibly excited to announce that today we’re rolling out the public beta of our new logging add-on. This is a whole new way of capturing and collating logs, based on a syslog routing layer we’ve dubbed Logplex. Logplex routes syslog traffic the same way that our HTTP routing mesh routes HTTP traffic. Not coincidentally, Logplex was built by Orion Henry and Jacob Vorreuter, the same geniuses behind the Heroku HTTP routing mesh.

Using Logplex, we can route logs not only from all of your application processes (web, worker) into a single location. Even better, infrastructure components in the platform that interact with your app can also write to the same place. For example, here’s a snippet of logs from a single HTTP request to a Rails app:

$ heroku logs
2010-10-21T14:11:16-07:00 app[web.2]: Processing PostController#list (for at 2010-10-21 14:11:16) [GET]
2010-10-21T14:11:16-07:00 app[web.2]: Rendering template within layouts/application
2010-10-21T14:11:16-07:00 app[web.2]: Rendering post/list
2010-10-21T14:11:16-07:00 app[web.2]: Rendered includes/_header (0.1ms)
2010-10-21T14:11:16-07:00 app[web.2]: Completed in 150ms (View: 27, DB: 121) | 200 OK [http://myapp.heroku.com/]
2010-10-21T14:11:16-07:00 heroku[router]: GET myapp.heroku.com/ dyno=web.2 queue=0 wait=0ms service=251ms bytes=24523
2010-10-21T14:11:16-07:00 heroku[nginx]: GET / HTTP/1.1 | | 247 | http | 304

The logs show not only the Rails logs from the dyno which served the request (web.2), but also logs from the HTTP routing mesh and Nginx. We also log events like web dynos idling and un-idling, process restarts, and more.

The logging add-on also adds some seriously bad-ass client-side features. You can filter down to an individual source or process (for example, just your app logs, or just the logs from worker.1). And realtime tail (heroku logs —tail) is spectacular for any app that’s doing heavy background processing. The docs have all the details.

Keep in mind that this is a beta feature, so there will be a few rough edges. During the beta process we need to prove that Logplex can scale to handle the huge volume of logs being generated by all the apps running on Heroku. We’re also working on more options for long-term archival and search of app logs. Once these questions are answered we’ll be able to remove the beta label, at which time the logging:basic add-on will become the default for all new apps.

The Next Level

What if enterprise apps were built the way you’d build an agile Ruby app? What if they were a pleasure to work with, deploy, and manage? What if big companies could adopt the philosophies of Heroku and the Ruby community? What if your company actually preferred you use Heroku to build apps?

That’s the next level for Heroku. That’s where we want to go, so we’ve made a decision we’re excited to share: we have signed a definitive agreement to be acquired by salesforce.com. We expect the deal to close by January 31st.

Why Salesforce.com?

Salesforce.com is the original cloud company. They convinced the enterprise world to consume software as a service before Gmail, Basecamp, or Facebook existed. They created one of the world’s first platforms-as-a-service and helped popularize the term. They get it.

Heroku always aspires to be trusted by more customers with their data and applications. Salesforce.com has achieved a level of trust and credibility unparalleled in the cloud. They are trusted today by the largest companies on the planet to store their most sensitive data. And their sales and support organizations are second to none.

We have long been fans of salesforce.com due to the unusual philosophies they share with us:

No software, no private cloud
There is so much value provided to customers when they consume services rather than buying software and running it themselves. Salesforce.com is religious about not selling software for private cloud use, and so are we.

Abstraction = Value
Don’t make users, customers, or developers do anything they don’t have to. Let them focus 100% on their data and their applications. Most products are more hands on and less abstract than Heroku. Salesforce.com however, is even farther down the abstraction curve than we are.

Multi-tenancy enables continuous upgrades and improvements, maintainability, and scale. Multi-tenancy is an architectural decision key to how both Heroku and salesforce.com have achieved success.

Salesforce.com Loves Heroku

Salesforce.com loves our developers and the community and culture they have brought to our platform. They love our maniacal focus on the developer experience. They love that we are a 100% open platform, enabling openness and choice everywhere we possibly can. They love that we support the tools and languages and architectures of the next generation of web apps.

Salesforce.com aspires deeply to these same goals and sees Heroku as leading the way. Together we can bring an open platform for modern apps to enterprise customers.

To hear this in the words of salesforce.com, see founder Parker Harris’s blog post: What I Love About Heroku.


Salesforce.com loves who we are and wants to preserve our brand, product, our values, and our roadmap. Though we’re joining forces, Heroku will remain independent.

This means the whole Heroku team, the founders, our technology and services, our free offerings for developers, our exciting roadmap, existing customer signup process, and most importantly our philosophies will remain intact and unchanged.

Our focus on design and user experience will stay as sharp as ever; we will stay purple. The Heroku you know will continue to grow.

Our roadmap stays the same, but we can do more of it, faster. Joining forces with salesforce.com gives us an enormous amount of fuel to keep building the platform toward the vision we’ve always had.


This deal is a victory and validation for all of our early adopters, our passionate users and customers, and for the Ruby community as a whole. The combination of salesforce.com’s trust and credibility with Heroku’s developer-focussed platform will be an incredible force pushing Ruby into the mainstream.

Heroku has been designed from the beginning to support multiple languages, but Ruby will always be our first love.

As we’ve talked about before, over the long run we want to constantly support more use cases and allow developers to choose the right tool for the job, like we did with our experimental Node.js support. Joining forces with salesforce.com doesn’t change this; we will add other languages when and where we feel it advances those goals.

Amazon and Ecosystem

Our relationship with Amazon Web Services will remain unchanged. We are huge fans of Amazon’s EC2 and the fast growing ecosystem of cloud services within it, and have no plans to leave. We are likely to add additional infrastructure providers over time to support a variety of customer use cases, and as above, we will follow the same path and decision making process we always have.

Great for Developers and Customers

Heroku will always be focused on developers above all else. Salesforce.com deeply understands why that is valuable and is making an enormous bet that we will continue to make developers happy. Not only does Salesforce.com want us to continue on unchanged, but they hope through this merger some of Heroku’s philosophies will rub off on them.

With salesforce.com’s trust and credibility, it will soon be a no-brainer to convince your company to use Heroku for your important projects.

With salesforce.com’s huge reach, we will be able to grow the ecosystem faster. This means more add-on providers with more great cloud service options for developers.

For customers, this means we will soon provide better sales processes for larger organizations, add more trust and security for data and applications, achieve more IT policy compliance, and provide more premium support options.

Great for Add-on Providers

The salesforce.com brand plus accelerated growth of the developer base, the types of applications on the platform, and the number and size of customers all bring huge opportunity for add-on providers.

Our Commitment

The founders and the whole team at Heroku are 100% committed to the long term vision we have shared since the beginning. This is Heroku going to the next level; a chance to further our vision, to take things to a larger scale, and to reach a wider audience than ever before with our product and our message about next-generation deployment.

We couldn’t be more amped!

The Heroku Team

Official press release here.

Bundles Deprecation

Recently we announced the release of PG Backups, our new database backup service. Since then, PG Backups has seen rapid adoption and has been successfully managing the backups of a large and growing number of our production customers.

Today we are announcing the deprecation of Bundles. Although Bundles has served the Heroku community well, we have found that it doesn’t scale to adequately meet the needs of the larger, more complex applications running on Heroku today.

We encourage all of our users to migrate their application backup strategy to PG Backups as soon as possible.

Starting today (November 30, 2010) we will no longer allow the Bundles add-on to be added to applications. Applications that already have Bundles installed will continue to function normally.

On February 1, 2011, Bundles will cease capturing new backups. By this time all active applications on Heroku should have switched to using PG Backups to backup their data.

Backups made with Bundles will continue to be available until April 4, 2011. After that time users will no longer be able to download or restore from Bundles-based backups. Please download any backups that you wish to permanently archive prior to this date.

Release Management on Heroku

When a team of developers uses continous deployment to deploy to their Heroku staging and production apps multiple times per day, having a record of what was deployed and when can be very valuable. This is especially true when bad code gets deployed: being able to recover quickly from failure is a key part of any agile process.

Today, Heroku is announcing our release management add-on. When installed on an app, every code deploy is recorded in a ledger with information about who deployed, when, and what commit hash. And it’s not just code: anything that changes the app environment, such as adding or removing add-ons or changing config vars, creates an entry in the release ledger. It looks like this:

$ heroku releases
Rel   Change                By                  When
----  -------------------   ----------          ----------
v17   Deploy 38a0f41        julie@example.com   7 minutes ago
v16   Config add API_URL    steve@example.com   31 minutes ago
v15   Maintenance off       joe@example.com     6 hours ago

The audit trail for deploys is useful information, and you can use a releases:info command to zoom in and get exact details for each release. But what’s even better is being able to roll back from bad deploys, like a giant undo button for your app.

$ heroku rollback
Rolled back to v16

The rollback command restores the previous release (or any release that you specify). Rollbacks are a very quick operation, because unlike pushing up new code, your slug doesn’t need to be recompiled. This is particularly significant for large apps with many gem dependencies.

Release management isn’t terribly important for small apps; but for large production apps with many developers, frequent pushes, and lots of code, it’s vital. The basic release management add-on (two levels of release history, one level rollback) is free; the advanced add-on (unlimited history and rollbacks) will be premium priced.

Read the docs, then give it a spin and let us know how it works for you.

This is the second in a series of new features targeted at large production applications (the first being support for larger databases). More features in this vein are coming soon!