Heroku Buildpack Equivalents for Python, Rails, Other Languages Supported by Nanobox

Web developers and their peers have become increasingly familiar over the past decade with Heroku's Platform as a Service (PaaS) product as a convenient way to deploy applications to the cloud and manage them live in production.

Since Heroku first became popular as a way to automate deploying and managing Ruby apps in production, it has become a polyglot platform, expanding to include support for the most popular of web programming languages used on the web.

Those in the web development and DevOps world who are just learning about Nanobox coming from the context of Heroku often wonder how the Heroku setup differs from Nanobox, specifically how Heroku buildpacks translate over to their equivalents on Nanobox.

tl;dr: Heroku buildpacks are equivalent to Nanobox engines.

Differences Between Heroku and Nanobox

Before we jump into Heroku buildpacks and how they are different from Nanobox engines, it's helpful to review some of the significant differences between Heroku and Nanobox, especially when viewed through the spectrum of the development to production workflow.

One of the fundamental differences between using Heroku versus Nanobox to deploy is upstream from the deployment process.

Whereas with Heroku, applications are built outside of the deployment and hosting platform, with Nanobox, the entire development to production workflow is covered. The exact same environments that are used in local development using the Nanobox platform are also used for deployment and production settings. This makes it so that there are no surprises in production.

The graphic below depicts the differences in dev-to-production workflow coverage between Nanobox and Heroku in addition to some of the other popular development and deployment platforms currently being used, including Google-sponsored Kubernetes.

Heroku Buildpacks Don't Cover the Local Dev and Staging Parts of the Dev-to-Production Workflow

Other differences between Heroku and Nanobox are detailed in some of our other documentation. To summarize:

  • Heroku runs on top of AWS, so if you host with Heroku, you likely experience a case of vendor lock-in.
  • Heroku sometimes lacks the flexibility desired by users with respect to pricing and control over infrastructure architecture because of how it packages AWS hosting. Because Nanobox is host-agnostic, you have more control over costs and more granular control over specifics about how your app is setup.

What is a Heroku Buildpack?

Heroku buildpacks are scripts used to transform deployed code into a "slug", which is then deployed onto a Heroku dyno, or hosting virtual machine.

Heroku has official buildpack support for Ruby, Node.js, Clojure, Python, Java, Gradle, Grails 3.x, Scala, Play 2.x, PHP, and Go, and shown in the image below.

Offical Heroku Buildpack Languages

These buildpacks are open source and available for download on GitHub. Developers are invited to contribute to the official buildpacks via pull requests on GitHub.

Aside from these official buildpacks, third-party buildpacks are also available.

Nanobox Versions of Heroku Buildpacks

Nanobox's language engines work similar to Heroku buildpacks, the major difference being, as mentioned previously, that Nanobox engines are used to construct local development environments as well. The local development environments created on the Nanobox platform make it easy to deploy the apps to multiple servers, including dry-run, testing and staging servers prior to making them live in production.

Nanbox engines are also open source and available for download from GitHub.

For anyone wanting to create a custom language engine, Nanobox provides support for doing so.

Posted in Heroku, buildpacks