Grav on production: APACHE or NGINX?

First of all, let me say you congratulation for your work on Grav CMS. I love it :slight_smile:

I have a question regarding security on production.
I am currently trying to host Grav on Amazon Lightsail with LAMP stack, using Bitnami.

I had to create apache virtualhost conf to get the CMS work in my domain name, since I’ve put the project into a subfolder and I plan to host several sites in the same VM.

Though, I didn’t find other way than adding the following lines in my vhost conf file, to get all the URLs working:

<Directory /opt/bitnami/apache2/htdocs/grav>
    Options FollowSymLinks
    AllowOverride All

But in the Bitnami docs there is a line precising:

For security and performance reasons, it is advisable to not set AllowOverride to anything other than None

So it seems that my solution works but is not secure.
Is that really true ?
What would be the other way to have the page URLs working correctly if not using that config ?


I think this article gives a perfect answerd to your question :slight_smile:

Thanks for your answer @RobLui

I noticed that Grav documentation doesn’t give any other way to have URL rewriting when using Apache:

You should also ensure you have AllowOverride All set in the and/or blocks so that the .htaccess file processes correctly, and rewrite rules take effect.

Would that mean that Apache is not recommended to run Grav on a production environment ?
Would you recommend to use Nginx instead ?

I renamed the topic to clarify what is actually exactly the question:
To host Grav on production, is it better to use Apache or Ngninx ?

Does apache present a security risk with this AllowOverride All directive ?

I’m not sure why you wouldn’t want to do it with Apache :slight_smile: I myself, don’t mind the AllowOverride All on any of my Grav sites, as long as they’re well contained within the framework I’m pretty sure it’s safe enough. And a security risk … If your site attracts X-million users, this would be a ++ important question. If not, just go ahead and choose the one you feel comfortable with, and ignore the warning… :slight_smile: Hope it helped

Allright, I guess you are right @RobLui
I will just ignore this for now :slight_smile:

Yeah, I find that article by Kevin Schroeder rather unconvincing, I have to say. I’m sure the performance impact mentioned there matters for Twitter, but certainly not for any site in the segment I’m catering to. (And do his tests assume encrypted connections? If not, then the relative performance impact might be even smaller.)

And I’ve found little to substantiate the alleged security risk. Of course, it’s not “null”: Whatever decreases options for an attacker increases security. But worrying about this feels to me like worrying that a buglar might break through the walls of your stone house without alerting the neighbours, while you should be worrying about the security of your door.

People, like me, who have to use shared hosts don’t have any option anyway. My clients need a glorified internet business card or internet showcase. If I told them to rent a server and hire a sysadmin for security, they’d go looking for another web designer. In fact, I can be glad, if they don’t change the website’s password to “nancy1969”.

I find this answer on Stackexchange rather more convincing:

1 Like