Introducing the app.json Application Manifest

Developers want to spend less time setting up applications and start working with the code sooner. Setting up applications is error-prone, time consuming and interruptive to the development flow. Often, there are several steps to go from your code or other samples and templates that you find in repositories online, to a running application that you can continue to work on.

Today, we are excited to introduce the app.json manifest. app.json enables developers to define their applications' details, setup configurations and runtime environments in a structured way. Instead of providing step-by-step instructions, you can now add app.json files to your applications' source code. You and other developers can then easily deploy the source code into fully configured apps on Heroku, ready for further development.

The new app-setups endpoint in the Heroku Platform API leverages app.json to make setting up of complex applications as simple as a single API call. app-setups orchestrates the different steps involved in getting an application deployed and running, freeing up developers everywhere to quickly start working on the code in a fully configured application environment.

Read more →

Presenting the New Add-ons Site

Heroku Add-ons make it easy for developers to extend their applications with new features and functionality. The Add-on Provider Program has enabled cloud service providers with key business tools, including billing, single sign-on, and an integrated end-user support experience. Since the launch of the Heroku Add-ons site over two years ago, the marketplace has grown to nearly 100 add-ons. As the add-ons ecosystem has grown, we've learned a lot about how cloud service providers structure their businesses and how users interact with them.

Today we're happy to announce the launch of the updated Heroku Add-ons site.

The goal of the new site is to make it even easier to find, compare, purchase, and use add-ons. In addition to categorization, tagging, search, and an add-on showcase, we've made it easier to understand the benefits of each add-on, distinguish between plans, access documentation, and provision add-ons from the web or the command line. Here are some highlights of the new design:


We're now featuring add-ons on the homepage in an active rotation based on three criteria: newness, popularity, and staff picks.

Add-ons Showcase


We've introduced categories to help you make more informed decisions about which add-ons are right for your use case, like which database to use.

Add-ons Categories


The home page now features a lightning-fast search field. Each search result includes the CLI command to install the add-on, so if you know the add-on you're looking for you can be on and off the site in a matter of seconds.

Add-ons Search

The search tool also has some handy vim-inspired keyboard shortcuts:

  • / focuses the search field.
  • esc clears the search field.
  • j (or down arrow) moves you down in the results.
  • k (or up arrow) moves you up in the results.
  • o (or enter) opens the currently selected search result.
  • y selects the CLI command so you can copy it.

Emphasis on Productivity

In the new marketplace, we've encouraged add-on providers to highlight the ways in which their add-on will improve developers' lives. Rather than emphasizing technical commodities like megabytes of cache or number of allowed requests, benefits highlight the high-level value of each service, such as ease of integration, time saved, and higher productivity.

Add-on Benefits: CloudAMQP

Clear differentiation of Plans

The new plan interface makes it easier to distinguish how an add-on's offerings change across plans.

Add-on Plans

Dev Center Documentation

We've added tighter integration with Dev Center for easy access to each add-on's documentation.

Add-on Documentation

Looking Forward

As of today, the new Add-ons Marketplace is the default for everyone on the platform. Watch closely for updates and new features. To stay up to date as new add-ons enter the marketplace, check out the new add-ons changelog and subscribe to the feed or follow our new twitter account, @HerokuAddons.

Heroku is hiring

Heroku Scheduler Add-on Now Available

Today we're happy to announce the availability of Heroku Scheduler. Scheduler is an add-on for running administrative or maintenance tasks, or jobs, at scheduled time intervals. It's the polyglot replacement of the Cron add-on, with more power and flexibility. And it's free; you just pay for the dyno time consumed by the one-off tasks.

A dashboard allows you to configure jobs to run every 10 minutes, every hour, or every day, and unlike the Cron add-on, you can control when. E.g. Every hour on the half-hour, or every day at 7:00am.

Scheduler Dashboard

Polyglot Tasks

Tasks are any command that can be run in your application or even the Unix shell.

For Rails, the convention is to set up rake tasks. To create your scheduled tasks in Rails, copy the code below into lib/tasks/scheduler.rake and customize it to fit your needs.

desc "This task is called by the Heroku scheduler add-on"
task :update_feed => :environment do
    puts "Updating feed..."
    puts "done."

task :send_reminders => :environment do

If you're using Python with the popular Fabric automation tool, you can define a fab clean_sessions task:

from fabric.api import task

def clean_sessions():
    url = urlparse(os.environ.get('REDISTOGO_URL'))
    db = redis.Redis(host=url.hostname, port=url.port, password=url.password)
    print 'done.'

For apps built on other frameworks or languages, another convention is to add a script to bin/ that will perform the task. E.g. bin/updater.

Scheduling Jobs

To schedule a frequency and time for a job, open the scheduler dashboard by finding the app in My Apps, clicking "General Info", then selecting "Scheduler" from the Add-ons dropdown.

On the Scheduler Dashboard, click "Add Job...", enter a task, select a frequency and next run time.

Note that the next run time for daily jobs is in UTC. If you want to schedule the job at a certain local time, add the proper UTC offset.

For example, add rake update_feed, select "Hourly" and ":30" to update feeds every hour on the half-hour. Then add rake send_reminders, select "Daily" and "00:00" to send reminders every day at midnight.

Migrating From the Cron Add-on

Existing Cron add-on users should migrate to Heroku Scheduler as soon as possible. It has more functionality, is easier to use, and is free. Cron is restricted to running a single command, rake cron and does not provide control over when daily and hourly tasks are run. Scheduler can do everything the Cron add-on does, and more.

If you want your new jobs to be scheduled as close as possible to when your Cron jobs would run, go to the Cron dashboard and look at the "Scheduled for" information. Then in the Scheduler dashboard, create a new task, set it to be either hourly or daily, and then set the Next Run field to the selection closest to the previous scheduled time. Set the task to rake cron.

RabbitMQ Add-on Now Available on Heroku

Today we're proud to announce the availability in beta of RabbitMQ add-on by VMWare. RabbitMQ is an open source implementation of the AMQP protocol that provides a robust, scalable and easy-to-use messaging system built for the needs of cloud application developers.

Getting Started

With the add-on, provisioning a fully managed RabbitMQ instance couldn't be easier to do:

$ cd rabbitdemo
$ heroku addons:add rabbitmq
-----> Adding rabbitmq to rabbitdemo... done, v2 (free)

$ heroku config
RABBITMQ_URL  => amqp://

Your application's environment will now have the RABBITMQ_URL set pointing to your new instance. Most modern AMQP clients such as Bunny for Ruby will accept a connection string in URI format, making configuration a breeze. The following is a simple Sinatra app that demonstrates posting and getting messages from the default RabbitMQ exchange. You can grab the source from Github here. Let's have a look:

Entering a message and hitting "post" will send a message to a RabbitMQ queue, where it will sit until we tell the app to fetch the oldest message from the queue by clicking "get". Examining the application code, the first place to look is in "lib/sinatra_rabbitmq.rb" where we set up the connection from the environment variable, and declare a queue called "messages":


require 'sinatra/base'
require 'bunny'

module Sinatra
  module RabbitMQ
    def rabbitmq_client
      return @rabbitmq_client if @rabbitmq_client
      @rabbitmq_client =["RABBITMQ_URL"])

    def rabbitmq_exchange
      @rabbitmq_exchange ||="")

    def rabbitmq_messages_queue
      @rabbitmq_messages_queue ||= rabbitmq_client.queue("messages")

  register RabbitMQ

Note that in RabbitMQ a message is never sent directly to a queue. Instead, it passes through an exchange, the type of which defines how messages are distributed to one or more client queues. In this case, we're side-stepping the concept of exchanges by using the default nameless exchange, which allows us to specify the target queue for our messages using a routing key. Once you get into more advanced usage of RabbitMQ such a broadcasting messages to set of known queues, you'll definitely want to learn more about exchanges.

With our connection established and queue defined, the main part of our app looks like this:


require 'sinatra/base'
require "#{File.dirname(__FILE__)}/lib/sinatra_rabbitmq"

class RabbitmqDemo < Sinatra::Base
  register Sinatra::RabbitMQ

  get "/" do
    haml :index

  post "/" do
    self.class.rabbitmq_exchange.publish params["message"], :key => "messages"
    @notice = "Message has been published."
    haml :index

  get "/message" do
    msg = self.class.rabbitmq_messages_queue.pop
    if msg[:payload] == :queue_empty
      @notice = "No more messages."
      @message = msg[:payload]
    haml :index

The first interesting part here is post to "/" where we send the message you typed in to the default exchange, using "messages" as the routing key. Then we pick up any outstanding at "/messages" by popping off the queue, which follows the FIFO principle. The rest, as they say, is just a bit of HTML.

Why would you want to use a messaging system?

The distribution of workloads across different process types is an essential aspect of modern web application architecture. For example, if your app handles file uploads, your web process might receive the upload and signal a background worker to do some processing on it via a queue. While you could use Delayed Job or another database-backed queueing library to do this, a true messaging system gives you much more flexibility, reliability and scalability in defining how your signals are distributed and received by your worker pool.

Finally, messaging is an important tool for the polyglot programmer. Having a language agnostic, data-centric message bus that can orchestrate communications between, say, a web app in Ruby, workers in Java and a chat server in Node.js is a key enabler in allowing application developers choose the right tool for any specific job.

Over the past few years RabbitMQ has emerged as one of the most popular, open source choices for messaging with clients in all major languages, and thousands of enterprises trusting it for mission-critical apps. We're excited to offer it as a cloud service through the Add-ons Catalog, fully managed and operated by the team who created it.

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