Adobe Commerce & Magento Staging: The Complete Guide for...

Adobe Commerce and Magento give you more control than any hosted platform, and hand you every operational problem that comes with it. Staging is the clearest example. What you get depends entirely on which edition you run, and none of the three answers is a full staging environment on demand.

This guide covers what each edition actually gives you, where each one stops, what it costs to build the missing piece yourself, and how to get environments on demand instead.

Does Adobe Commerce have a staging environment?

Short answer: on Adobe Commerce Cloud, yes. On Adobe Commerce on-premise, no. On Magento Open Source, no. The three cases are different enough to be worth separating.

Adobe Commerce Cloud

Cloud ships Integration, Staging and Production environments. Staging is genuinely near-production, carrying its own database, web server, caching and the third-party services that matter, including Fastly and New Relic. The constraint is quantity, not quality: Adobe's own documentation specifies one branch each for Staging and Production, so a single staging slot serves every workstream on that project.

Adobe Commerce on-premise

You get Content Staging, which schedules content, pricing and CMS changes with a preview. You do not get a managed environment. The next section covers exactly where that line falls, because the naming causes more confusion than anything else on this platform.

Magento Open Source

Neither. Content Staging is an Adobe Commerce exclusive and was never part of Open Source, so every environment is one you build and maintain yourself, then keep in step with production forever. This is where the gap is widest.

What Adobe Commerce Content Staging Actually Does

Content Staging is a feature available in Adobe Commerce (the paid, enterprise version). It is not available in Magento Open Source.

How Content Staging Works

Content Staging lets you schedule changes to specific content elements and preview them before they go live. You create a "campaign" with a start date and optional end date, then attach changes to that campaign:

When the campaign's start date arrives, all attached changes go live simultaneously. When the end date arrives (if set), changes revert automatically.

What Content Staging Does Well

For promotional planning, Content Staging is genuinely useful. A marketing team can prepare an entire Black Friday campaign (updated banners, promotional pricing, featured categories, themed CMS content) weeks in advance and have it activate automatically at midnight on the sale date. They can preview exactly how the store will look during the promotion.

This scheduled content management capability is something Shopify and BigCommerce do not offer natively, and it is a real advantage of the Adobe Commerce platform.

What Content Staging Does NOT Do

Content Staging operates within your production environment. It schedules content changes, but it does not create an isolated copy of your store. This means it cannot:

In short: Content Staging manages scheduled content. It does not manage staged environments. The name is misleading, and many merchants discover this distinction only after a production incident.

Ready to take action?

Run a Free AI Audit on Your Store

Vortex IQ scans your ecommerce store across 85+ checks — SEO, performance, analytics, ads — and gives you a prioritised fix plan in under 30 seconds.

The name is the whole problem. Content Staging and a staging environment sound like the same thing and solve different problems. If your question is whether a campaign will look right on Tuesday, Content Staging is the right tool. If it is whether an extension upgrade will break checkout, it cannot help, and neither can any amount of care.

Where the Cloud staging environment runs out

Cloud is the strongest starting position of the three, so it is worth being precise about the limit rather than pretending it does not exist. Integration can hold multiple branches. Staging and Production hold exactly one each. That is fine for one project with one change in flight. It stops working when:

Two feature branches need QA in the same week
A security patch needs testing while a redesign is mid-flight
An agency runs ten client projects and is managing ten separate queues by hand
A migration rehearsal needs to hold an environment for a fortnight

At that point engineers wait, branches age, and something eventually ships without a proper rehearsal.

What it costs to build Magento staging yourself

For Magento Open Source and on-premise Adobe Commerce, the honest options are these three.

Local Docker stacks such as Warden, Docker Magento or n98-magerun snapshots. Good for one engineer debugging on a laptop. No public URL for a stakeholder to review, no coordination across a team, and keeping the data in step with production is a standing manual cost.
A permanent self-hosted staging server. It works, and then it drifts. Six months later the extension versions, the data and the config no longer match production, so a green test stops meaning anything.
A custom build. Real infrastructure work, typically five to twenty thousand pounds, plus somebody owning it forever.

All three share one failure mode: the environment is only as useful as its resemblance to production, and that resemblance decays from the day you create it.

On-demand environments with DryRunPro

DryRunPro is the Vortex IQ staging launcher for Magento and Adobe Commerce. It supports all versions, including Adobe Commerce Cloud, on-premise Adobe Commerce and Magento Open Source.

A dryrun is a fully composed, fully cached clone of the production topology, spun up against any branch you point it at, with the full stack underneath: PHP-FPM, MySQL, Redis, OpenSearch and RabbitMQ. On Cloud it is Fastly-fronted and appears in about the time the build pipeline takes to finish.

What it adds beyond an environment:

Many projects from one account, with per-customer team segregation, which is why agencies and systems integrators are the sharpest fit
SWAT reports, Magento extension audits and code audits on every dryrun, so the output is a decision rather than a URL somebody has to go and poke at
bin/sync against the canonical environment
Docker snapshots and Warden packages as deliverables for laptop-side debugging
Disposable by design: spin up, test, tear down, so an environment that exists for one task never drifts

DryRunPro was an Adobe Commerce Rockstar finalist at Adobe Summit 2023.

What to test in a Magento staging environment

The list that earns its keep, in rough order of how often it bites:

Extension upgrades, especially two extensions that are each fine alone
Security patches and platform version upgrades
Theme deployments, and anything at all touching checkout
Database schema changes and data migrations
Integration behaviour end to end: ERP, PIM, payment, shipping
Indexer and cache behaviour under production-like data volumes
Anything during a peak-season code freeze

Frequently asked questions

Does Magento Open Source have a staging environment?

No. Magento Open Source ships neither managed environments nor Content Staging, which is an Adobe Commerce exclusive. Any staging you have on Open Source is one you built yourself.

Is Content Staging the same as a staging environment?

No. Content Staging schedules content, pricing and CMS changes and previews them. It cannot test an extension upgrade, a security patch, custom code, a database change or a theme deployment, because none of those are content.

How many staging environments does Adobe Commerce Cloud give me?

One per project. Cloud ships Integration, Staging and Production, and Adobe's documentation specifies that Staging and Production have one branch each. Integration can hold multiple branches; Staging cannot.

Can I use a development environment as a staging environment?

Not usefully. An environment without your production catalogue, customer data, extension configuration and integrations will pass tests that production then fails.

How long does it take to spin up a dryrun environment?

Minutes. On Adobe Commerce Cloud it is roughly as long as the Cloud build pipeline takes to finish.

Does DryRunPro replace the Adobe Commerce Cloud staging environment?

No, it removes the queue in front of it. The Cloud Staging branch stays where it is, and DryRunPro adds on-demand environments alongside it so two workstreams are not competing for one slot.

Related guides

Run a free store audit and see what is leaking revenue before you change anything, or book a DryRunPro walkthrough and we will run a dryrun against one of your projects.

Adobe Commerce & Magento Staging: The Complete Guide for 2026