Magento Hosting

Why does Magento need its own server?

Magento needs its own server because Magento 2.4 is not a single PHP application but a system of several services working together: a web server and PHP-FPM, a database, OpenSearch as the search engine, Valkey for cache and sessions, and optionally Varnish and RabbitMQ. Java-based services such as OpenSearch cannot run on shared hosting, and Magento installation does not complete without a search engine connection.

Beyond that, day-to-day Magento operation relies on the command line. You need Composer to install modules, bin/magento setup:di:compile to compile code, setup:static-content:deploy to generate static files, and a cron job running every minute to process indexes and email queues. These commands use a lot of CPU and memory for minutes at a time, which collides with the process limits of a shared environment.

The right environment for Magento is therefore a virtual server with full root access and resources dedicated to you. In LIONFIN VDS server plans, cores, memory and NVMe storage are fully dedicated to you, and thanks to KVM virtualisation you choose the operating system and service versions yourself. You can compare plan values in the table on this page.

What are the Magento 2.4 system requirements?

Magento 2.4.9 has been tested with PHP 8.5, MySQL 8.4 or MariaDB 12.3, OpenSearch 3, Valkey 9, RabbitMQ 4.3, Varnish 8 and Composer 2.10. The current patches of Magento 2.4.8 run on PHP 8.3 and 8.4 with MariaDB 11.4 and 11.8. Adobe supports only the version combinations it lists; for example, before moving to 2.4.9 you must also upgrade the database server to a supported version.

On the PHP side, the bcmath, ctype, curl, dom, gd, intl, mbstring, openssl, pdo_mysql, soap, sodium, xsl and zip extensions must be present. Adobe notes that application and extension updates can use up to 2 GB of memory and recommends creating swap space on systems with less memory. Because the version list changes with every patch, check the Adobe Commerce system requirements page before installing.

Which services run on a Magento server?

In a single-server Magento installation, seven services work together, each with a different job. Understanding this structure makes both server sizing and troubleshooting easier.

• Nginx: Receives incoming HTTPS requests, serves static files directly and passes PHP requests to PHP-FPM. Magento ships a ready configuration in the nginx.conf.sample file in its root directory.
• PHP-FPM: The process pool that runs Magento code; concurrent visitor capacity depends mostly on the size of this pool and memory.
• MySQL or MariaDB: Stores product, order, customer and configuration data.
• OpenSearch: Provides catalogue search and layered filters; it is Java-based and reserves its own heap.
• Valkey: An open-source, Redis-compatible key-value store; it moves Magento’s cache and sessions from disk into memory.
• Varnish: Caches entire pages sent to visitors; category and product pages are served without running PHP.
• RabbitMQ: Holds bulk operations, stock updates and integration messages in a queue and processes them in the background.

None of these services should be directly exposed to the internet: only ports 80 and 443 are open to the outside world, plus SSH for administration. OpenSearch, Valkey and RabbitMQ should listen only on 127.0.0.1. If you prefer Docker, you can define the same services in a Compose file; see Docker hosting for that approach.

How many resources does a Magento server need?

For a small Magento store on a single server, at least four dedicated cores and 8–16 GB of RAM is a realistic start; mid-sized multilingual stores using Varnish and RabbitMQ need eight cores and 16–32 GB of RAM. The values in the table are approximate; what really decides is not the product count but the number of concurrent visitors and the share of requests that cannot be served from cache (cart, checkout, account).

When planning memory, add up the services one by one:

• OpenSearch: A 1–2 GB heap is enough for small catalogues; never make the heap more than half of total memory.
• Database: If the InnoDB buffer pool (innodb_buffer_pool_size) is large enough to hold the database, reads never hit the disk.
• PHP-FPM: In Magento a single PHP process can use hundreds of megabytes; set the process count by dividing available memory by per-process usage.
• Valkey and Varnish: Cache size grows from a few hundred megabytes to several gigabytes depending on catalogue and page count.

