All on one box until it gets some traction. But I always setup an external monitoring (e.g. pingdom) service to get a notification, when something is down and a

All on one box until it gets some traction. But I always setup an external monitoring (e.g. pingdom) service to get a notification, when something is down and a cronjob for daily (db-)backup. Scaling steps with traction: 1.) dedicated server for DB 2.) loadbalancer (AWS ELB) & 2nd app-server 3.) scripting server mgmt (AWS OpsWorks, chef, puppet, ...) 4.) adding missing server roles (e.g. caching through memcache) to scripts 5.) deployment, up-/down-scaling with button clicks 6.) Slave-DB (more for ongoing backup and fail-over than for read-distribution) 7.) if you don't use AWS ELB don't forget to make sure the LB is not your single point of failure Usually I have more than 1,000 registered users before I start with scaling step 1.