I think this is a little too one-size-fits all to be very useful. This specific advice is also probably only going to serve to dissuade users making very budget installs, which might be desirable from a support resources perspective, but I think we actually have a pretty good story on scaling down.

I haven't thought about this too much, but I imagine a more helpful version of this being something like:

• RAM and CPU requirements depend on how many users you have.
• Rough idea of what they look like based on number of users.
• Tips for underspecced use cases (e.g., reduce daemons, reduce nginx/apache processes) with caveats that things are expected to work, but you're mostly on your own here, and they'll be slower.
• For larger installs, pointer to future cluster documentation.

For specific cases like T6735, it would maybe be nice to just detect that we're on a very anemic machine and raise a configuration warning ("This machine has very little RAM. See X for instructions on running Phabricator in a constrained environment. Performance will suffer. Your phd.taskmasters setting is probably too high. Your innodb_buffer_pool_size is probably too high."). We might be able to pull CPU info out of /proc/cpuinfo too and detect that.

I'd also like to understand T6735 in more detail. I hit it myself on the Phacility proto-cluster (where everything is running on micros), although I either didn't receive or missed the pcntl_fork() issue. The part where we print (empty) instead of something like "Unable to fork." is especially bad. It's possible that we can't really do a better job, but I'd like to be convinced of that first.

@epriestley is a t2.micro enough to handle phabricator for say 10 users (small startup)? What's the tipping point (concurrent requests I'm assuming not DB size for extra users)?

If you're paying 10 salaries, you should use an m3.large or sign up for Phacility.

Using a micro instance only makes sense if you have an abundance of free time and very little money, which is an unusual situation for a startup.

My experience with micro instances is that the tipping point is not load, but them randomly locking up without cause, see T8204 / T8210 for the most recent case. The number of hours I wasted dealing with those failures completely overwhelmed the tiny cost savings from not provisioning higher-tier hardware, and I don't even have a salary.

If you've had better luck with micros or are in a gambling mood or your startup is a bootstrapped charity or something, you can use a micro. There's no hard RAM or CPU cutoff anywhere, performance will just drop from bad to worse if you manage to avoid the random lockups.

@rftfaria I'm happy to help you personally for $1,500/hr -- see Consulting. Otherwise, please see Support Resources to understand the best ways to get help.

@epriestley I've just hit Enter before the question. I was just wondering if you had any recommendations for disk.

Sure, I'd be quite happy to personally help you make disk selections. See Consulting to move forward.