OpenCart hosting: server requirements that actually matter

OpenCart’s documented system requirements are short enough to fit on a postcard, and almost any hosting plan sold today meets them. That is exactly why so many shops end up somewhere that fights them. Meeting the minimum gets the software installed. It does not get you a shop that stays quick on a Friday afternoon.

Four things decide whether a server suits an OpenCart shop or fights it, and those are the OpenCart hosting requirements worth knowing: the PHP version matched to your OpenCart version, a database whose defaults are not at war with the shop’s queries, a handful of PHP limits that go unmentioned until they bite, and enough headroom for the pages OpenCart has to build from scratch every time. The rest is detail.

The PHP version has to suit your OpenCart version

There is no single right answer here, because OpenCart has changed a lot across its major versions and the shops running on them have not.

• OpenCart 2.x was written in the PHP 5 era. It is at home on PHP 5.6 and the early PHP 7 releases. Push a 2.x shop up to PHP 7.4 and you will usually get warnings first and broken extensions second.
• OpenCart 3.x arrived in 2017 and swapped the old PHP template files for Twig. The later 3.0.3 releases sit comfortably on PHP 7.4. PHP 8 is where it gets interesting: core coped better than people expected, but extensions written years earlier often did not.
• OpenCart 4.x is a genuine restructure, with namespaced code and a different extension layout, and it wants PHP 8. Your 3.x extensions will not run on it.

The rule we go by: your ceiling is set by the oldest extension in the shop, not by core. A host that flips PHP versions on its own schedule is therefore a real risk to a shop with a dozen paid extensions in it, however tidy the core install looks. If one of those hosts has already emailed you about it, we have written about what that email actually means and what your options are.

The documented extension list is worth checking too: cURL, ZIP, Zlib, GD, mbstring and OpenSSL, plus mcrypt on older shops. That last one catches people out, because mcrypt was pulled out of PHP itself back in the 7.2 days. If an old shop dies the moment it is moved onto a newer PHP, mcrypt is one of the first things to look at.

The database version matters less than its settings

MySQL or MariaDB, either is fine. What causes the phone to ring is defaults.

Newer database versions ship with strict SQL modes turned on. ONLY_FULL_GROUP_BY rejects a shape of query that older OpenCart code and older extensions use freely. The rules about zero dates reject the placeholder dates that old shops are full of. Neither problem announces itself politely. You get a blank category page, or an order that will not save, and it looks for all the world like the shop is broken rather than the server being fussy.

MySQL 8 also changed its default authentication method, which older PHP builds cannot speak. A shop that connected happily for a decade suddenly cannot reach its own database, and the error message is not the one you would hope for.

Two more worth knowing about. Character sets: a lot of older shops were created as utf8 rather than utf8mb4, so anything outside the basic set, including emoji in a delivery note and some accented names, arrives mangled or refuses to save. Converting is doable but it is a planned job, not a Sunday one. And connection limits: shared plans cap how many database connections you get, and a shop with staff running reports while customers check out uses more than one at a time.

The PHP limits that quietly lose your data

Memory first. PHP’s stock 128M is enough to browse a shop and not much else. Bulk edits, image resizing, exports and admin backups all want more, so 256M is a sensible floor for a working shop.

Then max_input_vars, which is the one we end up explaining most often. PHP will only accept a set number of fields in a submitted form, and the default is 1000. A product with a long list of options, a category screen with a lot of filters, or a layout page on a big shop can post more than that. PHP does not error. It accepts the first thousand and throws the rest away, so you save the product and half the options have vanished. If your shop keeps “forgetting” things you swear you entered, start there.

After that: max_execution_time, because product imports and backups from the admin are long jobs; and upload_max_filesize with post_max_size raised together, because extension packages and product photography both arrive as uploads and both fail in the same confusing way when only one of the two is generous.

OpenCart builds most pages from scratch

This is the difference that catches out hosts who mainly deal with blogs. A cached WordPress page costs the server almost nothing. OpenCart has no full page cache in the box, so a category listing means PHP running and the database answering, every time, for every visitor.

Add filters and it multiplies. Every combination of manufacturer, price band and attribute is a separate URL doing separate work, and a crawler will happily walk thousands of them overnight. No orders came in, no one was awake to see it, and the shop still spent the night building category pages.

Practically: opcache on, PHP-FPM rather than whatever the plan defaults to, and CPU you actually have rather than share with three hundred neighbours. If a caching layer goes in front of the shop, cart and checkout stay out of it, and somebody tests that properly before it goes live.

Disk space is rarely the limit you hit

OpenCart generates a resized copy of every image at every size a theme asks for and keeps them in an image cache folder. A catalogue of a few thousand products turns into a very large number of small files, and shared plans cap the number of files you may have long before they cap the gigabytes.

Two more things fatten up out of sight. An error log can outgrow the shop it belongs to when a single extension is noisy enough. The session and statistics tables keep every row they were ever handed, because nothing in OpenCart prunes them and pruning them was never anyone’s job.

What actually goes wrong on cheap shared hosting

Not usually a dramatic failure. It is a series of small ones.

The PHP version is chosen for you and changed on the host’s timetable rather than yours, which for a shop with a dozen paid extensions is the whole risk in one sentence. Concurrent process limits throttle the shop at exactly the moment a campaign lands, so the person who clicked your advert gets an error page instead of a slow one. Cron is restricted or missing, and currency updates, feeds and scheduled exports stop running without announcing it. Order confirmations leave from a shared IP address whose reputation you had no hand in building, so a share of them get filed as junk before anyone reads them, and there is nothing in the admin that will tell you which ones.

The one that costs the most is the last one. Nobody on the support desk has ever seen an OCmod conflict, so every problem comes back as “that is an issue with your website, please contact your developer”. On a shop where the modifications are the reason it works the way you want it to, that reply ends the conversation instead of starting it, and you are back paying a developer to diagnose a server you cannot see into.

If your shop is on OpenCart 2 or 3 and a host has told you to upgrade or move on, that is a separate conversation, and we have written up what it takes to run an older OpenCart shop properly rather than rebuild it. Our legacy PHP hosting page is where those shops end up living. For a shop on a current version that simply wants a server built for it, our OpenCart hosting page is the one to read, and sites with no shop attached are better served by our managed web hosting.

OpenCart hosting requirements FAQs

Before you pick a plan

The oldest extension in your install sets your PHP ceiling, and nearly everything else on this page follows from where that ceiling sits. So tell us what is installed and how far the catalogue has grown, on 01623 650 333 or in writing, whichever suits you, and the sizing falls out of it. Managed hosting here starts at £1 a day + VAT. A shop with two thousand products and fifteen extensions behind it is a different sum, and we would rather work that sum out than guess at it.