On the disk side, Magento’s generated, pub/static and var folders, product images and the database grow quickly together; because files are regenerated on every deployment, the high IOPS of NVMe storage directly shortens build times. Also plan extra resources for a staging environment with the same settings as the live store.

VPS, VDS or dedicated server for Magento?

The most balanced choice for Magento is a VDS: because the cores are dedicated to you, CPU-heavy work such as compilation, indexing and campaign traffic is not affected by neighbouring servers. A VPS with shared virtual cores can be enough for development and testing, but on a live store it can cause unpredictable slowdowns at peak hours.

As your store grows, you can first increase VDS resources, then scale horizontally by moving the database and OpenSearch to separate servers. If you want maximum power on a single machine, consider a dedicated server; a detailed comparison is on the VDS or dedicated server page. For small stores that do not want to manage a server, the lighter PrestaShop hosting is also an option.

How do you install Magento on a server?

Magento Open Source is downloaded with Composer from the official repository and installed with the bin/magento setup:install command. To access the Composer repository you need the access keys (public and private key) from your Adobe Commerce Marketplace account; these keys are written to Composer’s authentication file.

1. On Ubuntu 24.04 LTS, install Nginx, PHP-FPM with the required extensions, MariaDB or MySQL, OpenSearch and Valkey.
2. Create a separate system user and database for Magento; let the web server run in this user’s group.
3. Download the code: composer create-project --repository-url=REPO_URL magento/project-community-edition magento, replacing REPO_URL with Adobe’s official Composer repository (repo.magento.com) using the HTTPS scheme.
4. Run the install command with the database, domain, admin and OpenSearch details, plus the --language, --currency and --timezone options for your store (for a Turkish store, for example, tr_TR, TRY and Europe/Istanbul).
5. Set up the cron jobs with bin/magento cron:install.
6. Configure Nginx based on nginx.conf.sample and enable HTTPS with Let’s Encrypt.

At the end of installation, save the admin panel address shown on screen; Magento generates it randomly during installation. Two-factor authentication is enabled by default for admin login, so make sure the server can send email.

How do you put Magento into production mode and update it?

A live store should always run in production mode; in this mode code is compiled in advance, static files are pre-generated and error details are not shown to visitors. Developer mode generates files on every request and slows the store down noticeably.

After a deployment or module update, the typical command sequence is:

bin/magento maintenance:enable
composer install --no-dev
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy en_US tr_TR -f
bin/magento indexer:set-mode schedule
bin/magento cache:flush
bin/magento maintenance:disable

The setup:di:compile and setup:static-content:deploy steps can take minutes depending on store size and use every core; dedicated cores and fast disks are how you shorten the time spent in maintenance mode. A more advanced approach is to build in a separate environment (CI) and transfer the finished output to the server.

Adobe closes security vulnerabilities with patch releases named -p1, -p2 and so on. Do not delay these patches, but try them in a test environment first. Taking a server snapshot before major updates (see the backup section below) lets you roll back within minutes if something goes wrong.

How do you improve Magento performance?

The three cornerstones of Magento performance are full-page caching with Varnish, cache and session storage in Valkey, and a correctly tuned PHP OPcache. Without these three, even the most powerful server falls short at peak hours.

• Varnish: In the admin panel, set the caching application to Varnish under Stores → Configuration → Advanced → System → Full Page Cache and load the VCL file generated by Magento into Varnish. Nginx terminates HTTPS in front, and Varnish serves the cache behind it.
• Valkey: Use Valkey for the default cache, page cache and sessions with separate database numbers in app/etc/env.php; it greatly reduces disk access compared with file-based caching.
• OPcache: Adobe recommends high memory and file-count values for OPcache; in production, turn off file-change checks with opcache.validate_timestamps=0 and restart PHP-FPM on every deployment.
• Indexers: Switch all indexers to “Update by Schedule” mode; updates are processed in the background by cron.
• Images and CDN: Compress product images and serve static files through a CDN.

