In our production environment, we have set up a three-tier architecture. Craft CMS is deployed on a server sitting in the private zone. We want to have it serving client browser's request through a proxy server which sits in the DMZ. We want to make sure the app server does not have internet access for security.

However, it seems to us that craft CMS admin page is trying to access the internet. We would like to know why it is doing that and whether this can be disabled.

1 Answer 1


Instead of blocking the CMS's access to the internet, you should consider firewalling access to the CMS from the outside world. Basically, block all incoming IP addresses but your own. I can understand your need for security, but the CMS's core functionality relies on being able to communicate with the outside world to keep the system updated.

If you block access as you're wanting to do, I think you will find that it's going to be much more difficult to manage the system. Things that come to mind:

  • You'll need to be able to keep the system updated with source control (eg. Git) which requires internet access.
  • If you get into a situation where an update fails in the CMS, you may need to run Composer via command line on the server. This will require the internet to update packages.
  • One of the best ways to manage assets (images) in CraftCMS is to use a CDN like Amazon S3. You'll get much better site performance with a CDN. If your server cannot communicate with the internet, you'll lose this ability.

I'm sure there are many more ways that you'd essentially be hobbling the system. I'm not directly answering your question here (which I would prefer to do), but instead I'm trying to dissuade you from creating a system that is unmanageable.


As I began thinking about this more, I came up with a few more things to consider:

  • Keep your CraftCMS site files on a server that has access to the internet, and connect it to a database on a server which has no internet access. I did this for a previous client using Rackspace's Rackconnect which is essentially a back-door network that is only accessible to other Rackspace servers. I'm not sure how you host, but I'm sure this can be done with other service providers. At the end of the day, what you really want to protect is the contents of the DB.
  • Set up a VPN and require that users authenticate to the VPN before being able to connect to crucial protocols like SSH. I had this scenario set up for a previous client as well. Essentially, you must establish a VPN connection first, then you can SSH into the server.

Caveat, I'm not a server security person. I've set up a bunch of servers, and learned along the way what makes good security from people smarter than me. Your IT people may have even better suggestions than what I've provided.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.