Recommended droplet size for wordpress and Joomla combo

Hi guys, can you tell me how much System requirments I need to run WordPress, Joomla and do occasional run php and python webpages on…

Let me give you a bit of context…

I want to learn how to fully customize wp and joomla but also learn php and django from the ground up… I am wondering what would be a reasonable size droplet to use for now… I expect at most no more than 5 people connecting at a time on the site… mostly it will be me just checking edits and so forth… tweaking and experimenting…

Reason I ask this is because after 7 days of headaches with zero experience of ssh, linux, commands like systemctl start httpd, ssh keys and so forth I finally thought I was going somewhere had mariandb, phpmyadmin, httpd, sftp, wordpress running but when I tried installing pureftpd I think it also installed postgresql and mariandb crushed and log said something about not being enough resources. looking at monitoring tools on DigitalOcean I saw the charts spike from 60% to 100% right at the same time too…

being the rookie I am I deleted the droplet instead of attempting to remove postgresql incase it was the reason marian would not start. I forgot what I was installing but I remember it mentioning how postgresql eats up more resources than mysql… I think it was virtualmin…

Its been a lot of try and error but I have learnt quite alot thanks to the community guides and tutorials and I am grateful for them and thanks in advance for any recommendations.

Show comments

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Accepted Answer

It would be nice to know what size droplet you currently are working with. I’m going to guess a 512 MB droplet based on the challenges you’re encountering. My experience with a LAMP stack is that 1 GB helps you get by with the common background services (httpd and MariaDB/MySQL) involved.

Wordpress’s RAM requirements is deeply dependent on the plug-ins you will have running on your site. Bare metal you can get away with 512 MB but with more plug-ins 1 GB is preferred.

I think with Joomla you can use it bare metal with 512 MB of RAM. More plug-ins and extensions will likely require more RAM.

One thing you didn’t cover was expected volume these two apps will create on your server. Higher expected volumes will require more compute resources (CPU and RAM).

You guys rock… ill go with the LEMP stack.


@hansen would be right on the mark – my full recommendation goes to NGINX over Apache in more than 99.99% of the cases I work with. This one would be no different.

NGINX does indeed use less RAM than Apache in both high and low-traffic scenarios as it doesn’t do dynamic configuration processing. You have to reload or restart NGINX anytime changes are made.

NGINX also “outsources” requests to PHP-FPM using FastCGI (a proxy of sorts), instead of building in a module like Apache does (i.e. mod_php).

At the end of the day, NGINX simply takes a request and pushes it somewhere else, which is why it can handle more traffic than Apache in most all scenarios, and do it with fewer resources. Apache handles things a little differently, builds modules in to the configuration, etc – that all equates to a lot more resources being used for, in my experience, sub-par performance.

For example, with Apache there’s a file called .htaccess, which is what WordPress uses to handle the permalink rewrites (i.e. instead of index.php?p=32 you see /category/post-title).

You can make any number of changes to .htaccess without restarting Apache as that file will be read and processed on-the-fly (i.e. on each request).

With NGINX, if you make changes to the configuration, the only way they take effect is when you do a reload or restart NGINX altogether. NGINX also doesn’t use .htaccess, and the rewrites are a little bit different, but I find them far more simplistic.

The typical WordPress .htaccess looks like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

With NGINX, that gets shrunk down to:

location / {
    try_files $uri $uri/ /index.php?$args;

The location block basically tries a URL without a slash, with a slash, and if neither of those are able to handle the request, it pushes the request to index.php with $args which would be, in the case of WordPress, the post ID, category ID, etc. You don’t have to worry about that part though, just having the $args in the location block above is all you need to worry about having in place.

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Featured on Community

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel