Published on May 2nd, 2016 | by Sunit Nandi

Standalone Nginx servers and WordPress – you decide?

Introduction

I have been blogging at Techno FAQ for the past 3 years, but you might have noticed that most of my articles revolve around reviews, apps or hardware. In my work life, however, I’m a student and a freelancing consultant for servers, Linux administration and web development. So, as a change to my usual style of writing, I’ll focus on what I know and do best in everyday life, that is, web servers.

So today, in the midst of performing plugin updates, I noticed that the developers (Red Sand Media Group) of RS Feedburner plugin for WordPress has a cool blog. As I’m pretty much always interested in reading stuff, I started scrolling through their blog. One of the articles titled “Standalone Nginx Servers and WordPress Don’t Mix” by Scott Allen caught my eye. I read the article fully and found several discrepancies that I think I should point out to the Internet community. Before I proceed to expressing my thoughts, I’d suggest you to go through their article first by clicking here. After you read and return here, you’ll have sufficient background of the topic and will understand better what I’m referring to.

While the article does serve to clearly drive in the fact that Nginx is not a drop-in replacement for Apache, the failed logic and fear-mongering it uses throughout the entire article is appalling. I do understand you’re trying to educate the public, Mr. Allen, but trying to bust a myth with more misinformation is not a noble job, my man.

The Rebuttal

In my classical debate style, I’d like to point out where the discrepancies in the article are quote by quote.

Quote: “Nginx as a standalone server is not ready for primetime. That may sound harsh, but it is absolutely the truth. It is especially true when it comes to self-hosted WordPress sites. However, using an Apache/Nginx hybrid setup — with Nginx as a reverse proxy in front of Apache — has the speed benefits and allows all the functionality of Apache. (In real-world applications, this setup is actually faster than either standalone Nginx or standalone Apache servers.)

We don’t recommend standalone Nginx server setups for WordPress…in fact, we highly discourage it! Instead, we recommend the Apache/Nginx hybrid setup: Apache as the actual server that runs everything, with Nginx in front of it as a reverse proxy/cache/load balancer. (This has incredible performance…and things work perfectly. Perfectly.)”

Rebuttal: I don’t really believe in your claims unless you back it up with proper data. If only you had made a test site with proper server response time tests, and made the configurations public, I’d be more than happy to accept what you claim after verifying it myself. I have run Techno FAQ on standalone Apache, Apache + Varnish, Apache + Nginx as proxy, and standalone Nginx and in my personal tests, standalone Nginx is the winner in CPU load, RAM usage and response time. Whereas in the past, I had to shell around $30 for a VPS for a site of this traffic, today it runs smoothly on a $10 instance with standalone Nginx. I am saving a lot for the past few months and my traffic has doubled as well.

Quote: “Having pure Nginx disables the ability to use .htaccess files, which are required by many WordPress plugins, including WordPress itself. If you’re not familiar, .htaccess is a very important configuration file used on Apache servers. Nginx claims that allowing .htaccess files in subdirectories is a resource hog, but this simply doesn’t line up with the results of true performance tests because it is offset by other factors.
Considering that WordPress powers 26%+ of the web, we don’t consider standalone Nginx a practical server config for any kind of open source or commercial web software. (You won’t be able to use any of the WordPress caching plugins, security plugins, or minification plugins.) However, the Apache/Nginx hybrid setup is awesome and overcomes all of the potential issues. If Nginx would allow .htaccess, it would be great. The advertised speed improvements of Nginx over Apache have been greatly reduced in recent years, and with a hybrid setup, it’s nonexistent, and you get the best of both worlds.”

Rebuttal: Granted Nginx doesn’t support .htaccess and isn’t an exact replacement for Apache but it doesn’t make it any less of a webserver by itself. There are good configs for WordPress and plugins available for use with Nginx and they work perfectly. If Nginx isn’t supported by a plugin, then it isn’t Nginx developers’ fault, clear and simple. Its just the reluctance or stepmotherly attitude of plugin developers that Nginx is treated as a second grade citizen in the WordPress world. If your plugin can generate and place .htaccess files, they can also be coded to generate Nginx configs. No big deal. I’ll discuss on how to deploy shared Nginx configs from plugins later. Also, this is the third time you’re emphasizing the hybrid setup, which I feel is unnecessary.

