William Riker

Riker turns Amazon Web Services into your very own Platform as a Service, giving you the same ease-of-use that platforms like Heroku provide, while retaining the control that is attractive about AWS.

Getting Started

Getting started with Riker is easy: just install it using pip and Riker will prompt you for the necessary information it needs:

$ pip install riker
$ riker config

Deploy a Node.js app

First, let’s clone a sample Node.js app:

$ git clone git@github.com:heroku/node-js-sample.git
$ cd node-js-sample

Then deploy it with just one command:

$ riker deploy

And open it in your default web browser:

$ riker open

That’s it! While this example deploys a sample Node.js application, any language can be deployed, since Riker uses Heroku Buildpacks. More information on exactly what buildpacks Riker supports, and how to use a custom buildpack.

Deploy a static website

Riker can also be used to deploy static websites to S3, rather than running nginx or apache in an EC2 instance to serve static files:

First, generate a static website:

$ mkdir static-website && cd static-website
$ echo "Hello, World" > index.html
$ touch .s3 # tells Riker to deploy to Amazon S3
$ git init && git add -A && git commit -m "Initial commit"

Then use the same commands as before to deploy and open the website:

$ riker deploy
$ riker open

Scalable, zero-downtime deployments

Riker provides a scalable mode (--scale), where load balancing and auto-scaling are configured for you. This also ensures zero-downtime during deployments.

$ riker deploy --scale

How It Works

Riker provides a set of best-practices and structure to your infrastructure, while leaning on as much of the features AWS provides as possible.

Riker doesn’t require its own server to be running; it’s just a deployment tool (though it’s best to run Riker in a CI server like Jenkins).

Riker also abstracts away the EC2 instances, and instead lets you only care about the application itself: code, dependencies, and configuration. Riker makes your instances easy to destroy and recreate, removing the need to ever manually provision a machine. This also makes scaling trivial. To enable this abstraction, Riker uses Docker to run your application in its own sandbox, as well as Heroku Buildpacks to deploy many different types of applications. Today, Riker also uses Dokku, but may move away from it to allow Riker to also run your application locally during development, but more about that later.

By default, Riker will deploy changes directly to existing instances. However, with the --scale flag, Riker will deploy changes to new instances, and only swap old instances out for new instances when the new instances become healthy, and the old instances no longer have active connections.


While Riker is in active development, it’s probably not ready for prime-time, unless you’re really willing to help contribute and test things out.


There are many ways you can help make Riker better:

Let me know what you think! Look for subsequent posts about the rationale behind Riker and why it’s different than other comparable services.

You’re the captain - make Riker your "Number One"

William Riker