TL; DR – Yes, you can. But don’t. There are a lot of reasons why you shouldn’t.
If you must… scroll down for some tips.
I get asked this question a lot, by dev agencies or shared hosting resellers – often already using a control panel like Plesk. They’ll pick up a new customer who happens to be using Magento, upload to their shared server like every other site, and then call us when it doesn’t work.
This applies loosely to any shared hosting environment – Magento on Plesk, Magento on cPanel, ServerAdmin, or any a DIY solution with multiple websites on one server or VPS.
This article should be useful for Plesk server administrators, and Ecommerce CTOs who are looking at Magento hosting.
The right way
In most cases, a small dedicated VM, VPS or Cloud Server can be used to host a small Magento site in a more isolated way. LAMP Config can be honed to perfection for that site, and there’s no need to tip-toe around other websites on that same server.
A VPS, or Cloud Server with 4G memory is about where you need to start.
If you’re talking about a busier website with dedicated resources anyway, a control panel like Plesk will probably just hinder your ability to configure things at a low level. In that case, get a decent sys admin instead.
Let me start with some doom-mongering. Shared servers get compromised all the time. Ecommerce is an area where a compromise can do serious damage to business reputation.
On a shared server, you have no control over how many other sites are there, how long ago they updated WordPress (for example) or whether there are compromised sites running rogue on that server that the owner hasn’t even noticed.
It’s a numbers game – the chance of any one site being compromised might be relatively slim, but there might be 200 sites on that server. This is why shared environments (of any kind) usually don’t meet PCI compliance requirements. On the upshot, panels like Plesk do go to great lengths to try to separate websites: users, permissions, config like PHP
open_basedir, etc. Application-level compromises may not affect your site; but if it’s a root level compromise then you’ve had it.
A more everyday problem might be that you’re on a compromised server which is sending a lot of spam. Your crucial transactional emails could get lost in the server’s million-strong mail queue, or filtered as spam because of the sending server’s IP reputation.
Remember: If your Magento site is running on a shared server, then the security of your business is in the hands of the person running that server. Quite often – especially if they’re relying on control panels – those people are not very knowledgable on security topics, let alone the underlying LAMP config. I hate to say it, but it’s true more often than not. Disclosure: My first job in tech was with an IT services company, reselling shared hosting on Plesk servers. I definitely didn’t know much about security. Ignorance was bliss.
For Magento to work well, you need to tweak the LAMP stack a fair bit. Plesk and other control panels can limit how easy/feasible this is, either server-wide or per website.
High level examples:
- Varnish was popular for Magento 1 and is now a crucial part of a Magento 2 stack. Varnish config is very website-specific, so implementing Varnish on a shared server is very difficult. Possible, but will undoubtedly cause problems for other websites, and the VCL will be very messy. It’s just not practical.
- PHP version: You might even be stuck with an older PHP version, to cater for a legacy website on that same server.
Recent Plesk versions do give a lot of granularity for PHP config, even offering different PHP versions per domain, so that’s good. But those extra PHP versions might be outside of your server’s main package management. Are they getting the latest updates? See: security.
One special mention here is a PHP setting called
open_basedir. Used per website, it restricts PHP to only a certain few directories – exactly the sort of thing you want on a shared environment. Plesk uses it by default as a sensible security measure. But …and it’s a big but…
open_basedir effectively disables PHP realpath cache – an internal PHP cache which massively speeds up PHP file includes by caching filesystem paths. It makes sense, because the realpath cache is global within PHP, so having access to that cache could break the
open_basedir restriction. The downside is a big performance hit; PHP has to query the filesystem for every single include() . In Magento, we all know that’s going to be a lot. The impact can be severe.
Shared servers can sometimes be packed to the rafters with small sites. And that’s fine – many low traffic sites use barely any resource. But even a low traffic Magento site can consume a fair amount of memory and CPU. Remember that low human traffic doesn’t mean there aren’t a dozen search engine bots constantly hitting the Magento site. Layered navigation on a large catalogue can lead to a lot of crawling; you need to factor that in.
I’ve seen this several times, where a new or growing Magento site can engulf the CPU or memory on a shared server, causing downtime for many other sites. For example, Magento recommends a 512M memory limit – and it’s not uncommon to set a memory_limit of 2GB to allow for some large product import. What if you have 12G total, and 11G used by other sites? That might only be two visitors at once.
Server resources and website performance go hand in hand, but do think about the impact that the different websites will have on each other. In terms of resources (not necessarily security) it’s probably OK to run a busy Magento site and a few other, smaller sites (like a blog). But if you’re trying to run 20 Magento sites on one Plesk server, they’re going to trip over each other sooner or later. See below for how to mitigate that.
SEO makes no difference
A little off topic, but I just wanted to mention this as a non-argument. In case anyone mentions Search Engine Optimisaton as a reason not to use a shared server, or shared IP, it absolutely doesn’t matter. Matt Cutts said so, and he is pretty senior at Google. Sharing our diminishing IPv4 space with tools like SNI is very necessary, and it will not harm your SEO rankings. Or just use IPv6 already.
If you must…
If you’ve read this far , you probably have commercial or technical reasons you can’t avoid using a shared server. Here is how you run Magento on a Plesk server (or any shared hosting environment).
- Use a Full Page Cache Magento extension, which will massively reduce the server load impact as well as speed up page loads for your customers. I recommend Mirasvit FPC, instead of spending weeks with Varnish config.
open_basedir=none– if you are happy with the security implications. You can do that in Plesk under the advanced scripting options per domain – here are some instructions. My advice is to only do that for the Magento website(s), but leave the other sites restricted.
- Ask your administrator for general PHP optimisations to the global PHP config; the most important of which is to use an Opcode cache like Zend OPcache.
- Stick to the main PHP version on the server where possible, so it’ll get security updates. Anything above PHP 5.4 should be OK, but watch for EOL package sources.
- Use Redis for Magento cache, as long as you have the memory (1G should be plenty). Plesk doesn’t need to know or care that Redis is there, but it should be configured with
requirepassto prevent other sites accessing the data. If you are running multiple Magento sites, you should use a separate Redis instance for each.
- For Magento sessions – just use
<session_save>files</session_save>. Performance impact is minimal and it’s one less thing to worry about. Otherwise – if available – use memcached.
- MySQL – set max_user_connections globally. I usually set it to ~80% of the max_connections, so as not to be too limiting but prevent any one site using all connections and effectively bringing down all database-driven sites on that server.
- Set limits on the resource usage, where possible. Plesk can use Apache mod_bw to do that – see this guide. I wouldn’t limit by Kb/s – just use the overall connections. Again, the value here is difficult to judge and will be different for each site/server. Start with about the number of CPU cores you’re happy for this site to consume.
- Use a CDN, like CloudFlare. It’s free, and gives an immediate boost to page load times, especially for overseas customers. Headers for GeoIP information are also really useful if you’re an international store. It helps to reduce server/network load, and tools like the WAF (~$20/mo) can help with security.
- Understand the resource limits – I’m expecting even a bottom end dedicated Plesk server will have at least 4 CPU cores and 12 or 24G RAM. If you’re trying all this on a 1G VPS, you’re doing it wrong.