Third-party modules are the most frequent performance problem; measure page generation time before installing each module and compare it with the result afterwards.

How do you keep a Magento server secure?

Magento server security works on two layers: on the server layer, open only the necessary ports and close services to everything but the local network; on the application layer, apply security patches on time and protect the admin panel. A store that handles payment data is an attractive target; choosing a payment setup where card data never touches the server removes most of the risk.

1. Firewall: Open only ports 22, 80 and 443.
2. Services: OpenSearch, Valkey, RabbitMQ and the database should listen only on 127.0.0.1; leaving OpenSearch open to the internet leads to serious data leaks.
3. SSH: Use key-based login instead of passwords and set up Fail2ban against brute-force attempts.
4. Admin panel: Protect the unguessable admin address, keep two-factor authentication on and create personal admin accounts for each person.
5. File permissions: Set code files so the web server cannot write to them; only var, generated, pub/static and pub/media should be writable.
6. Patches: Follow Adobe security bulletins and do not hold back security updates from module developers.

At network level, the RouteFence firewall filters DDoS traffic; adding a WAF against application attacks provides extra protection.

How should Magento be backed up?

A Magento backup must cover the database dump, the product images in pub/media, the app/etc/env.php and app/etc/config.php configuration files, and your custom module and theme code. If any of these is missing, the restored store will not open or images will disappear. Magento’s old built-in backup commands have been deprecated, so plan backups with server tools.

• Database: Take a daily dump with mysqldump --single-transaction --quick without locking the store.
• Media: Sync the pub/media folder incrementally to another location with rsync.
• Code: Keep custom modules, the theme and composer.json / composer.lock in a Git repository; the vendor folder can be regenerated with Composer.
• Snapshot: Take a server snapshot before major updates; if something goes wrong, you can return the whole server to its previous state within minutes.

A snapshot does not replace a backup; it is stored on the same infrastructure and is not designed for long-term archiving. Keep database dumps and the media copy in a different location.

What are the most common problems on a Magento server?

The most common problems on Magento servers are a cron that is not running, OpenSearch connection errors, running out of memory during compilation, and file permissions after deployment. Error details are kept in the var/log and var/report folders.

• Indexes show “Reindex required”, emails are not sent: Cron is not running. Check the Magento lines with crontab -l and confirm the job runs without errors with bin/magento cron:run.
• “Could not validate a connection to OpenSearch” during installation: The OpenSearch service is not running or its heap is too small; check the service log.
• “Allowed memory size exhausted” during compilation: Raise the command-line PHP memory limit; if memory is tight, add swap space.
• CSS and JavaScript do not load (404): Static content has not been generated for that locale; run setup:static-content:deploy again with the locale code.
• “There has been an error processing your request”: Look up the report number shown on screen in the var/report folder.
• Permission errors after deployment: Do not run commands as root; run them as the user who owns the Magento files.

Most of these problems never appear when the right user, cron and memory plan are set up during the initial installation.

When should a Magento installation be split across several servers?

It is time to split a Magento installation across several servers when response times still rise during campaigns even after the single server’s resources have been increased, when the database and OpenSearch compete with PHP-FPM for memory, or when you need a redundant setup for uninterrupted operation. The natural order is to separate the services that consume the most resources and hold state.

1. Separate the database: Moving MySQL or MariaDB to a separate VDS leaves the web server’s memory to PHP-FPM.
2. Separate search and cache: Group OpenSearch and Valkey on a second server.
3. Multiply the web layer: Put two or more web servers behind a load balancer; because sessions are kept in Valkey, users do not lose their carts whichever server they land on.
4. Share media: Move the pub/media folder to shared or object storage.

Latency stays low when traffic between servers remains within the same data center. The 600 Gbit/s total upstream capacity of the LIONFIN infrastructure handles external traffic, while 24/7 NOC and SOC monitoring tracks network and security events. Learn more about our data center. When planning a multi-server architecture, you can open a support ticket from the customer panel for sizing help.