Cloud Hosting for PHP: The Eternal Pipe Dream

Posted: 2012-10-03
Category: PHP

I posted an article at the start of the year called 2012: The year of PHP cloud hosting. Well, not really. Sure there are two months left in the year, maybe the problems will get fixed? Before I go onto explain the problems, what is all this fuss about PaaS anyway?

Server Provisioning

I would much rather be doing anything other than sysadmin. Sure it only takes a few minutes to fire up a VPS and run "sudo apt-get install lamp-server", and you don't need a neck-beard to configure some PHP extensions to use and enable mod_rewrite, but if you could do it all with one single file… why wouldn't you? On Pagoda Box you can do this:

    shared_writable_dirs: [/system/cms/cache, /system/cms/logs, /uploads, /assets/cache]

    php_version: 5.3.10
    php_extensions: [mysqli, curl, gd, mbstring, eaccelerator, memcached]

    php_date_timezone: Europe/London
    php_max_execution_time: 30
    php_max_input_time: 60
    php_post_max_size: 50M
    php_file_uploads: On
    php_upload_max_filesize: 20M
    php_max_file_uploads: 20

    name: 'site'

That means I know exactly what version of PHP it will use, and I can configure other extensions to be installed. You can do this using tools like Chef or Puppet, but the overhead of setting all of that up is massive. You need to set up Chef Server or set up a Chef Solo on a cron or hook and do all sorts of arsing around - which is absolutely fine if you're building a big project that needs it, but not for some little blog.

If you don't use Chef, Puppet or a PaaS built-in provisioning tool like the Boxfile then you run the risk of forgetting about certain extensions when you move the application - which is a ballache and probably results in errors on your live site being reported by users. How many of you really remember to install mbstring or gd first time around?


Getting your code from your computer to the live site is another thing a good PaaS will take care of. I love that for simple sites I can make a tweak then hit "git push production master" and forget about it. I can replicate that functionality using other tools, but again it's all about having it in one place.

For example: A large project I've been working on recently is using Chef Server for provisioning and EC2 to host the staging and production servers. We then deploy new builds with a custom script that will fire up a new server via the Chef's Knife tool and a EC2 plugin, deploy the code from GitHub to the server, permission everything, set up configuration, transfer the Elastic IP over to the new server once its done, then terminate the old server.

Sound complicated? Sure is, but it is exactly how Pagoda Box works in the background. You just do a "git push" and it will use your Boxfile to build you your server, create a new instance, deploy the code, switch the network to look at your new instance, then terminate the old instance.

The whole point of these systems is giving you the advantages of these manually put together very complex systems, without asking you to spend all the time setting it up. If you only work on one or two websites, then you might not need deployment or provisioning, and if you do you might not mind setting it up. But if you work on a f**kload of sites and want to be able to do the same sort of things, you need a decent PaaS to help you out.


What did you do before GitHub or the hosted Subversion repo systems like CodeBaseHQ and Unfuddle? Did you set up your own Subversion/Git repos on your own networks? Setting them all up sucked. Managing them when a bug came up was annoying. Adding new users was time intensive, and if you wanted to give somebody remote access you had to serve your repo up online.

GitHub did the same for code sharing that PaaS does for hosting. In a team of developers you can just enter "jerelunruh" and click "Add user" to the project and they can deploy changes to your server. Again, if you have a LOT of projects where you work with various different teams, developers and clients, this is an unbelievable blessing.

Horizontal and Vertical Scaling

If you're running a little $12 VPS because your site has not been getting much traffic, then suddenly your site get listed somewhere popular and you get a flood of traffic what happens? You're going down. Downtown!

Some PaaS systems allow auto-scaling. That sounds pretty nice right? You get a lot of traffic, so you get more machines. Other PaaS systems don't have an automatic solution, but PagodaBox will give you a very simple analytic board and show off when your servers are taking a hit. You can easily slide a bar up and increase your memory dramatically, or even throw more servers into it to have your site automatically load balanced. EPIC!

What else?

The fact that most PaaS handle minor details like one-click Redis server setup, easy use of Worker systems (no need to set up Gearman or RabbitMQ - which can be a bitch) is handy extra to this already awesome list of features.

I know I've been suggesting PaaS is great for basic sites and basic sites might not need Redis or workers you say, but as those sites grow or the CMS they're using releases "Redis Support", it's nice to be able to take care of that in one click and not arse around setting it up. That makes clients happy, and I'm happy because I don't have to do any sysadmin shit.

Pagoda Box sounds great then!

