31 May

Can you run Magento on a Plesk server?

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 butopen_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).

  1. 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.
  2. Set 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.
  3. 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.
  4. 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.
  5. 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 requirepass to prevent other sites accessing the data. If you are running multiple Magento sites, you should use a separate Redis instance for each.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.




18 Jun

Magento deployment checklist

Just deployed a new Magento site? Or migrated to a new host?

Here are some things you should before you launch…

Secure it

  • Magento base code may not include the latest security patches!  Check the download page for the latest and apply them. For example, Community is still vulnerable to Shoplift out of the box.
  • Change your Admin path – anything other than the default /admin, to make your Magento backend harder to find or brute-force.  This is usually configured in your app/etc/local.xml.
  • Admin password: if you were using “admin123” while in development, now is a good time to change it.
  • File permissions: tend to get overlooked in development. Here’s a handy guide on what they should be.

Enable caches

Magento caches are often disabled during development, but in production it’s essential that they’re all ON.  In the Dashboard, go to System > Cache Management and enable them. Related article: Magento Full Page Cache

Log cleaning

This relates to the four log_* tables in the database. They’re a bit like access logs which are not rotated by default – this is bad because it bloats your database, wastes your InnoDB buffer, and makes database backups more cumbersome.

Go to System > Configuration > System > Log Cleaning and enable  it. The default 30-day retention should be fine.

Cron job

The Magento cron job should be run every five minutes. Top tip: run cron.sh instead of cron.php. The shell script first checks it’s not already running, then runs the PHP, preventing overlaps.

*/5 * * * *  /bin/sh /path/to/docroot/cron.sh

As of Magento 1.9.1, the cron job is responsible for sending customer email so it’s more important than ever.


If you are using Community Edition, indexing may not be a problem to start with, but one day it’s going to cause issues. Here’s my advice on how to configure Magento indexing.

Error pages

Death, taxes, and Magento 503s. Even a well tuned Magento application infrastructure can be complex and one day something will break. Or maybe we’re talking planned maintenance; installing a new extension for example.  Here’s a great tutorial on customising your Magento error pages.  It’s best to get this done early on, so you’re ready for the unexpected.

Top tip: Other reverse proxies like Load Balancers and Varnish (if using) will probably show their own 503 page when something is broken. Talk to your hosting provider about modifying these – default error pages don’t inspire confidence in your brand.

The goal here is a nice customer experience even when something is broken. Make sure there’s a phone number or email address at the very least. Including a discount code will encourage customers to come back and buy later.

Load test

If time allows, the last thing to do before launch is a load or performance test to get insight into what your new solution can really do.  It’s best to do that before you have real world traffic, otherwise load testing is basically DOS’ing yourself. Load testing is also likely to show up areas for config optimisation/performance, which is always a good thing.

Don’t: rely on tools like siege, or services like loader.io and blitz.io. They can be extremely useful of course, but only if you are able to interpret the results properly. Unless you have a deep understanding of HTTP protocol headers, cookies, unique session IDs, these tools probably won’t help you all that much.

Do: get it done professionally. You need a test that can mimic actual human user journeys, and repeat them on a massive scale. jMeter is great, but doing it right can be complicated and very time consuming. I would argue this is best left to professionals who do just that. Not cheap, but a necessary investment for your website’s future. Your hosting provider might offer professional load testing services, or refer you to someone who can. Soasta are excellent.