Quote: “Be cautious of web hosts that advertise “WordPress Optimized Hosting” on “Nginx”. Make sure that it is the Apache/Nginx hybrid, not standalone Nginx. If it’s on standalone Nginx, then it’s a sham…steer clear of that web host because they clearly do not know what they are doing. Good web hosts know how to do it right, and set things up with Nginx as a reverse proxy in front of Apache.

Recently, I received a support request from a small website hosting company that offered just such a thing. They advertise “WordPress Optimized Hosting”…on standalone Nginx. I wanted to slap myself. They couldn’t understand why their customers were having so many issues. I had to spend some time educating the owner on what they are doing wrong, and exactly what kind of effects this will have on WordPress and plugins. Ugh. Don’t buy into the marketing hype, folks! Nginx is not a magic bullet for speed. (It’s actually quite the opposite.)“

Rebuttal: Granted Nginx doesn’t make a good webserver because of centralized config system and lack of .htaccess, but that makes sense for the case of shared hosting only, running cPanel, Plesk or whatever. For WordPress optimized hosting, Nginx does the job fine. Your idea reverse proxy isn’t the only correct way of implementing it. And again, since Nginx is not Apache, do not expect that it will magically solve everything like a traditional configuration. Those who run Nginx as a hosting platform should know the ins-and-outs of the webserver, otherwise they simply shouldn’t use it. Instead of putting a blanket blame on Nginx, its better that the owner should be educated about how Nginx works instead of making him buy your reverse proxy idea that you preach over and over again.

Quote: “And that’s where they are missing the big picture: .htaccess provides a LOT more functionality than redirection/rewrites.

.htaccess provides a mechanism for:

Complex security directives – Protecting any specified combination of files, directories, etc.
Caching directives – Server-side(server caching), surrogate(proxy caching) and client-side(browser caching) such as setting/modifying expiration dates, setting far-future cache headers, setting/removing Etags, etc.
SEO directives – Rewriting and redirection that overrides server defaults, blocking and allowing certain files, adding/removing X-Robots tags, and much more.

These are all things that need to be done at a directory level.

Yes, Nginx can provide rewrites and redirection in its configuration at a server level, but it cannot be done at a directory level…so this is not the same at all.

So let’s be very clear, by using a standalone Nginx setup with WordPress, you can actually damage your site in the following areas:

Security
Speed (“Wait, what? But I thought that Nginx was fast?” Yes, speed! We’ll get to that in a moment.)
Search Engine Optimization (SEO)

“

Rebuttal: So here is where the real fallacy begins. You claim that .htaccess is more magical and has more features than Nginx’s config files.

Complex security directives? “allow” and “deny” are possible in the location block:

server {
...
    location /wp-admin/ {
        allow 192.168.1.1/24;
        allow 10.0.0.1/24;
        deny all;
}

You can block bots too 😉

map $http_user_agent $blockedagent {
        default         0;
        ~*malicious     1;
        ~*bot           1;
        ~*backdoor      1;
        ~*crawler       1;
        ~*bandit        1;
}

Prevent image hotlinking:

location /img/ {
    valid_referers none blocked 192.168.0.25;
    if ($invalid_referer) {
        return   403;
    }
}

Even rate-limit access per IP address (click here to read the docs):

location /account/login/ {
    # apply rate limiting
    limit_req zone=login burst=5;

    proxy_pass http://myapp;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
}

I still do not understand what you’re trying to say by saying .htaccess is more powerful. The only thing we know is that while Apache follows XML-style syntax, Nginx uses C-style syntax. Both are equally powerful. Nginx’s compact syntax makes rule-writing and debugging easy. Apart from that I don’t see how .htaccess is syntactically more powerful.

Coming to caching directives, why not look at a part of the nginx.conf file generated by W3 Total Cache?

# BEGIN W3TC Page Cache cache
location ~ /wp-content/cache/page_enhanced.*html$ {
 expires modified 3600s;
 add_header Vary "Accept-Encoding, Cookie";
 add_header Pragma "public";
 add_header Cache-Control "max-age=3600, public";
}
location ~ /wp-content/cache/page_enhanced.*gzip$ {
 gzip off;
 types {}
 default_type text/html;
 expires modified 3600s;
 add_header Vary "Accept-Encoding, Cookie";
 add_header Pragma "public";
 add_header Cache-Control "max-age=3600, public";
 add_header Content-Encoding gzip;
}
# END W3TC Page Cache cache
# BEGIN W3TC Browser Cache
gzip on;
gzip_types text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon;
location ~ \.(css|htc|less|js|js2|js3|js4)$ {
 expires 86400s;
 add_header Pragma "public";
 add_header Cache-Control "max-age=86400, public";
}
location ~ \.(html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml)$ {
 expires 3600s;
 add_header Pragma "public";
 add_header Cache-Control "max-age=3600, public";
}
location ~ \.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|json|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|wav|wma|wri|woff|xla|xls|xlsx|xlt|xlw|zip)$ {
 expires 86400s;
 add_header Pragma "public";
 add_header Cache-Control "max-age=86400, public";
}
# END W3TC Browser Cache

