What DryRunPro does
How much staging you start with depends on which edition you run, and none of the starting points are enough on their own:
In all three cases, engineers wait, code rots in branches, and releases ship blind.
DryRunPro removes the bottleneck by giving every project an on-demand dryrun fleet. A dryrun is a fully composed clone of the production topology, spun up against any branch you point it at, with a full Docker stack underneath (PHP-FPM, MySQL, Redis, OpenSearch, RabbitMQ). It runs SWAT reports, Magento extension audits, code audits, and bin/sync against the canonical environment. When you are done, you tear it down with one click.
Adobe Commerce Cloud projects get a Fastly-fronted public URL for every dryrun, built through Adobe’s own Cloud build pipeline. On-premise Adobe Commerce and Magento Open Source projects connect directly over SSH to your server instead, so DryRunPro can clone the codebase, database and media without needing an Adobe Commerce Cloud subscription at all. See Connecting an on-premise or Open Source project for how that connection works.
Because everything sits inside one DryRunPro tenancy, one user account manages many projects at once, cloud and self-hosted alike. That is the foundational design decision that distinguishes DryRunPro from a per-project CI/CD plugin or from Adobe’s own Cloud CLI.
Who DryRunPro is for
- Enterprise Adobe Commerce Cloud merchants running one or more Magento Cloud projects who want a fast, repeatable staging surface that does not collide with the integration environment.
- Adobe Commerce on-premise and Magento Open Source merchants who have no managed staging environment at all and would otherwise have to build and maintain one themselves.
- Adobe solution partners and Magento agencies who manage projects on behalf of multiple enterprise customers, usually across a mix of editions, and need one console with per-customer team segregation.
- In-house Magento engineering teams that ship across several feature branches in parallel and need more dryrun environments than the three-tier Adobe ceiling allows.
- QA leads and release managers who need a SWAT report, a code audit, and a bin/sync run against a candidate branch before signing off a production deploy.
- Migration teams moving from Magento on-premise to Adobe Commerce Cloud, where dryruns let them rehearse a full production cutover without touching the live Cloud project.
The multi-project architecture
A normal staging tool assumes one tenant equals one storefront. DryRunPro assumes one tenant equals many Adobe Commerce Cloud projects. The screenshot of the Projects tab in a real DryRunPro tenancy shows eleven distinct enterprise merchants in one console: Ulster Weavers Ltd, Xupes Limited, Bahrain Duty Free Company WLL (Dublin), Soak and Sleep, Independent Buying Consortium, Eggfree Cake Box Limited Azure, Eggfree Cake Box Ambala, Boutinot Ltd, Blitz Corporation Ltd, Bahrain Duty Free Company W.L.L., and Krispy Kreme UK and Ireland. Each is a separately provisioned Adobe Commerce Cloud project with its own credentials, its own environments, and its own DryRun Pro fleet, and the same engineering team operates all of them from one login. Each project card on the Projects tab shows two columns of metadata side by side. On the left, the Adobe Commerce Cloud column reports the live cloud topology (Environments, Storage in MB, Users). On the right, the DryRun Pro column reports the DryRunPro overlay (Staging, Packages, Users). At the bottom of the card sits the Team assignment dropdown (“Cakebox”, “Blitz”, “BDFC”, or no team), then a red Delete Project button on the left and a blue View Details link on the right. The team assignment is what keeps the multi-project model from becoming chaos. A team is a group of users that gets assigned to one or more projects collectively, instead of you having to grant per-user access on every project. See Teams for the full model.The seven top-tabs
DryRunPro’s left-rail navigation has seven primary tabs plus a sub-grouped Settings menu. They are, top to bottom:
A Change password link and a Logout link sit beneath the seven tabs.
The “Create your own” tab is worth calling out. It is the spin-up launcher that turns “I need a dryrun” into a running environment in the few minutes it takes for the Adobe Commerce Cloud build pipeline to finish. We document it as part of the Dryrun Environments section because the lifecycle starts there.
Position vs other staging tools
The staging space has four classes of tool that each solve a slice of the problem. DryRunPro is the only one that solves all four at once, across every Magento and Adobe Commerce edition. Adobe Cloud CLI and Cloud Manager. Adobe ships a command-line interface (magento-cloud) and a web console (Cloud Manager) for provisioning environments inside one project. They are excellent for the three-tier integration / staging / production flow, and they only exist for Adobe Commerce Cloud, so on-premise and Open Source get nothing from them. They do not give you on-demand dryrun fleets, they do not give you a multi-project console, they do not give you team-based access, and they do not run SWAT reports or code audits as part of the workflow.
Adobe Commerce Content Staging. Bundled with Adobe Commerce and absent from Magento Open Source, Content Staging schedules content, pricing and CMS changes and previews how they will look. The similar name causes real confusion, but the two solve different problems: Content Staging is a scheduling tool, not an environment, so it cannot test an extension upgrade, a security patch, custom code, a database change, or a theme deploy.
Magento staging frameworks (Warden, Docker Magento, n98-magerun snapshots). Local Docker stacks let an engineer spin up a Magento environment on a laptop. They do not produce a public URL and they do not coordinate work across a team of engineers, so keeping them in step with production is a standing manual cost. DryRunPro can produce a Warden package as a deliverable for laptop-side debugging, but the dryrun itself runs centrally, accessible by a URL anyone on the team can hit.
StagingPro (BigCommerce) and Vortex Staging (Shopify). These are the sister Vortex Apps for the SaaS storefront platforms. They solve the same problem class (preview a change before production) but the underlying architecture is different. BigCommerce and Shopify do not expose Docker, do not expose code-level Magento extensions, and do not have an Adobe Commerce Cloud-style multi-environment topology. So the UI is different and the lifecycle is different. Cross-link StagingPro and Vortex Staging for those platforms.
DryRunPro stitches the multi-project console, the on-demand fleet, the SWAT report, the code audit, the Docker snapshot, the Warden package, and the team-assignment model into one unified surface across every Magento and Adobe Commerce edition. That combination is what the other tools do not offer.
Pages in this section
How DryRunPro connects to the rest of the AI OS
DryRunPro is one Vortex App. It does not stand alone. It is wired into the rest of the AI OS so that the staging surface is informed by, and informs, every other module:- The Adobe Commerce connector on Nerve Centre surfaces the same Cloud project that DryRunPro stages. KPIs you see on Nerve Centre (sales, conversion, page-load, error rate) are the production baseline against which a dryrun is compared.
- Vortex Mind reports such as Daily Revenue Leakage and Checkout Conversion Failure run against the production Adobe Commerce data. When Vortex Mind flags a regression, DryRunPro is where you reproduce the fix safely.
- Ask Viq can answer “which dryrun is currently green for project X?” and “which staging environment was used for the 4.2.0 release?” by reading DryRunPro state.
- Actions tied to Magento extension issues, code audit findings, or storefront regressions can route into a DryRunPro dryrun for verification before they ship.