Article
Adobe Commerce hosting: managed cloud, Commerce on Cloud and self-managed — how to choose
Adobe Commerce hosting: the three options —Commerce on Cloud, self-managed on AWS, managed hosting with a partner—, what good managed includes, how to choose.

On this page
- What is Adobe Commerce hosting and why does it matter?
- What are the hosting options for Adobe Commerce?
- 1. Adobe Commerce on Cloud (the official PaaS)
- 2. Self-managed (on-premise or your own AWS cloud)
- 3. Managed hosting through a partner
- What does serious managed hosting for Adobe Commerce include?
- How do you choose between the three options?
- Common Adobe Commerce hosting mistakes
- How we help
- Related services
The hosting question almost always arrives late. In the discoveries we run with new brands, the team has chosen the platform, defined the catalog and designed the checkout — but infrastructure was left as a last-minute detail, settled by default or by price. It's exactly backwards: in Adobe Commerce (formerly Magento), hosting is part of the architecture. It defines the performance the customer experiences, the scope of PCI DSS (Payment Card Industry Data Security Standard) compliance, the ability to survive a peak sales event without going down, and a large share of the total cost of ownership over the next three years.
At WolfSellers we run Adobe Commerce stores across all three possible hosting routes, and the right decision isn't the same for everyone. This article explains what Adobe Commerce hosting is and why it matters, what the three real options are, what serious managed hosting must include, how to decide based on your size and team, and the mistakes we see repeat across Mexico and LATAM.
What is Adobe Commerce hosting and why does it matter?
Adobe Commerce hosting is the set of infrastructure and managed services that keeps your store running: the PHP application servers, the database, the search engine (OpenSearch/Elasticsearch), the caching layer (Varnish/Redis), the content delivery network or CDN, and the operations that monitor, scale, patch and back all of it up.
Unlike a static marketing site, Adobe Commerce is a heavy, stateful application: every product page can fire dozens of queries, the checkout writes to the database in real time, and indexers continuously rebuild catalog and pricing. That's why hosting isn't an interchangeable commodity. It matters for four concrete reasons:
- Performance. Core Web Vitals — LCP, CLS, INP — depend directly on server latency, Varnish/Fastly configuration and edge caching. Undersized hosting means slow PDPs and abandoned carts, no matter how good the frontend is.
- PCI DSS compliance. If you process cards, the hosting environment is part of the audit scope. OS hardening, network segmentation, patch management and logging are requirements, not options.
- Scale. eCommerce traffic in Mexico isn't flat: peak sales events such as Buen Fin, Hot Sale and the holiday season multiply load. According to the Mexican Online Sales Association (AMVO), Hot Sale concentrates peaks that comfortably exceed normal daily traffic. Infrastructure has to scale for those events without over-provisioning the rest of the year.
- Continuity. Backups, disaster recovery (DR) and an explicit service-level agreement (SLA) are what separate an outage measured in minutes from one measured in days.
What are the hosting options for Adobe Commerce?
There are three main routes. None is better or worse in the abstract — each fits a different profile of company, team and compliance.
1. Adobe Commerce on Cloud (the official PaaS)
Adobe Commerce on Cloud is Adobe's official platform as a service (PaaS): managed infrastructure on AWS (Amazon Web Services), with Fastly as the CDN and Web Application Firewall (WAF) layer, New Relic for application and infrastructure monitoring, and a Git-based deploy pipeline with integration, staging and production environments. It comes in two tiers — Pro and Starter — and the model is an annual subscription that bundles license and infrastructure together.
The advantage is that Adobe takes responsibility for the base platform: the client doesn't administer the servers directly. The trade-off is less low-level control over the operating system and topology, plus a cost model that requires sizing the tier well from the start. It's the route Adobe recommends by default and the one that integrates best with the rest of Adobe Experience Cloud.
2. Self-managed (on-premise or your own AWS cloud)
Here the brand licenses Adobe Commerce (in the edition that allows self-hosting) and operates the infrastructure itself — typically in its own AWS account, sometimes on another cloud provider, rarely on-premise today. The company's team, or a partner, designs the architecture: load balancers, autoscaling, RDS or Aurora for the database, ElastiCache for Redis, managed OpenSearch, CloudFront or Fastly as the CDN.
It gives maximum control and lets you optimize infrastructure cost in detail (reserved instances, savings plans, bespoke architectures). The price is full operational responsibility: you patch, you scale, you answer at 3am when the indexer locks the admin during a peak sale. It only makes sense with a mature DevOps team or a dedicated operations partner.
3. Managed hosting through a partner
A middle path: the infrastructure lives on a cloud (AWS, almost always) but it's designed and operated by a partner specialized in Adobe Commerce, not the brand. The partner brings the reference architecture, monitoring, scaling, security patching, compliance and the SLA — while the client keeps visibility and, depending on the model, co-ownership of the cloud account.
It combines the control of self-managed with the operational peace of mind of the PaaS. It's the option we most often recommend at WolfSellers for mid-market and large companies in Mexico that don't want to build an Adobe-specific internal DevOps team but do want cost transparency and architecture.
What does serious managed hosting for Adobe Commerce include?
"Managed hosting" is used for very different things. A generic host that just gives you a server with SSH access is not managed hosting for Adobe Commerce. Here's what we evaluate — and deliver — as part of a serious operation:
| Component | What it must include | Why it matters |
|---|---|---|
| Infrastructure | Multi-AZ architecture on AWS, application-server autoscaling, managed database (RDS/Aurora) | High availability and elasticity for peaks like Buen Fin/Hot Sale |
| CDN + edge | Fastly or CloudFront with well-configured Varnish, WAF at the edge | Core Web Vitals, DDoS protection and origin offload |
| Monitoring | New Relic (APM + infra), proactive alerts, business dashboards | Detect degradation before the customer sees it |
| Scaling | Capacity plan for events, autoscaling proven with load testing | Survive campaigns without over-provisioning all year |
| Security patching | Adobe and OS security patches applied in controlled windows | Unpatched CVEs are the #1 compromise vector in Magento |
| PCI DSS compliance | Hardening, segmentation, log management, audit support | Required if you process cards |
| Backups + DR | Automated backups, defined retention, agreed and tested RPO/RTO | The difference between minutes and days of downtime |
| SLA | Contractually committed availability, response and escalation times | Clear accountability when something fails |
If a hosting proposal doesn't explicitly cover backups with a tested recovery point objective (RPO) and recovery time objective (RTO), application monitoring and a written SLA, it isn't enterprise-grade managed hosting — it's hosting under another name.
How do you choose between the three options?
The decision intersects three variables: the size and criticality of the operation, the maturity of the internal technical team, and compliance requirements. This table summarizes when each route is the right fit:
| Criterion | Commerce on Cloud | Self-managed (own AWS) | Managed with partner |
|---|---|---|---|
| Infrastructure control | Medium | Full | High |
| Operational load on your team | Low | High | Low |
| Internal DevOps required | Minimal | Mature and dedicated | Minimal |
| Infra cost flexibility | Low (fixed tier) | High | High |
| Adobe Experience Cloud integration | Native | Manual | High |
| Best for | Those who want Adobe to run the base | Mature cloud teams optimizing in detail | Mid-market/enterprise without internal Adobe DevOps |
The questions we ask in a discovery to tip the decision:
- Do you have a DevOps team with specific Adobe Commerce experience? If not, pure self-managed is a risk: Magento's operational knowledge (indexers, cron, Varnish, deploy mode) is non-trivial.
- How critical is infrastructure cost control? If fine-grained elasticity and savings plans matter a lot, self-managed or managed-with-partner win over the PaaS's fixed tier.
- What's your traffic profile? Extreme, seasonal peaks reward architectures with proven autoscaling; stable traffic tolerates simpler setups.
- What does your compliance demand? PCI DSS, Mexico's Federal Law on Protection of Personal Data (LFPDPPP) and ISO 27001 are easier to evidence with a managed, auditable operation.
- Will you adopt more of Adobe Experience Cloud? If the roadmap includes Adobe Experience Manager or Adobe Experience Platform, Commerce on Cloud's native integration carries weight.
There's no universal answer. A Mexican mid-market brand without its own cloud team is usually better off with managed hosting (PaaS or partner); a company with mature DevOps already living in AWS can extract more value from self-managed.
Common Adobe Commerce hosting mistakes
Patterns we see repeat — and that cost dearly — in Adobe Commerce and Magento projects across Mexico and LATAM:
- Choosing hosting by monthly price, not total cost. Cheap hosting with no monitoring, no SLA and no proven scaling becomes more expensive the first time the store goes down in the middle of a peak sale.
- Undersizing for peaks. Configuring infrastructure for average traffic and discovering during Hot Sale that it doesn't scale. Autoscaling has to be proven with load testing before the event, not improvised during it.
- Confusing generic hosting with managed hosting for Adobe Commerce. A VPS with SSH doesn't manage indexers, deploy mode, Varnish or Adobe's security patches. Magento has specific operational needs.
- Not testing backups. Backups you've never restored are no backups at all. RPO and RTO are agreed and tested.
- Treating PCI DSS as a checkout concern. Compliance scope includes the infrastructure: hardening, network segmentation and log management are part of hosting, not just the payment gateway.
- Skipping security patches. Unpatched vulnerabilities are the most common compromise vector in Magento stores. Patch cadence is part of the service, not an extra.
- Having no observability. Without APM (Application Performance Monitoring) or alerts, the first person to detect degradation is the customer abandoning the cart.
Most of these aren't hard technical problems — they're decisions made without understanding that in Adobe Commerce, infrastructure is part of the product.
How we help
At WolfSellers we are an Adobe Gold Partner with more than 10 years in LATAM, 40 specialists certified in Adobe Commerce and 3 AWS Solutions Architect Associates on the team. We run Adobe Commerce stores across all three routes: Adobe Commerce Cloud (the official PaaS), optimized AWS hosting and cloud managed by us, and bespoke cloud infrastructure architectures with monitoring, scaling, patching and PCI DSS compliance. If you're choosing between Commerce on Cloud, self-managed or managed hosting — or if your current store suffers from performance issues or outages — we can run an infrastructure discovery and propose the right route for your size and your team. Let's talk.
Related services
If this topic is relevant to your business, these WolfSellers services can help you implement it:


