Editor's note: This is a cross post from Blake Gentry, an engineer at Heroku.

This is a post about the recently announced Heroku Platform API JSON Schema and how I used that schema to write an auto-generated Go client for the API.

Heroku's API team has spent a large part of the past year designing a new version of the platform API. While this is the 3rd incarnation of the API, neither of the two previous versions were publicly documented. In fact, the only documentation on the old APIs that was ever published is the source code of the Heroku Rubygem, which powers the Heroku Toolbelt. That worked fairly well at the time for Heroku's Ruby-centric audience, but it was never...


Today we’re making an important piece of Platform API tooling available: A machine-readable JSON schema that describes what resources are available via the API, what their URLs are, how they are represented and what operations they support. The schema opens up many interesting use cases, both for users and for us at Heroku working on improving and extending the API. A few examples are:

  • Auto-creating client libraries for your favorite programming language
  • Generating up-to-date reference docs
  • Writing automatic acceptance and integration tests

We are already using the schema to maintain the API reference documentation on Dev Center and to generate several v3 client libraries:


Currently in beta, the Heroku Platform API lets developers automate, extend and combine the Heroku platform with other services in a programmatic, self-service way. Today we are setting the capstone into the API by adding slug and release endpoints to the API beta.

These API endpoints are special. They expose a very core part of what Heroku does best: Quickly and safely releasing new versions of an app onto the Heroku platform.

Using the new slug and release endpoints, platform developers can build integrations and services that completely sidestep the traditional Heroku Git deployment flow. So instead of requiring git push heroku master to deploy, it’s now possible to do things like:

  • ...

Editor's note: This is a guest post from Rikki Endsley. Rikki Endsley is a technology journalist and the USENIX Association's community manager. In the past, she worked as the associate publisher of Linux Pro Magazine, ADMIN, and Ubuntu User, and as the managing editor of Sys Admin magazine. Find her online at rikkiendsley.com and @rikkiends on Twitter.

A code of conduct is a signal to attendees that conference organizers have carefully considered the issues involved with attending events, and that they want to make their conference welcoming and safe for everyone. Heroku recently adopted an event sponsorship policy that shows that the company recognizes the importance of formal...


Last week we released a new version of our node buildpack that features dependency caching, faster downloads of the node binary, and support for any recent version of node. This new build process is now the default for all node apps on Heroku, so keep deploying your apps as you normally would and you should start to notice the speed improvements.

Faster Deployments

The new buildpack makes use of a build cache to store the node_modules directory between builds. This caching can mean dramatically reduced build times, particularly in cases where your modules include binary dependencies like pg, bson, or ws.

We've also shaved time off the build process by caching precompiled node...


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