Pagoda Box is everything I want a PaaS product to be. It would be even better if it worked.

I have been using Pagoda Box since the early BETA's and it started off very shaky. That's ok though, thats what BETA is for - but a year or two later they're still horrendously unstable with no real signs of improvement. I feel horrible saying this because I the team are great people, but I can't sit around happily using a product that has caused two major issues in two days:

Randomly my company site disappeared. I have two apps running on the domain, the main site and my billing area (PancakeApp) running in a submodule folder. The entire main site was deleted, but the billing submodule was still there - only not responding to Apache. It was just a file system and anyone could click around looking at the files.

Somebody even sent me the URL to my PayPal IPN log which shows how much my clients have been paying me recently.


This would never normally happen with PancakeApp as Apache would read the .htaccess rules and never display that file, but because the .htaccess was ignored and this was being treated as a file system, anyone could read whatever they liked. Not cool.

I did the usual Twitter-check-before-bed and saw somebody reporting an error that has come up a few times before about sessions not being writable to "/tmp/pagoda/djsfhihep4o". I responded with an all-to0-familiar "That's a common Pagoda Box bug, it should be working again in a few minutes.". I wake up after 6 hours and my site is still down.

There have been other errors on other sites (I have about 20 hosted with Pagoda Box from client PyroCMS sites to the API backend for iPhone app Bus Live: London). Some of the times I've tweeted about "Pagoda Box Bugs" it's actually been my fault and the team have helped me out brilliantly, but a lot of the the problems have just been ridiculous; like when I took a backup of a large database and crashed the site... The other trouble here is that they are an American company with American support staff, so if I wake up and things are broken I have nobody to ask for help until my afternoon when the yanks are sipping their morning coffee.

I've been actively reporting bugs to Pagoda Box for the entire time I've used them and they've fixed most - but I've been paying through the nose to mine-sweep for them and I'm fed up with it.


I planned on having a fairly interesting morning of hiking up a nice little mountain near my hostel in Norway before getting on with the meat of my development work today. Instead I have gone through 6 well known PaaS systems and I can't use any of them.

PHPFog / AppFog

PHP Fog was the first on the scene that was usable well over a year ago. I used that since it was in early beta too and it was great for a while - until I tried to scale. The choices were "Gold, Silver or Bronze". I was on Bronze and my site just got nailed with traffic when some article hit #1 on HackerNews. Ironically I think it was "2012: The Year of Cloud Hosting", but it meant I needed to scale and quickly. When I selected Silver I saw a little message saying "Your cloud will be upgraded to Silver within 24 hours, please be patient". I was on Pagoda Box before waiting even one hour.

I can't blame PHPFog for this, as they were a start-up company building a minimal viable product. They then got given a whopping $9.8 million investment and pivoted to be generic PaaS, supporting Ruby, Node, Java, Python, etc as well as PHP. The features in AppFog are immense and it really looks like money has been spent on it, but it has its own problems.

Until two days ago App Fog didn't have root-domains. That means I could not have but I could have They fixed that, so awesome. But they have no writable folders.

Now I know people always say: "Yeah but you should be uploading your files to S3 so you don't need writable folders". Ok smart-ass, what about log files and caching? I can send my logs through RabbitMQ or store them in Mongo, and I can use Redis for my caching, but that's not exactly helpful for stock applications. PyroCMS can handle that thanks to some improvements made recently which will be available in a later version, but most systems will fall if it can't write anything anywhere at all. PHP Fog used to allow you to enter folder paths of folders that should be writable. Why doesn't AppFog?

Pagoda Box dealt with this by allowing "shared writable folders" which were not only writable by the server by they would be shared between all servers - so when you added more servers you'd keep all of your logs and they'd all use the same cache instead of hitting the DB once per server.

Beyond the problems with AppFog's feature-set the stability of its website and dashboard also worry me. Login attempts were taking about a minute and giving empty responses while the rest of their site loaded instantly. It took 6 attempts it log in to the site.

Creating new apps was giving a 500 error with their generic error page. After 7 attempts it let me create an application.

I'll come back to AppFog in the future. I still happily wear my PHPFog t-shirt and drink coffee from my AppFog mug, but for now I can't use them for any of the sites I look after. Next!


Orchestra is a very simple little PaaS founded by Eamon Leonard which was later acquired by EngineYard - who are very big in PaaS but mainly in the Ruby world.