I guess you should read the docs on the headers module.

Talking about SEO directives, I guess you should look up what things Nginx can do. Rewriting, overriding server defaults, blocking/removing header tags is all possible. It just that plugin devs have not given the attention Nginx deserves to get, while Nginx adoption is steadily on the rise.

While I accept that Nginx doesn’t have directory level configs, but there does exist a way it can be made to work with per site custom config with the help of the include statement (read the doc here). So lets say you have a WordPress site on your server with the files placed at /home/dave/wordpress. To implement per-site plugin config, we create a folder named nginxconf. So our Nginx configs reside in/home/dave/wordpress/nginxconf. After that we can add the following to the server{} block in Nginx:

include /home/dave/wordpress/nginxconf/* ;
location /nginxconf {internal;}

The first line tells Nginx to read config information from the nginxconf directory. The second line tells Nginx not to allow nginxconf directory to be served by HTTP. Any plugin that wishes to change/override the webserver config simply needs to write a file to that directory. Simple! All we need after that is a webserver reload and we’re good to go.

Granted implementing the above in cPanel or any popular shared hosting panel is hard but people who provide custom optimized WordPress hosting can definitely implement it given enough time. Also, plugin developers can rewrite their plugins to take advantage of this method. Everything is possible, but who will bell the cat? W3 Total Cache generates an Nginx config as a nginx.conf file which can be included in the server{} block. Why aren’t other plugin devs not doing the same? And why we can’t all agree on a standard configuration path in Nginx? Simply because no one is f**king interested. This isn’t an Nginx technical issue. Period.

Quote: “Security plugins are unable to make hardening modifications only done by .htaccess, such as adding site-specific directives to protect certain files, or disable PHP execution in your uploads directory. (That’s just one example of many.) Plugins you will not be able to use: WordFence Security, Sucuri Security, iThemes Security, or literally ANY WordPress security plugins. (See below for more.) This means that site owners who are not security experts have to hire a security expert to lock down their site, instead of being able to use off-the-shelf free plugins.

Backup plugins like UpdraftPlus Backup, WP-DBManager and others cannot protect the backup directory by placing an .htaccess file that blocks browser access to your database and website files. An attacker can then download your database and website files (including your wp-config.php which contains the secure database keys for your WordPress site!) and can potentially use the info gleaned to compromise your site. This forces a plugin to consider a backup option such as changing file permissions, but is not as reliable or secure.

For this very reason hackers LOVE standalone Nginx servers!!
Now you can’t use any of WordPress’ site backup plugins! Good luck if your site gets hacked! Restoring things will be a nightmare.

Because of these quite serious flaws, any Nginx standalone server setup needs to be reviewed by a security expert before launching a WordPress website on it, whereas this is not necessarily the case with an Apache/Nginx hybrid. (Although it is a good idea to have any site reviewed by security expert before launch.)”

Rebuttal: The entire argument you have placed forward has zero logic or backing facts. This is plain fear-mongering in order to drive potential adopters away from Nginx. Instead of convincing users that ‘Nginx is bad. You will face nightmare.’, code your plugins to help Nginx users deploy them. If you cannot decide how to apply the rules automatically, make the plugin show a guide for Nginx users to configure it by themselves. W3TC does it, why can’t the others do the same? Also, see my previous point for site-specific configs.

Here is a sample Nginx config for disabling PHP execution in uploads directory:

# Deny access to any files with a .php extension in the uploads directory
# Works in sub-directory installs and also in multisite network
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~* /(?:uploads|files)/.*\.php$ {
	deny all;
}

Its just a two-line rule for god’s sake (leaving the comments).

Also, you want to block access to wp-config.php?

location /wp-config.php {deny all;}

Get plugin authors to either guide Nginx users interactively with the plugin or install the config to a path specified by an include directive, and we won’t need to worry about any of this anymore.

Also, you don’t need a security expert. You need someone who understands Nginx well.

Quote: “Any speed improvement provided by this only has value in a testing environment, not in real-world website development. A lot of things work in theory, or in a laboratory environment, but don’t work the same way in real-world applications. This is one of them. This small and marginal speed benefit is greatly offset by a number of other flaws that are introduced by not allowing .htaccess files (or similar directory-level config files).”

Rebuttal: Do you have any data to back your claim? And what has speed got to do with .htaccess?

Quote: “One major reason why this wouldn’t improve site load speed is browser caching. If a site is properly set up to serve files that can be cached in a browser, then there is no repeat request sent to the server. Except…and here is the gotcha…with standalone Nginx and WordPress, if there is no .htaccess file, then you can’t properly setup the server for browser caching (because, again, for optimum performance, this type of directive has to be allowed on a directory-level), which will actually result in more requests sent to the server. So, what Nginx developers aren’t telling you is that using a standalone Nginx setup will result in more requests to the server! Ouch.”

Rebuttal: So how is W3 Total Cache working on my site then with browser caching? Here’s the secret sauce. Ouch!

Quote: “.htaccess is a standard and important feature in PHP/Apache web development. Removing features to gain marginal, lab-only speed benefits is not good practice. Sure, we can also make PHP faster by hamstringing some of its key features, but that’s a terrible idea.”

Rebuttal: Your analogy is like saying “Linux is bad because it doesn’t support .exe files, which are essential in running/installing apps in Windows. One shouldn’t dump Windows just to gain speed and reliability benefits.” It only confirms that developers are simply reluctant to try something out of their comfort zone. And again, read up on my previous point of per-site custom config.

Quote: “This specific issue is almost completely negated if the web host is using SSD drives. You will get far more benefit from using a web host with SSD drives, than simply switching to a standalone Nginx setup.”

Rebuttal: SSDs will speed up any application irrespective of what you use, simply because disk seek time is zero. This is not an excuse for bad practice. Its like saying I can write bad code and get away with it ‘cuz my CPU is very powerful.

Quote: “The number of CSS and JS files that are called from a site make a far bigger difference in how fast a site loads.
Plugins that minify and concatenate CSS and JS make a huge difference in website load speed. These require specific browser-caching configuration directives that only .htaccess can provide.
Standalone Nginx servers will not allow these plugins to work.
For all these reasons, you have to hire a website speed optimization expert to do it manually for you. Again, ouch!”

Rebuttal: HOW THE F**K IS W3TC WORKING? Also, what has minification got to do with browser caching? You need HTML Tidy, JSMin and CSS Tidy extensions in your PHP for minification, and concatenation and file path rewriting is done by PHP+libxml output buffering and string replacement. Headers can be passed as a custom Nginx site config. What misinformation are you trying to convey?

Quote: “A standalone Nginx server, by not having ability to use .htaccess files, effectively cripples a high percentage of the top plugins for WordPress. Let’s take a look at some of the top plugins you can’t use effectively on a standalone Nginx server:

Speed Optimization plugins:
- Caching Plugins:
  - WP Super Cache – Rated 4.2 stars / #12 Most Downloaded Plugin
  - W3 Total Cache – Rated 4.3 stars / #15 Most Downloaded Plugin
  - WP Fastest Cache – Rated 4.8 stars / #94 Most Downloaded Plugin
  - WP Rocket
  - All other caching plugins
- CSS & JS Minification and Concatenation plugins:
  - Autoptimize – Rated 4.7 stars / #103 Most Downloaded Plugin
  - Better WordPress Minify – Rated 4.3 stars
  - RS Head Cleaner Plus – Rated 4.2 stars
  - All other CSS/JS minification plugins
Security plugins:
- WordFence Security – Rated 4.9 stars / #10 Most Downloaded Plugin
- Sucuri Security – Rated 4.6 stars / #88 Most Downloaded Plugin
- iThemes Security – Rated 4.7 stars / #25 Most Downloaded Plugin
- All In One WP Security & Firewall – Rated 4.8 stars / #63 Most Downloaded Plugin
- Bulletproof Security – Rated 4.7 stars
- All other security plugins
Site backup plugins:
- Database backup plugins:
  - WP-DBManager – Rated 4.4 stars / #83 Most Downloaded Plugin
  - All others
- File & Database Backup plugins:
  - UpdraftPlus – Rated 4.9 stars / #27 Most Downloaded Plugin
  - BackWPup – Rated 3.9 stars / #42 Most Downloaded Plugin
  - Backup WordPress – Rated 4.7 stars / #73 Most Downloaded Plugin
  - Most others
SEO plugins:
- All in One SEO Pack – Rated 4.4 stars / #4 Most Downloaded Plugin
- Yoast SEO – Rated 4.0 stars / #3 Most Downloaded Plugin
- Google XML Sitemaps – Rated 4.9 Stars / #6 Most Downloaded Plugin
- All others
Anti-spam plugins:
- Akismet – Rated 4.8 stars / #1 Most Downloaded Plugin, Included with WordPress
- WP-SpamShield – Rated 4.9 stars / #87 Most Downloaded Plugin, Leading Alternative to Akismet
- Many others
Ecommerce Plugins:
- WooCommerce – Rated 4.6 stars / #8 Most Downloaded Plugin
- WP eCommerce – Rated 3.5 stars
- Easy Digital Downloads – Rated 4.9 stars
- Most others

“

Rebuttal:

WP Super Cache: Works! See WordPress codex.

W3 Total Cache: Works! We use it here at Techno FAQ.

WP Fastest Cache: Works! Read their FAQ.

WP Rocket: Works! See this GitHub repo.

CSS and JS minification apps usually don’t need all that .htaccess magic, except of course RS Head Cleaner Plus, which is your plugin.

Backup plugins don’t need .htaccess magic, except to guard their backup directories (if at all) which can be inserted as a online liner in a server{} block or as a custom site config.

All-in-one SEO pack: Works! We use here at Techno FAQ. Needs no additional config.

Yoast SEO: Works! Here are the rewrite rules.

Google XML sitemaps: Works here at Techno FAQ, use the following config:

rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;

Akismet: Are you serious? It works irrespective of webserver.

WordFence: Works! Have a look here.

WP-Spamshield: Oh, that’s your plugin. And I see you try to deter potential Nginx adopters here.

WooCommerce: Doesn’t need extra configuration unless you have a caching plugin. You can put the no-cache rules in the caching plugin, which in turn will generate the nginx config.

I’m not interested in looking up the others. But do you see, your statement is invalid in all respects? A simple search on Google with “<plugin name> nginx” search term will tell you they work on Nginx and how to configure them for the same.

Its 2016, and it seems most popular plugins already support Nginx. However, there are a few devs, including you, who are simply not interested in supporting standalone Nginx installations and standard Nginx directory paths.

Quote: “Take a look at how many of these are in WordPress’ Top 20 plugins…one, two, three…eight! 8 of the top 20 WordPress plugins are handicapped on a standalone Nginx server! That’s 40% of the top 20! And, I didn’t check every plugin in the top 20. I just did a spot check of some of the leading plugins. It’s likely that more of the top 20 would be crippled as well. If you go further and check the code of all the other plugins in the WordPress plugin directory, you will find a ton more. Therefore, using a standalone Nginx server effectively prevents you from using the best and most popular WordPress plugins. These plugins are free, and provide extraordinary functionality for websites. That means that to get the same functionality, you have to hire experts to write code specific to your site, making your website development costs astronomically higher than those using an Apache/Nginx hybrid setup or a standalone Apache server.”

Rebuttal: At this point I think your arguments have no weight. A lot of plugins can run on standalone Nginx.

Quote: “A Server that Cripples the Internet’s Top CMS and its Top Plugins, is NOT a Viable Replacement for Apache. WordPress is undisputedly the top Content Management System (CMS) in use by websites in 2016. It is used by over 60% of all the websites whose CMS we know. The next closest competitor is Joomla with just over 6% of the CMS market share – only a tenth of what WordPress has. This means that WordPress powers over 26% of the web. Think about that for a second…more than 1 in every 4 websites is powered by WordPress. This is why I make the strong point that standalone Nginx is not ready for primetime, and it is not yet a viable substitute for Apache.”

Rebuttal: No, its simply your attitude to change that cripples the Internet’s top CMS. Unless you’ve been living under a rock, you must know that 1/3rd of all websites run Nginx. What makes you think its not ready for primetime?

Quote: “Don’t get me wrong, Nginx is great…when used in an Apache/Nginx hybrid setup. If you set up Nginx as a reverse proxy in front of Apache, you will get better speed benefits than either Nginx or Apache alone, and you have all the functionality of Apache. That’s the winning combo. That’s what we use it, and what we recommend.”

Rebuttal: Finally coming to your hybrid setup, what makes you think it is very workable and secure compared to standalone Nginx? Let me speak about this is detail now.

You can configure your Nginx installation to serve static files directly while proxying dynamic requests to Apache which again references PHP. In this state, the Nginx server will serve static files from the WordPress root. To protect from unauthorized access to sensitive areas, you’d need to configure Nginx in exactly the same away as you’d configure Nginx in standalone mode or else it will leak your wp-config.php and whatnot?

The other way is a caching proxy server in front of Apache for all requests. So Nginx caches all content for a set period of time depending on what headers Apache passes to it. Now my question is, how do you deal with cache invalidation when you change files? Unlike Varnish, Nginx doesn’t have cache purge URLs by default. The Cache Purge option comes as a separate module for Nginx which needs to be added in during compilation. Someone installing Nginx from a Linux distribution’s package repositories won’t get that feature. So unless your sysadmin is skilled enough, he’ll have a hard time dealing with cache management.

All things considered, your winning combo is as difficult or even harder setting up compared to a standalone installation. And Apache is a RAM hog and needs increasing more memory for more number of requests. Makes no sense.

So going by your logic, if we are dealing with Nginx as a reverse proxy, it could be troublesome for an inexperienced user. It makes sense for shared hosts only.

Coming to speed benefits, we have no definite data or study from your side, so I’m having difficulties in believing your bold claims.

Conclusion

Now that I’ve pointed out the discrepancies in the article, I’d like to state that Nginx is equivalent to Apache. Its approach to the task differs with respect to Apache. It has a different syntax, different config style and different architecture, but is no way less powerful than Apache. Its all a matter of preference. The only group who will be affected by the lack of .htaccess is the shared hosting community. Apart from that, it serves its purpose in every other respect and works pretty well.

I’m in no way affiliated with Nginx. I simply wrote this article to point out how many misconceptions are floating around regarding this subject matter.

As for Red Sand Media Group and Mr. Allen, you guys need to:

Research before you write.
Stop spreading misinformation.
Stop fear-mongering just to avoid handling support issues from Nginx users.
Stop blaming a fully functional web-server design just because of your own incompetence.

As for me, I’ll simply move to a different plugin once you stop Nginx support.

For everyone else, I’d suggest you all to use the webserver that meets your needs and you’re the most comfortable with. If you plan to switch webservers, make sure to read the docs properly and study the paradigm of the new webservers. I won’t recommend Nginx for shared hosting companies, mainly because it is a pain to maintain. But if you are a VPS or a dedicated user who likes to tinker, trust me, Nginx is pretty stable enough to run WordPress the way it is. You may face a few rough edges after switching over from Apache, but with time, you’ll learn to love the simplicity.

What do you think about standalone Nginx and WordPress? Let us know in the comments below.

Tags: Apache, decide, hosting, nginx, plugins, servers, standalone, web development, web hosting, WordPress

About the Author

Sunit Nandi I'm the leader of Techno FAQ. Also an engineering college student with immense interest in science and technology. Other interests include literature, coin collecting, gardening and photography. Always wish to live life like there's no tomorrow.