I take the opportunity to say: thank you Heroku for being so open. You saved me 100's of hours of work when setting up my own private PaaS as I was able to piggy back on your buildpack idea and code.

Cf: http://news.ycombinator.com/item?id=3521959

Excellent! (Maintainer of the Python buildpack here).

I've been looking closely at your PaaS, actually. I love the general approach. Drop me a line sometime if you'd like to collaborate on Python-specific stuff: kenneth@heroku.com

:)

How does this differentiate from Dotcloud's custom services? For example:

NodeJS service: https://github.com/dotcloud/node-on-dotcloud Ruby service: https://github.com/dotcloud/ruby-on-dotcloud ZNC service: https://github.com/dotcloud/znc-on-dotcloud Jenkins: https://github.com/dotcloud/jenkins-on-dotcloud Gitosis: https://github.com/dotcloud/gitosis-on-dotcloud Tilestream: https://github.com/tilestream-on-dotcloud Geodjango: https://github.com/dotcloud/geodjango-on-dotcloud Memcache: https://github.com/dotcloud/memcached-on-dotcloud Django+MongoDB: https://github.com/dotcloud/django-and-mongodb-on-dotcloud SOLR: https://github.com/dotcloud/sold-on-dotcloud Pyramid: https://github.com/dotcloud/pyramid-on-dotcloud -on-dotcloud

And if they are functionally similar, as I think they are, would it be interesting to make them compatible?

I was actually looking at buildpacks a few weeks ago. I found a github repo that was using a custom buildpack, but there was no documentation at all about it then.

I wanted to create a buildpack to build a jekyll website and deploy, that should be a cinch to do with these custom buildpacks. No longer would I have to build the jekyll app locally (takes long time), I can just push and heroku builds it.

Someone explain this to me. What do buildpacks allow me to do?

It looks like a buildpack describes how to detect and compile apps for a given language / framework. So you can use a custom buildpack if you want to use a framework that Heroku doesn’t support by default.

Or, for example, for the node.js build pack to use a more up-to-date node version

More tightly couple your code to Heroku.

The mono build pack from Ben Hall (https://github.com/BenHall/heroku-buildpack-mono) looks interesting.

With AppHarbor's pricing announcements yesterday (which sucked) I've finally got around to looking at Mono and Heroku. It looks a good combination, although still referred to as unsupported/unstable. I plan to deploy a few test apps to Heroku using the mono build pack and NancyFX.

Thanks for linking to this. The only reason it's unsupported is because I don't work for Heroku so no idea what will happen in the future. I'll do my best to help :-)

There has been a number of successful deployments and it appears to work as expected. It would be great to hear your experiences. My twitter is @ben_hall

I'm curious about what environment the buildpacks are run on. I see there is some uname=Darwin support so I guess it's pretty portable. Just POSIX / GNU userland and tarballs?

In other words, does Heroku separate its build machines and server machines? do they all have the same OS image?

They run on the same dyno environment as the web apps (Ubuntu 10.4). Basically Vulcan is a node.js app deployed onto a dyno which takes source code, starts the build command and then return you the file.

The C build pack is awesome. I wonder what the raw performance (CPU and I/O) of Heroku dynos is.

You can find out with dyno-blitzer: https://github.com/pcapr/dyno-blitzer

What would one use this for? I don't know of many C-based web frameworks.

I could see it being useful to deploy a Thrift/Protobuf/Avro service. Not everything is a web server :)

I'm slow. I hope they write more documentation on this. Is a Heroku runtime environment just Linux? Will anything that builds and runs on Linux runnable on Heroku?

How easy would it be to replicate the Heroku deployment environment on your own dedicated server?

Is this sort of like a proprietary Chef or Puppet, or like a Linode StackScript or something?