I had a demo of Orchestra before it launched from Eamon himself and it looked really cool, but the feature-set is just not on the level with some of the competition. You can control where nginx will look for index.php and that is about it. No writable folders (especially not shared writable folders), no control over extensions, nothing. They suggested over twitter after my rants this morning that I use their Redis extension to send out all my logs and cache. That's fine if I am building an application specifically to use with Orchestra but deploying existing applications is pretty tough. One of their selling points is:

Build your app with a range of popular PHP frameworks

I don't know many frameworks that have Redis logging built in. I'm sure Symfony does, but that's not "a range" of popular frameworks. If I have to build my application specifically to work with the provider then the point of this simple hosting has been missed.

The other gripe I have with the system is that your deployment is done with a hook - overwhich you have no real-time feedback. When you push to your repo a hook will fire, then "at some point" the code is live, meaning its hard to tell if a change was successful. Other systems provide real-time feedback in the command line, or via the interface so you actually know if its deployed or not.


FortRabbit certainly looks interesting and has some very useful performance analytics on the dashboard. I'd suggest you guys take a look but it's still got a BETA tag on there and I'm not going through that again.


I was excited by the idea of AppliHQ as I am a big fan of aTech products and have used PointHQ and CodeBaseHQ a lot in the past. Sadly after scouring their site I couldn't find a signup button, and they eventually tweeted to let me know they were not accepting new sign-ups. Erf.


I looked into this and know a few people running PHP happily on Heroku, but it's a hack. If these companies cannot get things right after two years then I don't know how Heroku expect to get PHP right in the first year - especially if you have to hack in support by saying it's a "Facebook App". I've seen some articles that show how I can do this, but I don't need my hosting solution to be posted on There I Fixed It.

AWS Elastic Beanstalk

Elastic Beanstalk is essentially Pagoda Box but with WAY more flexibility, but that flexibility of course comes with a loss of simiplicity. It is also 5x the cost and really not meant for hosting a little blog. The process is essentially the same as the initial EC2 + Chef process I described above. It looses the advantages of "adding users" easily like this other GitHubescque systems do and of course it is in BETA itself.


I've moved this blog to a little EC2 instance, left some low-traffic client sites on Pagoda Box, I'll be moving to EC2/Chef deployments much like the first example and I'll be hoping that AppFog add shared writeable directories soon.

This comment section will doubtlessly be filled up with people linking up other PaaS solutions as there are a LOT (about 50) but most of them are developed by very small teams, not yet complete, still in beta or just too lame to even mention. The way I see it, if a company with $9.8 million in the bank hasn't quite got it right yet then I doubt a bootstrapped-in-the-garage product will.

Maybe Pagoda Box will fix itself; That would be ideal because they have absolutely nailed the features but their service just doesn't stay up. I've been assuming their problems will just stop for well over a year and it hasn't happened yet.

Finally to everyone suggesting I just use Linode/CheapVPS4U/whatever: I've spent the last 2 years driving a hover-car. I don't want to go back to driving a normal car, I just want another hover-car that doesn't keep crashing.




Great post Phill. I am just in great dilemma about moving my sites from VPS to paas service. Pagoda was my closest bet, but I will now re-conceeder if I will be moving at all...

Jake Statham


Not the cheapest option but we have been using Cloud Sites from Rackspace for multiple client sites for many years and it includes a lot of what you are looking for. Supports PHP (and .net I believe). It's been good for us, would recommend you check it out for other projects.



Interesting to hear about the PagodaBox problems. I thought they had the best service among the php paas providers when evalutating a year ago. But I wasn't able to use them since i needed to be on Amazon's platform and Pagoda runs on Softlayer.

Been using phpfog with amazon RDS for the last year. phpfog has had their share of issues but has been stable the last 2 months. RDS has been rock solid since day 1. currently trying to decide between Elastic Beanstalk vs Appfog as a phpfog replacement. phpfog doesn't support multiple domains per app which i now need.

Fortunately, a shared file system isn't important to me. Dotcloud however offers an option for that. they seem a little pricey though.



Honestly, if you just want to" thing about code" and runs your site on LAMP, why don't you get a simple shared hosting on a pro and renowned hosting company ?



Sounds like you need to check out ActiveState's Stackato (with both persistent file system support and a great big love for PHP) and break your addiction to Public PaaS providers. If you really want the PaaS functionality and ease of use, try spinning up a Stackato AMI on EC2 and you'll be pleasantly surprised at how easy it is to host your own Private PaaS



I completely agree: Pagodabox is the bomb diggity, but so far their service is pretty inconsistent.

I feel that they've taken a huge leap and have been trying to solve a lot of very complex problems that others no dare touch. The result is that they constantly run into problems. And that's annoying because there is so much to love about Pagodabox.

