About us ?
a
M

Follow us

Home > All Our Magento & E-commerce Articles > Magento 2: Best infrastructure practices not to be overlooked

Magento 2: Best infrastructure practices not to be overlooked

Hosting a Magento 2 system may seem simple. But there’s a huge gap between best practices and bad ideas. Here’s a technical and pragmatic guide to laying a clean and stable infrastructure foundation.

🌐 Web Server: Why Nginx is Better Than Apache

Nginx is based on an asynchronous event-driven architecture, whereas Apache still largely operates according to a multi-process model (prefork, worker, event MPM).
Nginx handles thousands of simultaneous connections without duplicating its processes. This is much more efficient for static resources, and therefore perfectly suited to Magento, which sends a lot of CSS, JS, images, etc.

On the configuration side, Nginx is more readable, the directives are more predictable, and the block-based configuration system (location, server) is more modular than Apache’s sometimes messy .htaccess files.

Another important point: reverse proxy support is native and very robust in Nginx—perfect when running Magento behind Varnish or Traefik.

🐘 PHP-FPM: the PHP engine you need

PHP-FPM (FastCGI Process Manager) is now the standard for running Magento 2. Unlike PHP in Apache mod_php mode, FPM allows:

  • Process isolation: a crash or memory leak on one process does not impact the entire instance.
  • Better scalability: the server can dynamically adjust PHP processes according to load.
  • Fine-tuned configuration of memory and CPU consumption.

But be careful: there is no universal configuration. Settings such as:

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

must be adjusted according to:

  • server specs (available RAM, number of cores)
  • of the project (traffic, SQL load, business complexity)
  • of its evolution (a better optimized site consumes less, so these values ​​can be revised downwards)

👉 Tip: Regularly monitor your FPM pool via pm.status_path, slowlog logs, or tools like Grafana + Prometheus.
However, the following settings are generally valid for all Magento 2 servers:

pm = dynamic
pm.max_requests = 500
request_terminate_timeout = 60s
  • pm = dynamic : allows PHP-FPM to dynamically adjust the number of processes depending on the load. This is the recommended mode, more flexible than static or ondemand.
  • pm.max_requests = 500 : Each FPM worker is restarted after processing 500 requests. This helps prevent memory leaks or other usage drifts over time.
  • request_terminate_timeout = 60s : Sets a maximum execution time for each PHP request. If exceeded, the process is killed. A valuable safeguard against blocking calls.

⏰ Crons: neither on the fronts, nor blindly

The advice is simple: never run your crons on your front-end servers.

  • Crons must live on a dedicated server, or at least on the back-office server.
  • Also, make sure that only one instance is running them. Otherwise, you’ll end up with duplicate commands, concurrent processing, and subtle bugs.

🔄 NFS mounts: yes, but not just any old way

In a multi-server (clustered) Magento architecture, it is often necessary to share certain directories.

But be careful: not all montages are equal.

✅ To assemble :

  • pub/media → essential: this is where product images, catalogs, etc. reside.
  • possibly var/log → useful for centralizing Magento logs if you don’t yet have an ELK stack

❌ Do not go up :

  • the entire  magento/ folder (vendor, generated, pub/static, etc.)

Why?
Magento contains tens of thousands of files. The smallest bin/magento setup:di:compile or setup:static-content:deploy triggers I/O storms. With a network mount (NFS, EFS, other), this becomes a critical bottleneck. Result:

  • slowdowns
  • broken deployments
  • random 500 errors
  • or even file corruption

📌 Please note :

  • NFS is common on self-managed or dedicated hosting
  • EFS (Elastic File System) is the equivalent at AWS, often used in Magento architectures on Kubernetes or EC2
  • For other cloud platforms: Azure Files, Google Filestore, etc.

👉 Only share what is strictly necessary. And for the rest, favor fast local volumes (SSD) and a good deployment system (see next article 😉).

Centralize and monitor your logs with ELK

On Magento, we log a lot: errors, business events, SQL slowness, uncaught exceptions…
Reading all of this over SSH, file by file? It’s outdated.

👉 Set up a stack ELK :

  • Elasticsearch : real-time search engine, capable of indexing millions of log lines.
  • Logstash : ingestion pipeline, which aggregates, filters and transforms your logs.
  • Kibana : graphical dashboard, to analyze and cross-reference information at a glance.

The benefits are immense:

  • All Magento (and server) logs in a single interface
  • Instant search on a specific client ID, URL, error
  • Visualization of error peaks, recurring slowness, or isolated incidents
  • Save time for the dev and ops team (and less stress for everyone)

You can also connect an alerting system (e.g. via ElastAlert or Grafana) to be notified in real time of certain types of critical errors.

🚀 Deployment: never live

A bin/magento deploy:fail in production, does that sound good? No?

So we never deploy to the current instance. We use versioned folders (/releases/20240605) (/releases/20240605) and switch cleanly.

Another article will detail Magento deployment methods (with or without CI/CD pipeline).

🧵 RabbitMQ: No cron for queues

Magento uses RabbitMQ to handle asynchronous operations. And no, crons don’t have to do this job:

  • Crons are already overloaded
  • Queues must be consumed quickly, almost in real time

👉 We therefore use a supervisor (or systemd) that automatically launches and restarts queue:consumers:start.
It’s stable, isolated, and efficient. In addition, it allows for automatic monitoring and restart in the event of a crash.

🧩 In summary

Putting Magento 2 into production is not just about launching a composer install.
It’s about thinking about architecture, stability, performance.

Some reminders:

  • Nginx + PHP-FPM, winning combo
  • Well insulated crons
  • Well thought out NFS
  • Versioned deployments
  • And a monitored RabbitMQ

🧠 Infrastructure is like a solid backend: if it’s done well, you don’t think about it anymore.

👉 To learn more about cache performance, don’t miss our article on Redis in Magento 2, where we explain how it optimizes caching and session management.