When building a web app we all really just want to focus on writing code and making it work. But some of us are total control freaks and choose to torture ourselves with server admin issues on top of that. What's the reasoning behind your setup?
VPS/dedicated with third party email hosting
757 points
Heroku, Google App Engine, PHPFog, other SaaS
335 points
VPS/dedicated all the way including hosting my own email
237 points
I run my own sever (at home, office, wherever but it's totally yours alone)
Vote: VPS/dedicated with third party email hosting
Reasoning: SaaS is extremely tempting. If programming is only a hobby for you I recommend it wholeheartedly. But if you're serious about your app or business, learning or hiring someone for sysops/devops is really the way to go. It's cheaper, you aren't dependent on anyone, reducing your points of failure, and you learn extremely valuable skills related to server setup and maintenance.
In my (soon to be open-sourced) deployment solution that's built on Fabric and Chef, all I need is a configuration yaml file to describe my servers. I provide IP addresses, what role(s) each one serves (app, db, static, queue, etc), what kind of software for its service I want to use (db servers should all use postgres, for example), what OS to expect on each one, and what stage of deployment that server happens to be for this project (development, staging, production). Everything is completely shared-none and non-destructive, so if I happened to have 3 VPSs, each hosting some combination of several sites' app, db, and static resources, across a different OS on each, I don't do any additional work. All I type is "make deploy" after quickly writing some lines in that config file and I can sit back and relax. Servers get setup from scratch if they're new, secured, and have services like logging all ready to go.
In essence, I get the dead simple deploy of a SaaS, with the flexibility of using whatever hosting provider I feel like, using the exact stack and details I want, for the cheapest price I can find. If my Ubuntu-running Amazon data centers flooded tomorrow, I could be deploying on brand-new RHEL Linode servers with 30 seconds of yaml changes. That kind of peace of mind can't really be bought from a SaaS provider.
Interesting. Are there or were there any key articles or other resources (github projects) that helped you determine your setup? How did you learn this? Should people follow https://github.com/Pewpewarrows ?
Way too many actually. I basically scraped every single Fabric/Chef/Django-related boilerplate and skeleton project on GitHub to see what other devs were doing, and learn from their mistakes and successes. I follow Disqus' dev blogs thoroughly, as I consider them the current de-facto leader in terms of scaling and deploying giant Python applications.
And yes, it'll be up on my GitHub account when it's finished, and will (hopefully) hit the frontpage of HN when it's announced.
I'll be announcing it all over HN when it's done (likely February/March), but yes I'll also broadcast it on my twitter feed (same username as here on HN: pewpewarrows). The GitHub account that one of the other replies to my comment linked will have the project on it as well.
I wonder. Between Fabric and Chef, what do you feel you need to add to the mix? Provisioning of machines perhaps?
Personally, we're using Puppet for server admin and some cobbled together shell scripts, for app deployment. The latter is heavily inspired by Capistrano. We have a few shell scripts for generating new manifests in Puppet. All together a not-fully-automated, but quite close solution.
Sounds very interesting. I was planning working on a similar setup. Taking and improving on the many chef cookbooks and building around that. But due to lake of resources it may not be possible.
Here's my current thinking: I use Heroku to start out. If the app takes off and needs to scale, I can use Heroku until I get in place a cheaper/more custom config to support my specific needs - including pulling in the external services I'm using to dedicated servers.
If my app never takes off, then I don't need to do this work.
I find that it's always a good idea to know what you'd do a few steps down the scalability line (100 users, 10,000 users, 100,000 users) but not necessarily build for the biggest case. When bootstrapping, you can't afford the server costs for the big cases anyway.
We've used the exact same reasoning with our app Denso. The costs will definitely not make sense if/when we hit scale, but in my mind that's a good problem to have. The advantage with Heroku over services such as GAE is that no component of our stack is proprietary (as opposed to the BigTable data store available on GAE) and hence, moving hosting providers is slightly more straightforward.
The Heroku Add-ons marketplace is also a huge competitive advantage that they provide over other services. There are plenty of examples where we've relied on third-party addons to begin with (for e.g. Embedly) but once the costs of using such third-party services increased (due to increased traffic), we switched over to our own hand-made solutions and we were able to bring down costs substantially.
While I definitely agree here, this reasoning makes me wonder a little at the longterm profitability of platforms like Heroku.
Tons of freeloaders (like me) using their resources for our off-the-cuff apps, plus some people using it to bootstrap. As the usage climbs, and theoretically your revenues are also climbing, you get to a point where it makes sense to move away to your own setup.
How can Heroku make money if all customers eventually plan to leave?
Not everyone migrates out because it's not trivial to do well. Once out of the free tier their offerings are quite expensive for comparable(well performance wise) service elsewhere.
Dude, I wished I did like you. I spend so much time configuring the damn thing and it is still not quite there. I did get great deal on the server which is why I did what I did, but seriously don't think this was a smart move.
I always figured why not pay someone else to deal with these problems? Not that I end up paying Heroku very much at our current scale.
Sure there might be an in-between period where we are doing a large amount of traffic on Heroku + paying too much for it, but by then we will be able to afford to hire someone who can set us up properly + at the right price. Either way, I avoid wasting time configuring servers!
This is the best way to go these days, hands down. I can't imagine working any other way now that stuff like Heroku exists and can be used essentially for free during development.
I don't know yet. This flexibility is one thing that Heroku gives me, and I'm happy to pay for (once my product is live)
It may be that my product never needs enough resources to push me over the edge for moving to my own servers.
I've shipped products before where we pre-built a large cluster of servers (20+) and then used less than half that capacity, and that sucks cash really fast.
You may win the award for most rational reasoning so far. I should do that. Maybe it would be fun for everyone. I'm really glad I asked this after reading your answer. I could totally get rid of one of my VPSes and replace it with Heroku until or if, like you say, it takes off
"Reasoning" is being a little generous: I happened to develop a setup which is a duct-taped mishmash of VPSes and external services, and every few months I pay for it with a phone call at 3 AM in the morning (local time) that says something has broken.
These days I'm attempting to move things off of my VPSes where there are good, stable options which don't require huge engineering efforts to use. SendGrid for email was an early, obvious choice. I'll be migrating many of my blogs to WPEngine fairly soon. (I'll write up my rationale for that at length after it happens. They're a client, so take my arguments with a grain of salt, but it became painfully obvious when working with them that it was the right call.)
If I got a do-over on my two main software products I would probably re-write them to use Heroku over self-hosting them on my VPS. It would have avoided ~6 minor service disruptions and ~2 catastrophes in the last year, plus saved me about two weeks of lost billable time. (Mostly lost due to having a very involved migration from Slicehost to Rackspace which went fairly poorly, principally due to failing to invest another few weeks preparing thoroughly for it.)
I can't justify a rewrite of BCC or AR at the moment to migrate to Heroku, though, as they're both multiple weeks of work with high probability of breaking something, and my anticipated costs due to I'm Not Always A Sysadmin But When I Am I Only Fail On The Hard Stuff this year don't quite justify it. (Please, please, nobody buy Rackspace to shut it down. One migration was enough.)
Don't forget that Heroku/AWS aren't immune to outages themselves. Their major outage last year (due to an AWS/EBS issue) put my app out of commission for ~16 hours (fortunately it was still in a small, private beta).
I've got 6 VPSes and 12 dedicated boxes and have never had an outage that long (self-inflicted or otherwise) in roughly 6 years. Granted, most of my dedicated boxes are managed by Rackspace and cost > $1k/month.
All that to say, I agree with your sentiments for the most part ... I just haven't seen the "prevention" of catastrophic events per say.
The company I work for experienced a two hour outage several days ago, with a Rackspace hosted stack. It was a hardware failure of some sort, most likely a disk in our DB server.
Nothing is really 100% fail-proof, and each "9" that you want costs an order of magnitude more than the last. I've been happy with Heroku overall, even though their major outage affected me pretty badly last year. They have learned from it, and don't expect they'll get caught by the same thing again. And they are much better at managing servers than I am.
("Dammit, Jim, I'm a coder not a sysop!")
Heroku, GAE and other SaSS are great, if and only if they have everything you need. For my own purposes, most of the things that I do now involves PostGIS which mean I have to use a PostgreSQL server. The cheapest option for PostgreSQL on Heroku starts at $200. That's just way out of my budget for now. I'd love to know how people do GeoSpatial searches and other GIS stuff using MySQL or other NoSQL solutions.
Couldn't you migrate BCC to EC2 and then migrate pieces of it into Elastic Beanstalk (or AppEngine, or Heroku) as you wrap thin service layers around each piece?
I run anyhub.net which runs on two Intel Atom based dedicated servers. I serve about 50 TB of data per month and it costs me exactly $110 each month which I easily make back from Adsense.
The same would cost me tens of thousands on Amazon or other 'cloud' services.
How would you rate their network? I have a few sites that need bulk content serving stuff with minimal code, and these prices can't be beat for 100mbps uplink..
It's brilliant, one of my servers does about 90mbps around the clock.
They advertise a 6TB transfer limit, but I've been with them for almost 2 years now and they don't seem to enforce it.
I'd totally recommend them to anybody.
Also, if you're looking to save cash, an Atom CPU is surprisingly capable. At any given point in time both of my servers would have about 700 active HTTP connections each.
I am surprised nobody so far has mentioned AWS as a hosting provider. You can start with their free micro instance plan for one year (http://aws.amazon.com/free) and resize the server as needed. Having the ability to take a snapshot of the full server (you need to use EBS) and clone it to test changes before going into production or just for backup purposes gives me a peace of mind that I never had with dedicated servers (even if they had RAID). Plus you can get a myriad of services around EC2, like managed MySQL (RDS) that you cannot get from traditional VPS hosting providers. (Disclaimer, I created http://bitnami.org/ and we work a lot with Amazon)
I use rackspace and its very cool. Rackspace is fast and simple, and is also cheap. Their server runs fast, and smoothly. AWS is sometimes too complicated, lots of config, lots of choices, lots of weird price changes -- I am talk about the recent spot instances weird pricing fluctuations, and other wierd episodes they have had. Unless you know exactly what you are doing scaling in AWS will take more time and effort -- Unless you are Zynga, and you need a stupid amount of server which almost noone of the server providers except amazon have, or you dont want to deal with relational db scaling problems, or other of the expensive and specific service that amazon offers I dont see why complicate things in the "building stage". AWS is too complex for my use cases, and my software is usually transparent to the server where he is running, so I can always port my code. Rackspace API is stable and it talks JSON, which is cool because my frontend and backend talks javascript.
I guess this question is too open... the answer will always be, depends on what you are building..., and you amount of experience on the field... In my case several 8gb rackspace servers with a cost of 10 dollars a day seems to work well for collecting and crunching gigabytes of data.
Provisioning is not that hard, nor scaling -- you can always create a image and create servers from that image. In my case, I usually create a server that listens to git and the rest is synced by some program who is also listening the folder where the git repo is.
Heroku looks cool, but I am used to compile things...
I run my own server for over 6 years at an IDC in San Diego. The hosting is managed by http://m5hosting.com/ and I think they are fantastic.
Would I do it again given the abundance of VPS options today? Possibly. There are only two reasons not to run my own hardware: 1 - dangers of hardware failure on my single server and scrambling to build a new one as opposed to spinning up a new VPS. 2 - scaling. But after 6 years, neither of these have been a problem. In fact, I bet if the hardware failure does occur, I can have m5hosting provide me with a replacement server in a few hours and I could have it config'd and back up in around a day.
I certainly pay less by running my own, with hardware cost amortized over such a long period. I feel the admin hassles are about the same as running a single VPS and less than running multiple VPSs. I set it up, have good docs on the config, automated cloud backups (tarsnap) and would have no problem reinstalling from scratch.
Oh, and of course, I don't run my own mail sever. I'm not a masochist ;).
My team and I run on App Engine for our startup's product, but I run all of my own stuff (email, websites/blogs, legacy projects) with Mike. It's a trust thing.
Why not run your own mail server? Outbound deliverability is a pain. You can't just install an SMTP server package and go -- you need to think about DomainKeys, SPF, DKIM, Sender-ID, monitoring realtime blacklists for your IP, etc. That's a whole job unto itself and is worth paying a couple bucks for someone else to do it.
There is an option for SLA with a paid Google Apps account. Last I checked it was $50/year, but comes with much larger inbox (25G at Google vs. 10G max at Rackspace). Also better integration and push notifications on mobile for Google, if you care about that.
I do a lot of app engine at work. I'm aware of most of the sharp corners the platform has, but overall, I think it's a great offering for a wide-variety of applications.
So, when it comes time to host a side project, App Engine is my go to platform these days. There are a few times when I prefer going with EC2, but I like how easy it is to get a project started on app engine, especially when I'm confident that the application will scale should I need it to.
In my experience, hosting your own email is just a huge time sink. It's probably the most difficult service to get up and running and maintain over time. If you take your hourly rate and consider how much time you waste on email, it seems a better investment to pay someone else to do it.
I currently run a couple of VPS', but I'd love to switch to an app host like appfog or cloudfoundry if one hits the right balance of price, performance, reliability and functionality.
Unfortunately that balance problem has existed for years and we seem no closer to a solution that works for everyone.
At TitanFile we run our own server for all application-related stuff, and use a third party for email hosting. Reasons:
1) We need to comply with Canadian privacy laws, so need Canadian VPS - and those are way more expensive than in US.
2) To be PCI compliant, you need access to server logs. You can get that with Rackspace but pay a premium.
3) I've managed an in-house data centre before on my own, so I know what I'm doing for the most part.
If you factor all of the above, it's actually cheaper to manage your own servers, even if you outsource the sysadmin stuff to a competent contractor at about $100/h. The catch is there is an overhead initially to provide redundancy that diminishes only when you can utilize that extra capacity.
Thanks for the links Daniel. Very helpful! BTW, we're in headquartered in Nova Scotia, and as per your link, we have stricter privacy laws than the rest of Canada. It even goes as far as provincial departments not cooperating with other provinces because their privacy laws are incompatible.
Additionally, at least in Canada, privacy-cautious organizations don't look too favorably on services that store data in US, in part due to the patriot act. We even have US clients who liked the fact their data would be stored in Canada ;O)
We host our servers with IAI (http://www.internetworking-atlantic.com/) and run our own private cloud using proxmox and OpenVZ. The VMs are CentOS 6 and the host drives are all encrypted.
We use google apps for email, but it's all routed through a server of ours to have a backup and to be able to immediately migrate away should we have to: all mail that's sent to our domain and which is sent by us is not only in gmail but also in maildirs ready to be served over IMAP by changing one config file entry.
All application mail is also sent over that server (a Ubuntu VM hosted on physical hardware we own). All installations of our product are hosted on VMs on more physical machines we own.
Hence I voted the top option, even though we are also using Google for convenience.
I'm running a mix of small VPS and dedicated servers (most of them below 20€/month), including for receiving emails. Once you've spent some time tinkering with them, taming the OS, and stuff, it's much more flexible than any SaaS. And probably way cheaper, too.
I use 3rd party services for sending mails, though. The amount of boring work to get out of my recipients' spam folder is just too high without that.
I still use Heroku for a few low-traffic sites where I'm not doing anything fancy (like my personal website), but once I got into managing servers with Puppet it was VPS all the way.
I use a Linode for VPS/web hosting, Google Apps for email and AWS for S3 storage where I need it.
The combination is great. But if it wasn't for the Linode community and great support I would consider switching to an EC2 instance - I imagine an EC2 would be quicker to communicate with S3 than my Linode, though I haven't looked at Amazon's datacenter location options.
I would love to use Heroku/PaaS the one thing holding me back is my service needs a proper file system with a highly customised server for the compilation of LaTeX documents (https://www.sharelatex.com). I would also prefer to use an Linode server but because I rely heavily on s3 and the aws based MongoLab I am using an ec2 for the moment.
If the service gets bigger I am planning on leaving the LaTeX compiling on the ec2 and moving everything else into Heroku, but thats a big if.
One thing I would say to other small timers like me who can't use a PaaS for some reason, automate your deploys as much as possible, capistrano is a good start https://github.com/capistrano/capistrano/wiki . Also look through the list of Heroku addons for other services to make life easier, I use MongoLab and Loggly for starters.
We may be "total control freaks " but since our application stores Protected Health Information (http://en.wikipedia.org/wiki/Protected_health_information , except our requirements are even more strict), given our budget constraints and very good talent availability we're rolling our own, starting with buying the motherboard, CPU and 1U enclosures on up. Using the Xen XCP system as a good "just works" distribution of Xen, not as it was intended (a pool of multiple interchangeable hosts). Aren't messing with incoming email and stuff like that, companies that specialize in that sort of stuff are OK and decrease our attack surface.
It really depends on the project and your own context (or your customer's).
For some projects (eg: https://www.wisecashhq.com) I go DotCloud or Heroku, because I'm willing to pay in favor of focusing on features.
For some other projects (eg: http://www.hackerbooks.com) I use a VPS and Chef, because it's a low recurring cost and it's a smaller deal if the server is offline for a while.
Even if I go app hosting but the project works well, I take care to think about what it would need to redeploy it on a VPS instead (eg: create a staging server with Chef and a VPS).
One thing I will not host in all cases is email, because I feel it's really easy to do it wrong.
Linode, Ubuntu, Nginx, Varnish, Google Apps for mail.
Did the custom mail server with Postfix on Gentoo for a few years. Had the experience. Loved it. Came to realize I should be doing things with tools instead of managing tools, hence current config.
I run a datacenter, so yeah, we do it all in house.
The main problems for me are - security, reliability, network.
Using a VM/VPS type system basically eliminates any security you might have, there are currently too many ways to have your data stolen/intercepted/manipulated/disconnected for it to be safe. Using a "hosting environment" aka PAAS is actually one of the best ways to maintain availability, however your security is even more compromised.
If I were to pick a VPS/etc environment I'd go for Rackspace because they've got a better backstory than Amazon does, and they seem to be a bit more interested in protecting their customers.
I did a php app for a client on Media Temple's (gs) and it was unbearably slow. The php execution time would vary drastically (.1 seconds to over a minute) even on a simple debugging page. After a lot of back and forth with customer service and never being able to pinpoint the issue, I switch to Linode.
I wonder if this is a general Media Temple thing. I have a few small sites using Drupal on MT and the response times vary widely. I thought it was because of Drupal itself (I never use it; client decision) but maybe it's just MT, which I've found to be basically horrible overall.
Sorry to hear about your bad experience so far. This would usually be the case due to different configurations between the sites, but if they are all the same uniform configuration we'd be happy to take a look for you. Please let me know if you have a support request open already. Finally, what in particular have you found horrible, and what would you like to see us fix the most?
I've noticed the same. Did a lot of agency work last year where the agency boss got every client on MT to get the affiliate perks and was getting constant grief over slow sites, slow scripts and whatnot. I stuck copies of everything onto an old Dreamhost account I had and it flew.
In my experiences over 6-7 mo, MT had these speed issues roughly 50% of the time.
I thought about having a shared host option but honestly, shared hosting is kind of a joke if you're running any sort of custom app. It can be reasonably assumed that most shared hosting is used for static sites and PHP blogs.
I'll also add that I keep a MediaTemple gs account in addition to my VPSes for various static sites. You can actually use it to host your DNS and email then have your site resolve to the ip of another server. Obviously that's a really expensive option for basic email but if you've got the account for some other reason like me then you've got 100 domains you can add for free so it's an option in rare cases. Anyway, I'm in the middle of building a PHP app for a client on their MediaTemple gs account and I'll testify to the fact that performance varies wildly. I haven't seem anything take over a minute to execute but I've seen it go from .1 to as high as 50-something seconds. I've found you can fix most of the long queries by writing more efficient code. You'll still get some wild variations but not as often.
I'm currently bootstrapping an on-the-side startup which will hopefully provide a nice middle ground between fully-managed hosting and self-managed hosting. We'd provide you a platform for monitoring, backups and configuration management for a set monthly fee. You'd provide the hosting underneath, or we could provide for you.
Either way, should work out significantly cheaper than fully-managed hosting, with more flexibility for you while allowing you to spend your time on your business rather than managing your servers.
Co-located all the way. You have capital expense, but you have hardware perfectly tuned to your application. Yes, it's a distraction from coding, but those at times are very helpful.
VPS is good because I don't want to deal with the hardware, I just want it to work, BUT I want full control of the software I run, within reason. My definition of within reason is I like to run experimental servers on my VPS and see how they perform. Not within reason is trying to run my own mail server. I did that once in high school, just to see if I could. It was a painful experience and I'll never do it again.
We run our own server because we like to be able to set up testing / staging / all kinds of development.
However, our core platform is actually supposed to be able to run anywhere, so once it's finished, we may very well run it on a cloud setup.
More than that, though, we plan to open source it and make it distributable. Do you think we should put something on Kickstarter? If so, any advice on how to get as much buzz as Diaspora* did?
This is a bad poll because there isn't even distribution here. By definition there are more small companies then large ones which by definition will use month-to-month dynamic hosting options.
Most every startup will start in the cloud and some will move to dedicated machines later when it makes economic sense and if the team deems the additional headaches worth it.
And yet the poll does not bear that out. The real cost of starting in "the cloud" is often very high -- 3x the cost of a VPS or more -- and you can handle an awful lot of traffic on a 512MB VPS.
I actually found the comments informative to gain better insight as to why people use different setups. I had assumed that same as what you said, which turned out to be less often true than I thought.
I wanted to know what real developers were using. Obviously big companies are using their own hardware but I'm interested specifically on the usage of developers similar to me. I expected more votes for SaaS than VPS/dedicated to be honest.
got a dedicated box, but use AWS for some things (S3 and SimpleDB mostly). Also, i have used both PHPFog and AppHarbor for hosting of smaller projects, mainly for their ease of Git Push deploy. Mail is hosted my Office365... I did, how ever, run all these in house before, but bandwidth on a home cable connection was never enough...
I've used rackspace hosted email before, both the regular and the exchange versions. It works nicely and the users were very happy. It gets expensive though if you want push notifications on the blackberry, even without the exchange.
Google Apps has the advantage that it comes with docs and gmail - not just a standard email :O)
I've been on Fastmail for at least the last 7 years and find it to be an extremely reliable service. I've probably used them as the MX for over 20 domains.
I am migrating away from them however, because I've decided to consolidate all my hosting with a single provider (Linode). I can wholeheartedly recommend them though.
our app is actually hosted on a mixture of phpfog and Amazon AWS. if you find a paas that runs on amazon like heroku or phpfog, then you can actually use any other amazon aws product like RDS w/o any latency by setting it up in the same region as the paas web server(s).
I've started a "Ask HN" to help get more info on how people are doing their email delivery as it's one of the areas that isn't answered well in the responses below:
I've been running my services on my own hardware colocated out of Chicago for coming on 8 years or so.
I'm in the process of transitioning some of my stuff to S3 for durability, and will likely eventually transition to VPS-based hosting over the next year or two.
Both: Google App Engine when availability is important. When privacy / data security is important I'll use dedicated server. This is funny but interesting solution: http://cloudroulette.me/
I use a VPS for the site, S3 due to scalability and Postmark App for all transactional based emails. It means all the little things are managed by the people who know best, allowing me to focus on what I'm good at.
I'm currently deploying to Heroku during development and will switch to a VPS again as soon as the Heroku free plan isn't sufficient anymore or I go into production.
I don't use dedicated servers. Too much work for too little reward.
My choices for the german readers here:
https://www.jiffybox.de/ - cheap scalable(!) VPS, nice UI, easy cloning of existing "boxes", backups, etc.
It doesn't have to. You can rent a physical server from one of the many companies out there.
You get a few IP addresses (I've got a /29 on both of my servers) and a fresh install of whatever distro you choose with sshd running. It's just like purchasing a VPS.
I'll start. I've been running 2 VPSes. One for an app that's special to me (as in I hope to make some money on it) and a second one I use to host multiple sites and apps on. I chose to host my own email on the special one even though it's a huge pain because I feel like I need absolute control over everything. I'm pretty obsessively controlling over that server. I've even totally wiped it about 3 times because I want to be sure everything is exactly perfect from the start. On the other one I have no problem outsourcing the email as I don't plan to use it much if at all. I tried AWS for a pet project but found it to be too complicated for simple, experimental projects. I don't really get into Heroku or GAE as I have trust issues. I feel like if I can't control it then it's not reliable... Even if it is Google running it.
Reasoning: SaaS is extremely tempting. If programming is only a hobby for you I recommend it wholeheartedly. But if you're serious about your app or business, learning or hiring someone for sysops/devops is really the way to go. It's cheaper, you aren't dependent on anyone, reducing your points of failure, and you learn extremely valuable skills related to server setup and maintenance.
In my (soon to be open-sourced) deployment solution that's built on Fabric and Chef, all I need is a configuration yaml file to describe my servers. I provide IP addresses, what role(s) each one serves (app, db, static, queue, etc), what kind of software for its service I want to use (db servers should all use postgres, for example), what OS to expect on each one, and what stage of deployment that server happens to be for this project (development, staging, production). Everything is completely shared-none and non-destructive, so if I happened to have 3 VPSs, each hosting some combination of several sites' app, db, and static resources, across a different OS on each, I don't do any additional work. All I type is "make deploy" after quickly writing some lines in that config file and I can sit back and relax. Servers get setup from scratch if they're new, secured, and have services like logging all ready to go.
In essence, I get the dead simple deploy of a SaaS, with the flexibility of using whatever hosting provider I feel like, using the exact stack and details I want, for the cheapest price I can find. If my Ubuntu-running Amazon data centers flooded tomorrow, I could be deploying on brand-new RHEL Linode servers with 30 seconds of yaml changes. That kind of peace of mind can't really be bought from a SaaS provider.