One little spark of hope is that they do seem to communicate openly about when shit hits the fan, when they've run into a problem that set them back a lot. Just now the released a new blog post detailing the stuff they're actually trying to battle, and they have done in the past, so you feel like at least you're in capable hands and there is the chance of improvements.

For now, it's hard to justify running anything production on Pagodabox.. balls

Spicer Matthews



"I've spent the last 2 years driving a hover-car. I don't want to go back to driving a normal car, I just want another hover-car that doesn't keep crashing."

Janos Pasztor


The problem with PHP in conjunction with the "cloud" concept is, that it really demands a full POSIX-compliant filesystem to work in most cases. Since it's the "cloud" it will be some sort of networking filesystem like NFS. Networking filesystems are incredibly easy to bring down with just a faulty application, that writes logs like crazy. With a classic webhosting you don't have that problem that often, because the only the users on that one host are affected, but in the "cloud" a little IO or say too many files in the same directory can kill the whole storage subsystem.

I tested Pagodabox when it was closed beta quite some time ago and I remember that they didn't do anything very wrong, it's just the "cloud" that kills them. To build a proper networking filesystem with a decent amount of IO capacity, you need a storage and those things cost a LOT of money if they are done right. I was the chief operator of one such system before the big "cloud" hype and remember having sleepless nights over the IO problem this despite or in fact sometimes because of our FC storage.

Sorry to break it to you, but if you want a reliable PHP solution, you gonna have to build it yourself. At least until some big hosting panel provider decides to move in with a well engineered, off the shelf solution.



Jake Statham: Rackspace Cloud Sites does nothing anywhere close to what I am looking for. It doesn't handle deployment, or auto-scaling, no ssh, no load balancing or vertical scaling, no ability to add extra extensions, or any of the stuff that other PaaS systems do. They only upgraded to PHP 5.3 about 2 months ago - their service is WAY behind the curve on pretty much everything - its just a place for people to FTP their basic sites.

Dianem: It's not an addiction, I just want PaaS providers to offer useful products and not break. I use EC2 for large projects as I mentioned in the article, so I don't want a "Enterprise Private Platform-as-a-Service". Simple Heroku-style hosting for simple projects, complicated server setups for complicated projects. Surely thats a fair expectation?

Alex: Please read the article again. You seem to have ignored... all of it.

Janos Pasztor: That's not really true at all. It being "cloud" doesn't mean anything, other than VM instances are running somewhere. Sure hitting an application that hits the file system too much would bring it down but thats true of any hosting. On my live sites it will only hit the file system for basic caching and log errors (not debugging or info) so there is barely an IO overhead happening on the average page load.

It's not performance that has ever been a problem, it's these companies pushing new features that just don't get enough testing. I could list all of the issues that Pagoda Box have had because 9/10 I was the one that reported it. They've always explained the issues.

Example: We had issues for months where would just return an "Empty Response". Not a 500 error, it would literally have NO status code - which I've never seen beter. This was because Pagoda Box was truncating HTTP Request headers to 1024 characters, while Apache will actually allow 4kb in a line.

That has nothing to do with file I/O, thats just somebody doing something wrong.

PHP PaaS is obviously possible and saying otherwise is just silly. These companies need to just get it right, keep it stable, test things before charging and employ decent support staff to quickly answer any problems that arise. Especially if they've got $9.8 million in investment. nudge nudge



Phil, the definition of insanity is repeating the same thing over and over and expecting different results. Expecting "Public" PaaS providers to offer useful products that don't break is a form of insanity. You're putting your faith in an unnecessary middleman. I use Stackato on EC2 to host a couple of my HTML5/CSS mobile apps' backends, and some simple python/django sample apps on one Extra Large instance - and I just pay Amazon as the use of a single instance of Stackato is free. It makes Stackato's UX makes it easy for me to deploy all kinds of applications. Once you give it a try, you'll never go back. And yes, I work for ActiveState, so take it with a grain of salt, Private PaaS is the way to go.

Frank Lämmer


@Phil: thanks for sharing your experiences and your opinion. And thanks, of course, for mentioning our service - fortrabbit. We have removed the BETA seal just yesterday.

We like Pagoda Box too. They understand the needs of PHP developers better than the others. We are monitoring different PaaS vendors with pingdom for a while and Pagoda Box has the highest uptime rate.

We totally agree to the comment by János above. True: It's expensive and I/O can be problem. But i think we figured it out. We believe that r/w storage (and along SSH/SFTP) is a need.

