The Cheapest Magento Hosting for less than 10€

Why should you do that?

Well first question you might ask is why do you want to do that at all? There are a couple of factors why I think this experiment might be useful:

1. First of all from my experience as a Magento consultant I can assure that there are lots of small Magento / OpenMage shops out there running on a small budget and for whom a hosting setup of this kind could be applicable.
2. This cheap setup might also be a good option for testing and staging environments.
3. Secondly the cheap hosting environment and limited resources force you to think about your implementations very heavily as you cannot allow to release unperformant code or software.
4. Also this has kind of an environmental impact as server resources are not wasted unnecessarily.
5. In addition this article can also be a starting point for your optimizations. Perhaps you won't implement the cheapest solution but a cheaper solution than your current hosting.

And even if you do not plan to run your Magento shop on such a tiny budget, I hope this article can provide useful tips anyhow.

Requirements

Before we start let's emphasize again that of course it is a matter of how much traffic your online shop instance will receive. You cannot expect to run the cheapest hosting setup for a Magento store with more than 1000 parallel requests.
I will present the prospected numbers on my test instance in the performance results section at the end of this blog post.

In addition to the traffic the results also mainly depend on your implemented customizations in the Magento 1 / OpenMage software. There is always a performance-efficient and an -inefficient variant of a certain task. We assume that you or your developer have already optimized the source code as much as possible.
This also includes for example to optimize CSS styles, build a perfect frontend or to apply available Magento performance optimizations.

Finally you also need some basic server administration knowledge as of course for this budget we cannot afford a managed hosting provider - so we will be the Linux admin. At least you should be familiar with tools like fail2ban, rkhunter, ufw firewalls or Apache modsecurity module as you are responsible for keeping the server instance safe.
An important part for our setup is the bot prevention and security as we do not want bots to flood our Magento instance easily.

Our Setup

So how does the setup look like? We concentrate on the 3 areas software & code, the hosting itself and backup & monitoring.

Software & Code

First of all we choose Magento 1 / OpenMage as our software of choice because with some optimizations it is one of the fastest shop systems available. I will not go into too much details here as I have already described how to build a perfect frontend.

The code optimizations basically should have 2 primary goals:

1. Avoid any CPU intense operations and long-running or blocking tasks
2. Reduce the requests that actually hit our server instance to an absolute minimum

One important role in this case plays the Full Page Cache (FPC). It caches all static content pages or parts of the website that are not specific to individual users.
I use the Lesti_Fpc Magento Extension as it is a very simple but effective solution.

Also the used webserver - LiteSpeed in my case - should be tuned and optimized for performance and scarce resources. A good starting point for the Apache webserver can be these parameters.

Basically on the server instance only the absolutely required processes should run so that no ressources are occupied for no valid reason.

Hosting

The described hosting here is an absolute minimal setup which you should handle with care. Most of my recommended hosting requirements are not met or have major drawbacks.

For hosting our Magento shop I chose the German hoster Contabo. With their CLOUD VPS 1 hosting package they have in my opinion one of the best offerings regarding price and performance. For as little as 5,- € per month you will get 4 vCPUs, 6 GB RAM and 100 GB NVM storage.
The server is available super quick after your order and the performance stats are very much OK and their documentation is really extensive. Of course for this price level you can expect to have some kind of performance degradation by other instances on the same hardware ("Noisy Neighbors"). But from the data that I observed on my test instances, this so-called "CPU steal" was below 3% for most of the time.

In addition to the server itself we will implement a Content Delivery Network (CDN) in front of our Contabo instance. This is mainly - as the same for the code optimizations - to reduce the amount of actual requests that the Contabo instance has to handle. As we have limited CPU and memory resources we have to use them wisely!
For the CDN provider I have chosen Gcore CDN as it is EU-based, has a great support and some very neat features like image optimizations or a simple Web Application Firewall (WAF).

Backup

Of course for our small budget and as we do not have a managed hosting we are responsible for backups on our own (and you should never ever run a website without a comprehensive backup strategy!).
The Contabo hosting package itself does include 1 snapshot of the whole instance, which we can use to quickly reset to a server state in case of an update or if we are doing a risky operation on the server.

But this has major drawbacks:

1. Only 1 snapshot is possible (of course you could upgrade to a higher instance with more costs)
2. It is also provided by Contabo, so you have no control where this backup is placed and will you ever loose access to Contabo (for whatever reason) your backup is also gone
3. It is a proprietary format by Contabo and cannot be exported/downloaded to an external storage

That's why it is highly recommended to have an external backup space. For this purpose I can recommend the Hetzner Storage Box BX11. For less than 4 € per month we can have an external backup space that offers the possibility for incremental rotating backups. For this use case I am using the borg backup tool (but that will be part of a later blog post).

Monitoring

With limited resources as in our cheap Magento hosting it is more than important to monitor the setup very accurately.
To quickly identify issues with our setup or huge traffic spikes a reliable uptime monitoring is very much recommended. For our small budget we can use Uptime Robot as it offers a lot of features for free.
As an alternative you can also opt for a more detailed observation of your server instance, have a look at my ELK Stack Setup.

Performance Results

