I wonder if it's because modern PHP apps (such as Symfony) have some external dependencies (such as on the APC cache).
Happy to see that there is "unofficial" support for it at the moment. Competition is a good thing!
Really Heroku? Any web framework? I guess PHP and ASP.NET aren't web frameworks any longer.
Also, PHP is not a web framework, it's a language.
I've only poked around Heroku a bit with basic applications and the standard stacks (Python w/ Flask, etc.), but I think I'll look into what would be required to create a buildpack for Racket.
That is, if someone hasn't already beaten me to it...
EDIT: As figures, it already exists[1]; I'll toy around with it and test it out before suggesting they add it to the list.
OpenShift is also interesting. And if you need something to hack on, see
https://github.com/RayRacine/rackos
Understand that Heroku and App Engine are fundamentally different kinds of things.
The commonality is that they are both selling some kind of service to run code on, and they are both (in different ways) trying to make it easier than just administering everything at the low level of a VPS or dedicated server, while also giving you similar levels of isolation and capacity as you get outside the shared hosting world.
But other than that, they are aimed at quite different goals and the architectures (necessarily) vary accordingly.
App Engine imposes heavy constraints on your app architecture with a primary goal of making scaling easier from the outset. You are very much doing everything inside a framework provided by Google. They are trying to make sure your handlers do not run too long or do certain classes of insecure things. And the infrastructure of production is very much opaque to you. You can't just run any old combination of services, they provide you a set of very good and very transparent but proprietary APIs for things like memcache and datastore. You just use them and get billed by usage. While they offer multiple runtimes and some multi-runtime tricks are possible, they really aren't trying to cover the 'polyglot' use case or support every language under the sun. It has good technical merits but your app is almost completely married to Google. Running a low-traffic app is free but scaling can be a little costly compared to approaches where you are doing more yourself.
Heroku is not a platform in the same sense as App Engine. That could be good or bad depending on what you need. It provides high-level interfaces to reduce most users' deploy and management overhead. But like a VPS, it isn't trying to limit your flexibility or determine your architecture. It explicitly gives you control over your mix of services and your own languages and use different things together. However, in the course of simplifying it also does constrain and hide details. It just isn't a fundamentally different environment from normal Linux VPS, as App Engine is - it's only one which you manage at a higher level using Heroku's tools. You are left with less lockin than App Engine, but you are still dependent on Heroku insofar as it is supplying all your deploy/management scripting and stuff like that.
App Engine says something like "do it our way with our tools and you will be able to scale easily on high grade infrastructure" and Heroku says something more like "do what you could do on a VPS in a slightly different way, with slightly less choice of tools, and we can make it much easier. We can help you cross the scaling bridge later." So they are designed to meet different kinds of needs and have attracted somewhat different kinds of audiences.
When the app is created it sets NODE_PATH=lib so the app can find those files without specifying the full path: https://github.com/heroku/vulcan/blob/master/lib/vulcan/cli....
What happens in an environment where you have multiple applications with different but overlapping dependencies?
automated scripts like Chef / Puppet are designed to keep a system in a predictable state according to some code+data specification. It's not a guarantee though as things not specified by the scripts can have any state. They're more useful to maintain an heterogenous park of machines, systems that want to keep state on the disk like databases or even configure the underlying system that will run the buildpack containers.
that's how i see it but notice that there are some similarities. it could be possible to use chef to pre-configure a system image as a "buildpack", or to add some disk storage to buildpacks. although both not on heroku obviously.
If my information is correct Heroku is using Linux containers to keep everything nice and sperate.