frank - fortrabbit designer

Jaap Rood


Looks like the hover car is getting jet engines.

With so many changes all at once (and the lack off for the last couple of months) you'd think stuff has been changed on lower levels. At least the Ping monitoring will give us more application based indicators of stuff hitting the fan



Dianem: I don't think it is insane to expect a service to fix their bugs, and it is certainly not insane to look for other options.

As for you saying that PaaS will never work: I call bullshit on that friend. Heroku is a public PaaS that has been running for years. It's had a few outages throughout the years, but it's not unstable by any means. It can work, and continues to do so. I would like its PHP brethren to do the same, with some of the top level features shown off by Pagoda Box.



Aldo is a classic shared hosting, webfaction give me the chance to sleep all night.

Great performance and a few minutes to respond a support request, 9 to 16 dls/m

I have a wordpress there one day a get 14k concurrent visits and the site was ok, near 15k DB went down. no chance to do some fast upgrade.

And an other instance i have an ExpressionEngine, and it works great with 200k visits



One things I've noticed with Pagodabox vs PHPFog is that the pushes from Git locally to Pagodabox seem to take a lot longer - up to a minute - on Pagodabox?



Nice article Phil. I checked out Pagodabox after reading your article about it months ago. Personally, I haven't had any major issues with downtime or anything else. The most common issue I had was deployments getting stuck, but they're releasing an update that takes care of that too. Its features blows everyone else out of the park. I'm excited with all the updates coming up (check out the latest roadmap update on their blog) which will definitely raise the bar higher.



I have spent the last week or so moving a WordPress MultiSite install to Pagoda Box. Now I'm no server or terminal Guru. I actually only started using SSH so that I can use Pagoda Box, so it's been quite a learning curve. But I love the idea of Pagoda Box, and I'm happy to invest some time in the hope of of a better workflow. And truth be told, I'm enjoying some basic bashing.

It's all been pretty smooth sailing. Their support documents are thorough. Which is luckily. Because their actual support --by way of returning support emails-- sucks. And considering how exceptional their platform appears to be, it's quite the shock. I just expected them to be all over support as well.

They've spent so much time to build such an awesome platfom, but offer nearly no support to back it up. I sent emails to support 5 days ago which still have not been replied to. Yep ..... FIVE days.

They have 2 Twitter accounts: one being dedicated Twitter Support (@PagodaSupport) which has not replied to a single of my Tweets. Whey even have it then Pagoda Box? It just pisses people off that it's there and doesn't actually support anyone.

Now in Pagoda Box's defence, I'm not one to whinge about free anything. So I hasten to complain about their non-existant support considering the non-existant revenue I've so far paid them. But I do plan on using their premium features, and they do offer the free accounts. But so far I can't even get the actual App functioning properly, so I can't even upgrade anyway.

Also I know they are in the middle of rolling out some major new systems. But fuck, you can't ignore the people who are using your system just because you're making the system better.

Had I read this blog post before investing the week in Pagoda Box, I might have thought twice. Phil clearly knows a shitload more about all-things-server than me, and he's bailing on Pagoda. That worries me.

I still love the idea of Pagoda Box, and I want to use them. Their dashboard is seriously kickass, their performance seems impressive (the minimal pageloading that I've tested), and the whole setup seems so modern. But their support has been prehistoric bordering-extinct.

Getting real time chat Pagoda (IRC does not count) and answering support emails would be a good start.



Hi Phil,

Nice article. I went through all the same stuff recently and concluded the same thing, none of the PaaS providers are production ready and EC2 is the way to go. I was quite sad about that conclusion. I started to put together a a spec for an "infrastructure builder" for PHP which would allow me to configure a YAML file with every AWS feature I want preconfigured in the same way as a Boxfile. I was planning to use Puppet within it but I needed to learn Puppet and just lost the momentum. I hope someone else does it.



I have been impressed with AppFog the most in terms of reliability, support and app / site speed when viewing stuff on their AWS based servers in IRE from the UK / Europe. I am planning on moving something that needs to be highly reliable over at the moment so will report back if my opinion changes!



I am dedicated server man myself. Yes, the alure of autotmatic scaling is a powerful one. But I figure by the time I need to scale out a presentation tier, or database tier, of my infrastructure, I've already made hit product, and won't be bogged down with doing much else but supporting it.



and now... PHPFog is unceremoniously dropped. gone.



Anyone has any experiences with fortrabbit ?



What about Redhat Openshift ?

Posting comments after three months has been disabled.