What Magento hosting needs in production
Magento and Adobe Commerce performance depends on how the complete application stack is designed and operated. CPU and memory are only the beginning of the decision.
- Author
- Intercube
- Revised
- Reading time
- 10 min read
01
Start with the workload, not a standard package
Two Magento stores can require very different infrastructure. Catalogue size, active integrations, indexing behaviour, scheduled work, administrative activity, checkout traffic and promotional peaks all influence the design. A package selected only from monthly visitors or storage usage can miss the processes that create the real load.
A useful assessment combines application architecture with observed production behaviour. It should identify the web tier, PHP workload, database characteristics, search, cache layers, queues, cron groups, media, external integrations and deployment pattern. That provides a defensible basis for capacity and service choices.
02
Treat the supporting services as one system
Magento commonly relies on several services that affect one another. PHP workers can saturate while the database appears healthy. Search indexing can compete with customer traffic. Cache configuration can improve response time or conceal invalidation problems. Message queues and cron jobs can build backlogs that are not obvious from the storefront alone.
The hosting design should define how these services are separated, monitored and tuned. Versions and topology must match the application and its extensions. The right answer is not always more servers; it is often better workload separation, predictable configuration and a clear view of bottlenecks.
- PHP runtime and worker capacity aligned with the request profile.
- Database configuration based on data volume and query behaviour.
- Search, queues, caching and scheduled work treated as production dependencies.
- Operational visibility that distinguishes application symptoms from infrastructure causes.
03
Make releases repeatable
A Magento release can involve dependency installation, asset compilation, configuration changes, database operations, cache invalidation and background consumers. Manual server commands make the outcome depend on timing and individual memory. That risk increases when several developers or an external agency share delivery responsibility.
An automated deployment pipeline should make the build and release stages visible, keep environment-specific configuration outside the repository, and retain logs when a step fails. The exact sequence depends on the application. The important property is that the process is reviewed, repeatable and understood by both the application team and the hosting operator.
04
Plan for commerce operations, not just uptime
Availability matters, but a store can be technically online while checkout, indexing, imports or administration are degraded. Monitoring and incident response need enough application context to recognise those failure modes. Backup and recovery planning should also cover the relationship between files, media and transactional data, not only whether snapshots exist.
Before migration or a major campaign, agree how traffic assumptions will be tested, how changes will be frozen or rehearsed, who can approve a release and how the team will communicate during an incident. Those operating decisions protect revenue more effectively than a long list of infrastructure features.
Magento hosting review checklist
- Map catalogue, checkout, indexing, import, cron and integration workloads.
- Review PHP, database, search, caching, queues and media as one architecture.
- Document the build and release sequence, including failure handling.
- Define monitoring around commerce-critical processes, not server health alone.
- Test migration, recovery and peak-traffic assumptions before the critical date.