An e-commerce director migrates Magento 2 shop to the same VPS as the old WordPress site "that worked fine." Blocked indexing, twelve-second checkout, late cron. Not "badly optimized Magento": Magento on a stack built for a light CMS. Magento is not heavy WordPress. It is a commerce platform with indexers, multi-layer cache, and execution modes that punish approximation.
Magento architecture: what actually consumes resources
| Component | Role | Without it |
|---|---|---|
| Indexers | Price, stock, catalog search | Stale data, slow admin |
| Redis | Sessions, backend cache | File sessions, disk I/O |
| Varnish / FPC | Catalog pages | PHP render every hit |
| Elasticsearch | Catalog search | Unbearable LIKE queries |
| Cron / consumers | Async queues | Blocked emails, indexes |
| Production mode | Compiled code, warm caches | Developer mode = disaster |
Magento in developer mode in production is parking a truck on a hill without engine.
Size hosting without marketing
Small B2C shop. 8 GB server, Redis, full-page cache, recent PHP, reliable cron.
Medium catalog plus promos. 16 GB, dedicated or managed Elasticsearch, separate admin and frontend if possible.
Adobe Commerce / enterprise. Adobe Cloud, cluster or bare metal with 24/7 operations.
Compare via directory filtering PHP long-running and Redis compatible offers.
Signs of Magento-ready host
Documented PHP OPcache and required extensions. Managed or installable Redis. Minute cron or queue workers. Available or low-latency Elasticsearch. Full staging clone. Support knowing stuck indexer and compilation.
Generic "PHP host" leaves you alone on blocked reindex Sunday — budget integrator time or choose a commerce-aware vendor.
Staging must mirror production modules, media volume and cache configuration — a lighter staging stack hides checkout failures until go-live.
Classic migration mistakes
Copy config without adapting Redis/Elasticsearch. Forget generated directory permissions. Large media without CDN. Custom modules incompatible PHP 8. Test performance in developer mode.
The peak: Magento needs a stack
If you need a simple shop, well-operated PrestaShop or WooCommerce may suffice — see PrestaShop heavy catalog.
Decide and move forward without blind spots
Switch to production mode with warm caches before go-live. Verify indexers and cron under simulated load. Configure Redis and full-page cache minimum. Size RAM by product catalog size and modules. Plan staging identical to production. Use comparator to cross-check hosts and e-commerce use cases.
Frequently asked questions
Minimum config for Magento Open Source?
Four to eight gigabytes for a small optimized shop, sixteen or more for a medium catalog with full cache. Never run developer mode in production — performance collapses.
Are Redis and Varnish mandatory?
Redis is near standard for sessions and backend cache. Full-page cache is strongly recommended for any non-trivial storefront traffic.
Can Magento run on shared hosting?
Not for a serious shop — you need high-end VPS or dedicated cloud with guaranteed resources and cron control.
Is Magento Cloud worth the premium?
Yes if preconfigured stack and Adobe SLA; compare TCO vs internal operations.
Magento does not ask for "a bit more RAM." It asks for a stack built for it — or an incident invoice to remind you.