I don't think there's a huge market for what Heroku does in the PHP world. With Rails, you want to run it as a long-running process. The amount of time to spi

I don't think there's a huge market for what Heroku does in the PHP world. With Rails, you want to run it as a long-running process. The amount of time to spin up a (Thin|Mongrel|Unicorn|etc.) is too long to do it based on a user request for a page and it's why Rails isn't run as a CGI. PHP is a bit different. The language is typically embedded in the server and then the individual files are parsed and run. There's little configuration other than uploading the files since the server can just interpret the files ending in ".php". Heroku needs to be able to put your application code on multiple servers and know which servers are responsible for your application. When one of your Thins isn't working, they need to kill it and spawn a new one, potentially on a new server and make sure they update their routing table. It's a tad complicated. PHP Fog doesn't have to do much. Heroku is running around 65,000 applications. Assuming that applications are under 30MB (for the hard drive), a RAID-1 with 2TB drives on every server they have would do the trick with a simple load balancer sending requests to a random server would do the trick. Your code is resident on their 15 app servers, a request comes in and gets routed to a random one, it parses your PHP and returns a response. The application isn't in memory as a long-running process like it is with Rails. Heroku already just has shared or dedicated database servers. There's no fancy process monitoring that you need since you only have to ensure that Apache is still going strong. But that's also why PHP Fog won't do as well. They aren't taking on as difficult a challenge as Heroku. They don't need to run something like god or monit to monitor lots of user processes. They don't need to pre-spawn application servers. They don't need fancy routing to keep track of what domain is being requested, what application belongs to that domain, and on what server that application is located. Because PHP doesn't usually involve long-running processes, it's taken care of for them. In fact, there are services like this already such as Rackspace's Cloud Sites (which puts your PHP or ASP code on multiple boxes, has a shared database, and loadbalances it). The same situation exists with Media Temple's Grid Service. Media Temple says, "hundreds of servers for the price of one". That's possible because the application code takes up such little space and can be easily replicated since it doesn't store state. Rails and Django users on Media Temple have to buy a "container" which comes with a certain amount of RAM on a specific box - because they need to keep the application in memory. Rails deployment will get a lot more people on board because it's more difficult to do. You have to manage application processes. PHP deployment is already seen as something that "just works". And if someone is going to argue that this "just works" a little better, wait until different users are expecting different php.ini stuff - or they expect to be able to save to the local filesystem because that's what the code they downloaded does or do a highly insecure cross-domain require or all of the various things that can't "just work". They could still be a very good webhost, but they aren't solving the same problem as Heroku and others (including Media Temple and Rackspace) have already gone the multi-server, auto-load-balanced and managed failover route for PHP (just not using git).