Of course you should not release your setup out into the wild without having it tested properly. In our case we use the Apache Benchmark tool to measure how much traffic our Magento shop is able to handle on certain page types. Note that using this tool has some limitations, especially high sensitivity to network and it only tests the PHP part ignoring any static assets (which is totally fine for our case since we are using a CDN).

Before we do that let's quickly recap our hosting costs at this point:

With this in mind, let's fire up the engine and put 100 concurrent requests onto our instance with this command (up to a total of 5.000 requests):
ab -n 5000 -c 100 https://your-instance/

Now let's have a look at the results of this command:

This is ApacheBench, Version 2.3 <$Revision: 1903618 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking your-instance (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests


Server Software:        Apache
Server Hostname:        your-instance
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-CHACHA20-POLY1305,256,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        your-instance

Document Path:          /
Document Length:        61755 bytes

Concurrency Level:      100
Time taken for tests:   61.250 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      315614125 bytes
HTML transferred:       308775000 bytes
Requests per second:    81.63 [#/sec] (mean)
Time per request:       1225.006 [ms] (mean)
Time per request:       12.250 [ms] (mean, across all concurrent requests)
Transfer rate:          5032.09 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      104  164  42.3    155     428
Processing:   160 1042 291.2    930    1943
Waiting:       75  950 291.0    844    1850
Total:        471 1206 288.5   1089    2094

Percentage of the requests served within a certain time (ms)
  50%   1089
  66%   1183
  75%   1336
  80%   1454
  90%   1730
  95%   1822
  98%   1907
  99%   1954
 100%   2094 (longest request)

What does this tell us?
Well first of all our instance did not go down or into blocking mode ("0 Failed Requests") - yeah!
Also the response times are still acceptible (1,2 seconds mean, 2 seconds for longest request).

Next step was increasing the concurrent requests up to the point when first failing requests were appearing or response times are unacceptable, let's say above 3 seconds.
This is how it looks like for 200 parallel requests:

This is ApacheBench, Version 2.3 <$Revision: 1903618 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking your-instance (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests


Server Software:        Apache
Server Hostname:        your-instance
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-CHACHA20-POLY1305,256,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        your-instance

Document Path:          /
Document Length:        61755 bytes

Concurrency Level:      200
Time taken for tests:   62.590 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      315614441 bytes
HTML transferred:       308775000 bytes
Requests per second:    79.88 [#/sec] (mean)
Time per request:       2503.612 [ms] (mean)
Time per request:       12.518 [ms] (mean, across all concurrent requests)
Transfer rate:          4924.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      216  602 231.0    529    1984
Processing:   194 1825 421.7   1693    2962
Waiting:      114 1726 427.3   1600    2856
Total:        715 2428 559.4   2222    4452

Percentage of the requests served within a certain time (ms)
  50%   2222
  66%   2438
  75%   2995
  80%   3077
  90%   3241
  95%   3435
  98%   3597
  99%   3698
 100%   4452 (longest request)

I have then repeated this with different types of URLs specific for a Magento store like Home, Catalog Page, Category Page, Content Pages, Cart, Checkout, etc.

It should also be noted that the test was made without the header Connection: Keep-Alive which would improve the response times for returning visitors.

The results show that our cheapest Magento hosting setup is able to handle about 80 requests/sec with still acceptable mean response times of 2,5 sec/request.
Assuming an average visit time of 3 minutes we'll get:
(60*60) sec/h / (3*60) sec/visit * 80 req/sec = 1.600 visitors/h

That means our cheapest Magento hosting can handle about 1.600 visitors per hour by using a total hosting price of about 9 € per month including tax - not that bad I would say!

Further Optimizations

So we have seen now that it is totally possible to run a tiny Magento or OpenMage online shop on the cheapest hosting setup on the planet - for below 10€ per month!

But what if the performance is not sufficient?
Well the main limitation of our hosting setup is the server resources, especially the CPU. So the first idea would be to upgrade to the next higher VPS instance at Contabo, the CLOUD VPS 2 with 6 vCPUs and 16 GB RAM. My tests with this instance type resulted in about 100 requests/second, i.e. an improvement of about 25% for twice the price.

This is ApacheBench, Version 2.3 <$Revision: 1903618 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking your-instance (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests


Server Software:        nginx/1.25.1
Server Hostname:        your-instance
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,4096,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        your-instance

Document Path:          /
Document Length:        41540 bytes

Concurrency Level:      100
Time taken for tests:   50.430 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      210290000 bytes
HTML transferred:       207700000 bytes
Requests per second:    99.15 [#/sec] (mean)
Time per request:       1008.606 [ms] (mean)
Time per request:       10.086 [ms] (mean, across all concurrent requests)
Transfer rate:          4072.18 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       66  109  58.9     98     546
Processing:   103  885  92.2    879    1234
Waiting:       76  858  92.0    851    1199
Total:        295  994  95.5    980    1779

Percentage of the requests served within a certain time (ms)
  50%    980
  66%   1008
  75%   1027
  80%   1040
  90%   1092
  95%   1152
  98%   1263
  99%   1309
 100%   1779 (longest request)
            

Instead of shared ones we could also use dedicated resources, e.g. with the Contabo CLOUD VDS S or by purchasing a Hetzner server in an auction. Of course this comes with the downside of 3 to 4 times our hosting costs.

What do you think? Do you have any further ideas to optimize our cheapest hosting setup for Magento?