Adobe Commerce Cloud Development Company: PaaS, SaaS and Skills

An Adobe Commerce cloud development company builds, deploys and supports stores on one of Adobe's cloud models. The first is Adobe Commerce on cloud infrastructure, a platform as a service (PaaS). The second is Adobe Commerce as a Cloud Service, a software as a service (SaaS). PaaS work centers on environments, the ece-tools package, Fastly, New Relic and owning your upgrades. SaaS work centers on out-of-process extensions and an Edge Delivery Services storefront. This guide compares the models, explains cloud delivery and lists what to check before you hire.

What are Adobe Commerce's deployment models?

Adobe Commerce comes in three deployment models: Adobe Commerce as a Cloud Service (SaaS), Adobe Commerce on cloud infrastructure (PaaS) and Adobe Commerce on-premises. Adobe's own comparison notes that the on-premises model "shares similar capabilities with the PaaS model". So the real split is between the SaaS model and the other two.

Area	On cloud infrastructure (PaaS)	As a Cloud Service (SaaS)	On-premises
Hosting	Single-tenant, run by Adobe	Multi-tenant, run by Adobe	Your servers or your cloud
Updates	You upgrade and patch	Adobe upgrades automatically	You upgrade and patch
Custom code	PHP modules plus App Builder	Out-of-process only	PHP modules plus App Builder
Content delivery	Fastly included	Adobe-managed CDN or your own	Your choice
Monitoring	New Relic access	Managed by Adobe	Your tools
Storefront	Themes or headless	Commerce Storefront on Edge Delivery Services	Themes or headless

The table draws on Adobe's feature comparison for the first two columns. The on-premises column follows from Adobe's note that it works like PaaS, with the hosting left to you.

Adobe also offers Adobe Commerce Optimizer, which Adobe describes as a route for "modernizing only the storefront layer" while keeping an existing backend. For a fuller tour of what each package includes, see our overview of Adobe Commerce solutions.

How is Adobe Commerce on cloud infrastructure set up?

Adobe Commerce on cloud infrastructure comes in two plans, Starter and Pro. Both run your code from a Git repository across several environments. The difference is in how production is built and how much it can scale.

Starter. Adobe says the Starter architecture "supports up to four environments": a master branch that serves production, a staging environment and up to two integration environments. All of them run in shared platform containers.

Pro. Pro adds dedicated hardware for staging and production. Development happens in integration, with up to two active branches. Staging and production run on dedicated infrastructure. Adobe says production has "three virtual machines (VMs) behind an Elastic Load Balancer", and all three accept reads and writes. Each Pro project is replicated across three availability zones on Amazon Web Services (AWS) or Microsoft Azure.

A few details matter for planning. Fastly and New Relic aren't available in Pro integration environments, so you can't fully test caching or monitoring there. Staging is the first place you see the full stack. Adobe lists the B2B module as an included feature of Pro, and as an add-on "available for an additional fee". On both plans, Adobe provides "24x7 monitoring and email support for the core application and the cloud infrastructure".

What does cloud development on Adobe Commerce involve?

Cloud development on the PaaS model is Git-driven. Every push to a cloud environment triggers a build and a deployment. The skills that matter are environment management, deployment tooling, caching and monitoring.

Branches and environments

Code moves in one direction. Adobe's Pro workflow says to push changes from integration to staging, test there, then merge to production. A good team keeps that path strict. Hotfixes still go through staging, even when the pressure is on.

Build and deploy with ece-tools

Adobe describes ece-tools as "a set of scripts and tools designed to manage and deploy the Commerce application". It runs the build, deploy and post-deploy stages through hooks in the project's .magento.app.yaml file. It also helps with cron jobs, configuration checks and applying Adobe patches.

Two facts shape how a cloud team works. First, after the build, the file system is read-only except for a few mounted folders, such as pub/media and var. Code that writes files in other places breaks on cloud. Second, the deploy phase "places a temporary hold on incoming requests" and puts the site into maintenance mode. A skilled team keeps that window short and schedules production deploys for quiet hours.

Fastly caching and security

Fastly sits in front of production, and of staging on Pro. Adobe lists four roles for it. There's a content delivery network (CDN) that caches pages and assets, a managed web application firewall (WAF), distributed denial of service (DDoS) protection and image optimization. The WAF is available on production only. Adobe notes the built-in DDoS protection covers common layer 3 and 4 attacks, not layer 7. So a cloud development company should know how to tune caching, purge it safely and handle bot traffic at the application layer.

Monitoring with New Relic

New Relic application performance monitoring (APM) is included on all cloud projects. Pro projects also include New Relic infrastructure monitoring and log management. A good cloud team sets up alerts before launch, not after the first outage.

Local development

The ece-tools package also includes a Docker configuration generator. That lets developers run a cloud-like setup on their own machines. Teams that only ever test on shared cloud environments tend to queue behind each other and find problems late.

How are upgrades and patches handled on Adobe Commerce cloud?

On the PaaS model, you own upgrades and patching, usually through your development company. On the SaaS model, Adobe upgrades the platform for you. That single difference changes the size and shape of your support contract.

For PaaS, Adobe's feature comparison says updates require "manual upgrade and patching", with six patch releases and one minor release per year. Adobe's shared responsibility model puts patching of your custom code and extensions on you as well.

Version support has dates attached. Adobe's lifecycle policy gives each version a three-year standard support window from release. Adobe Commerce 2.4.9 reached general availability on May 12, 2026, with standard support listed until May 31, 2029. Standard support for 2.4.6 ended on August 11, 2026, with extended support listed to August 31, 2027.

