Magento Hosting in 2026: Server Requirements and How to Choose a Host

Good Magento hosting gives Magento 2 the software versions Adobe supports, enough CPU and memory for your traffic and catalogue, and the supporting services the platform depends on: a search engine, a cache, a full-page cache and a database tuned for its workload.

Shared hosting rarely meets these needs. Most growing stores run on a well-configured virtual or dedicated server, a managed Magento host, a cloud platform, or Adobe Commerce on cloud infrastructure for larger Adobe Commerce projects. The right choice depends less on brand names than on whether the host supports the current stack, can size the servers properly and will help when something goes wrong at the worst possible moment.

This guide replaces our older list of hosting providers, which dated quickly. Instead of naming companies, it explains what to look for, so you can judge any host on the same criteria.

Magento hosting requirements in 2026

Adobe publishes the supported software for each Magento Open Source and Adobe Commerce release on its system requirements page. At the time of writing, in October 2026, the on-premises requirements for the two newest release lines look like this.

Two changes stand out compared with a few years ago. Elasticsearch has given way to OpenSearch, and the latest patch releases list Valkey, an open-source fork of Redis, as the supported cache and session store. Requirements change with every release, so always check the page for your exact version rather than relying on a host's marketing page.

The services behind a Magento store

A Magento 2 store is not a single application on a single process. Several services work together, and a host needs to provide, configure and monitor all of them.

• PHP-FPM and nginx: run the application and serve requests that are not cached.
• MySQL or MariaDB: stores products, customers, orders and configuration.
• OpenSearch: powers catalogue search and layered navigation; Magento 2.4 cannot run without a search engine.
• Valkey or Redis: stores the application cache and customer sessions in memory.
• Varnish: serves full pages from cache, so most visitors never wait for PHP.
• RabbitMQ: handles message queues for asynchronous operations, increasingly important on busy stores.
• Cron: runs indexing, emails, price rules and many other scheduled jobs; when cron stops, stores slowly go wrong.

When comparing hosts, check that every one of these is available on the plan, at supported versions, and that someone is responsible for keeping each one running. Our article on Valkey, Redis and Varnish explains the caching layers in more depth.

Sizing CPU and memory

Adobe's hardware recommendations give a simple starting formula for the number of CPU cores web servers need to process requests without queuing.

Cores needed = (expected concurrent requests / 2) + expected cron processes

In other words, one core handles roughly two Magento requests at a time, plus capacity for background jobs. A store expecting 20 concurrent requests and running 4 cron processes would start from around 14 cores across its web nodes. Real needs depend heavily on caching: with a well-configured full-page cache, most visits never reach PHP at all. Stores with many logged-in customers, such as B2B portals, see fewer cache hits and need more CPU per visitor.

Memory

• PHP: Adobe recommends configuring PHP memory of around 2 GB for a single-server store, with more needed for some tasks such as compiling code and deploying static files.
• Database: for MySQL to use its indexes effectively, memory available to it should be at least close to half the size of the data it stores.
• Search and caches: OpenSearch, Valkey and Varnish each need their own memory, which grows with catalogue size and traffic.

These figures are starting points. Load testing before launch, and before every big sale, is the only reliable way to confirm a configuration. Our guide to speeding up a Magento store covers the tuning that makes hardware go further.

Types of Magento hosting

Many growing stores do well on a managed VPS or a small cluster, with the database, search and cache either on the same server or split onto separate ones as traffic grows.

The best choice often changes as a store grows. Starting on a single well-tuned server and moving the database and search to their own machines later is a common, sensible path. What matters is choosing a host that can support that growth without forcing a complete move, and documenting the set-up so any competent developer can understand it.

Choosing a Magento hosting provider

Price per month is the least useful comparison. Two plans with the same price can differ hugely in software versions, support and the work you still have to do yourself. Ask every shortlisted host the same questions.

1. Which PHP, database, OpenSearch, Valkey and Varnish versions do you support, and how quickly do you add new ones?
2. Is Varnish included and configured, or only available as an add-on?
3. Where are the servers? Choose a region close to your customers, or use a CDN.
4. How do backups work? Frequency, retention, off-site copies and how fast a restore can be done.
5. Is there a staging environment that mirrors production?
6. What monitoring and alerting is included?
7. What are the support hours and response times, and do support staff know Magento?
8. How do you handle traffic peaks, and what does extra capacity cost?
9. Who applies operating system and security updates?

Our e-commerce hosting guide covers these questions for stores on any platform. A content delivery network in front of the store also reduces the load on your servers by serving images, scripts and styles from locations close to your customers.

Security and maintenance

Hosting is only as secure as the way it is maintained. A fast server running an unpatched operating system or an old PHP version is a liability.

• Apply operating system and service updates on a regular schedule.
• Run supported PHP and database versions, and plan upgrades well before support ends.
• Restrict SSH and admin access, use keys rather than passwords and enable two-factor authentication for the Magento admin.
• Keep backups off the server and test restoring them at least every few months.
• Apply Magento security patches promptly, always tested on staging first.

Our backup and disaster recovery guide explains how to plan restores, and our Magento security patch guide covers the patch cycle.

Planning for traffic peaks

Most stores are sized for normal days and struggle on the few days that matter most: seasonal sales, product launches and campaign emails. Planning capacity for those peaks is part of choosing a host.

• Know your peak: look at last year's busiest hour, not the daily average.
• Load test in advance with realistic journeys, including search, basket and checkout, which cannot be fully cached.
• Agree temporary capacity with your host, such as extra web nodes or a larger server for the sale period.
• Warm the caches before a campaign goes live, so the first visitors do not all hit PHP at once.
• Freeze risky changes in the days before a big event.

Our guide to preparing for peak traffic covers the full checklist for sale days.

Migrating to a new host

Moving a Magento store between hosts is a project in its own right. Plan it like a launch.

1. Build the new environment with the required software versions and test it with a copy of the store.
2. Run a load test against the new servers before switching.
3. Lower DNS time-to-live values a few days before the move, so the switch spreads quickly.
4. Freeze admin changes, take a final database copy and switch DNS during a quiet period.
5. Check orders, payments, emails, search, cron jobs and caches immediately after the switch.

Keep the old server available for a short period in case you need to roll back. Once the new host has run smoothly through at least one busy week, cancel the old plan and remove any credentials it held.

Frequently asked questions

Planning a new Magento server or a move to a better host? Talk to our team about sizing, set-up and migration, or see our Magento development services.