A proper upgrade follows Adobe's documented steps. The team updates the ece-tools package using version constraints and then updates dependencies. It checks that every third-party extension supports the new version and reviews any applied patches. Adobe's guidance is to "validate the upgrade in a Staging or Integration environment before scheduling it in Production". For individual fixes between releases, Adobe's Quality Patches Tool lets teams apply, revert and review patches.

Security patches are the urgent part. Recent attacks on unpatched stores show why speed matters. Our briefing on Adobe Commerce mass exploitation and what stores should do covers the response steps.

On SaaS, the work changes. Adobe says security patches are "automatically applied for you". When Adobe ships new features, "You have a 30-day period to evaluate the new capabilities in your sandbox instances". Your partner's job becomes testing your extensions and storefront in that window.

What changes on Adobe Commerce as a Cloud Service?

On Adobe Commerce as a Cloud Service, you can't change the core application. All custom work runs out of process, through application programming interfaces (APIs), events and Adobe's App Builder. That calls for a different skill set from classic PHP module work.

Adobe's feature comparison spells out the differences:

• Extensibility. "Out-of-process only (APIs, events, App Builder)". The listed technologies include JavaScript and Node, but not PHP.
• APIs. Custom APIs run through API Mesh, which combines several API sources into one endpoint.
• Data model. Custom attributes for core and B2B entities, rather than full data model changes.
• Search. Custom search indexing needs a third-party product.
• Storefront. Adobe's Commerce Storefront runs on Edge Delivery Services, and Luma storefronts aren't supported.
• Compliance. HIPAA, the US health data law, is "currently not available" on SaaS, while it's listed for PaaS.
• B2B. Core B2B features come pre-installed.

This has a direct effect on who you hire. A team that spent years writing PHP modules for PaaS stores may be excellent, but SaaS work leans on JavaScript, Node, App Builder and API Mesh instead. Ask a company how many of its developers have shipped App Builder apps to production, not just finished a tutorial. Ask how it handles state and data for those apps, since Adobe lists the App Builder state library as the custom storage option on SaaS.

Instances are provisioned through Commerce Cloud Manager, which Adobe says can launch "sandbox and production instances in minutes". For more on the storefront side, read our guide to Adobe Commerce on Edge Delivery Services.

Should you stay on PaaS, move to SaaS or run on-premises?

Choose SaaS if you want Adobe to own upgrades and your customizations can live outside the core. Stay on PaaS if you depend on deep PHP customization or need compliance options SaaS doesn't list yet. Run on-premises only if you have strong reasons to host it yourself, and the team to do it.

On-premises also loses some Adobe tooling. Adobe's Site-Wide Analysis Tool gives merchants performance and security recommendations, but Adobe decommissioned it for on-premises customers from April 23, 2024. So an on-premises team has to build its own equivalent from monitoring and audits.

Ask these questions to decide:

• How much custom PHP do you run? Heavy core customization means a large rebuild before SaaS works for you.
• Who should own upgrades? If your team keeps falling behind on patches, a versionless model removes that burden.
• What are your compliance needs? Check them against Adobe's current comparison table.
• What's your storefront plan? SaaS assumes an Edge Delivery Services storefront.
• Do you need full control of hosting? On-premises gives it, along with every security and scaling job.

If you plan to move, Adobe is clear that it's a project. Its migration guide says moving to the SaaS model "is more than moving data". It describes four phases: assess, modernize the application and migrate data, modernize the storefront, then cut over and operate. Adobe's Data Migration Service moves core data such as catalogs, orders and customers, but not custom or third-party entities. Those need their own plan.

What should an Adobe Commerce cloud development company be able to show you?

A capable Adobe Commerce cloud development company can show working evidence for each part of cloud delivery, not just say it's covered. Ask to see real artifacts, with client details removed.

Capability	Evidence to ask for
Environment management	A branching and release plan across integration, staging and production
Deployments	A deployment runbook with the typical maintenance window
Fastly	How they configure caching, purges and the WAF
Monitoring	New Relic dashboards and alert rules they set up
Upgrades	A recent version upgrade plan with extension checks
Patching	How quickly they applied the last security patch, with dates
SaaS skills	An App Builder app or API Mesh setup they built
Storefront	Edge Delivery Services or headless work with performance numbers
Incident handling	Escalation path and how they work with Adobe support

If a company can't show most of this, it may be strong at building stores but new to running them on cloud. Score each company's evidence on the same scale, and line up your finalists in our comparison tool.

What questions should you ask before you hire?

The best questions are ones a team running cloud projects every week answers without hesitation. Ask the engineer who'll own your environments, as well as the account lead.

• Which plan and deployment model are most of your current clients on: Starter, Pro or Cloud Service?
• How long is the maintenance window on a typical production deploy, and how do you shorten it?
• What's your process for a critical security patch, from release to production?
• How do you test caching and monitoring when integration environments don't include Fastly or New Relic?
• What was the last major version upgrade you ran, and what broke?
• Have you built App Builder apps or API Mesh setups for Adobe Commerce as a Cloud Service?
• Who raises and manages tickets with Adobe support when the core platform is at fault?
• What do you hand over if we move to another provider?

Listen for dates, version numbers and specific tools. "We follow best practice" isn't an answer. For broader questions on contracts and engagement models, our guide to hiring an Adobe Commerce agency covers the commercial side.

What to do next

Here's a short checklist for choosing an Adobe Commerce cloud development company:

• Confirm your current deployment model and plan, and if a move to SaaS is on the table.
• List your custom modules and extensions, so you know how much would need rebuilding out of process.
• Check your current version against Adobe's support dates.
• Ask each shortlisted company for the evidence in the table above.
• Run a short paid audit of your cloud setup before a long support contract.

Start with our Adobe Commerce partner finder, and send each firm the Adobe Commerce request for proposal (RFP) template so their cloud answers line up.