Skip to main content
The Dryrun Environments tab is the cross-project list of every dryrun environment that DryRunPro is currently maintaining, across every project in your tenancy. Where the Projects tab is project-centric (“which Adobe Commerce Cloud projects do I manage?”), this tab is environment-centric (“which dryruns are running right now and what state are they in?”). Live URL: app.vortexiq.ai/v2/apps/dryrunpro/staging This page documents what a dryrun is, why on-demand staging matters, the table layout, the lifecycle states, the two top-bar actions (“Create Staging Environment” and “Upgrade to Adobe commerce”), the three secondary actions (“Enable/Disable Magento Extension”, “Configuration settings”, “Adobe US Events”), and how to create a dryrun for either an Adobe Commerce Cloud project or an on-premise Adobe Commerce / Magento Open Source server.

​
What a dryrun environment is

A dryrun is a temporary, fully composed, Fastly-fronted clone of an Adobe Commerce Cloud topology, spun up against any branch you point it at. Under the hood it is a coordinated set of Docker containers (PHP-FPM, MySQL, Redis, OpenSearch, RabbitMQ) that mirror the production stack, plus a media volume cloned from the source environment, plus a database cloned from the source environment, plus a CDN entry that exposes the dryrun on a public URL such as https://staging-47k74xtjq6jya-2.dryrunpro.com. You point a dryrun at a branch (e.g. staging, master, pr-1068) and DryRunPro runs the Adobe Commerce Cloud build pipeline against that branch’s code, but with the dryrun’s database and media instead of production’s. The result is a public, testable, throwaway Magento environment that does not interfere with the Adobe-side integration / staging / production tier. When the dryrun has done its job, you tear it down. The containers stop, the database is dropped, the media volume is reclaimed, the CDN entry (or SSH connection, for on-premise and Open Source) is revoked, and the URL stops resolving. The description above is the Adobe Commerce Cloud path specifically: Fastly-fronted, built through Adobe’s own Cloud build pipeline. On-premise Adobe Commerce and Magento Open Source dryruns are built the same way underneath (the same Docker stack, the same database and media cloning) but are sourced by connecting directly to your server over SSH instead of through Adobe’s pipeline. See Connecting an on-premise or Open Source project below.

​
Why on-demand staging matters

Adobe Commerce Cloud ships with three environment tiers per project: integration, staging, and production. Many enterprise teams have several feature branches in flight at any given time, plus a hot-fix queue, plus a release candidate. The three-tier ceiling forces serialisation: only one feature can sit in staging at a time, and the integration environment is shared chaos. On-premise Adobe Commerce and Magento Open Source start from further behind: neither ships a managed staging environment at all, so every environment is one the team builds and maintains by hand. DryRunPro removes the ceiling either way. Every project gets unlimited dryrun environments on demand. Engineers do not wait for a staging slot, or for someone to provision one. QA can run a dozen parallel SWAT reports. Release managers can rehearse two release candidates side by side. Migration teams can run cutover dummies without ever touching the live integration environment or the live server.

​
The table layout

The dryrun list is a paginated table with the following columns: A search box top-right filters the table by free text against any column. The “Show / entries” dropdown at top-left controls pagination size.

​
Top-bar actions

Two prominent buttons sit above the table: Create Staging Environment (green). Opens the spin-up wizard. You pick a project, pick a branch, pick a dryrun name, and DryRunPro starts the build. The new row appears in the table immediately with status “Processing”. Upgrade to Adobe commerce (green). Promotes a passing dryrun back into the Adobe-side environment ladder. Use this when the dryrun has been validated by QA and you want the same code committed up the Adobe staging tier. The promotion runs the Adobe Cloud CLI under the hood and writes the dryrun’s branch into the chosen Adobe environment.

​
Secondary action buttons

Three blue buttons sit on a second row: Enable/Disable Magento Extension opens a popup that reads the Magento extension list from the active dryrun and lets you toggle modules on or off without re-running a full build. The toggle is persisted to the dryrun and survives container restarts. Configuration settings opens a key-value editor for Magento core_config_data and env.php overrides. Useful for ad hoc “set base URL to X” or “switch payment to sandbox” tweaks during a QA pass. Adobe US Events is a regional log subscription. When enabled, DryRunPro tails the Adobe Commerce Cloud event stream for the project and surfaces events that affect dryrun availability (Adobe-side maintenance, region failover). It is most relevant to merchants whose primary region is the US.

​
Lifecycle states

A dryrun moves through these states over its lifetime: The Failed state is the one that most often needs human attention. The most common failure modes:
  1. The Adobe-side branch references a Composer dependency that DryRunPro cannot resolve. Check the DRP Composer overrides on the project.
  2. The database clone exceeded the storage allocation for the dryrun. Adobe-side production databases above 50 GB sometimes need a size override. Open a ticket.
  3. The deploy-bot SSH key has rotated and the dryrun could not authenticate. Re-run the Add Project wizard’s step 4 to re-validate.

​
Spinning up your first dryrun (Adobe Commerce Cloud)

  1. Click Create Staging Environment in the top-bar.
  2. Pick the project (the dropdown shows all projects on the Projects tab).
  3. Pick the Adobe-side branch (the dropdown shows the project’s Adobe Cloud Environments list).
  4. Optionally, set a dryrun name (defaults to “<project>-<branch>”).
  5. Optionally, pre-attach a Docker package or composer override.
  6. Click Start.
The dryrun appears in the table with status “Processing”. Wait until it goes to “Completed” / “Active” (4 to 12 minutes), then click View to open the Staging Detail page and copy the Dryrun URL. This flow needs a project already added through the Add Adobe Commerce Cloud Project wizard. On-premise Adobe Commerce and Magento Open Source skip that step entirely; see below.

​
Connecting an on-premise or Open Source project

Adobe Commerce Cloud has its own build pipeline and credential model, so it needs the Add Adobe Commerce Cloud Project wizard first. On-premise Adobe Commerce and Magento Open Source do not go through that wizard at all. They connect directly from Create Staging Environment, where a Cloud / On-Prem toggle switches the form between the two sources. Picking On-Prem replaces the project-and-branch picker with a direct SSH connection form: Four buttons drive the flow, in order:
  1. Save Connection. Stores the connection (without launching anything) so it can be reused for future dryruns without re-entering SSH details. Saved connections appear at the top of the On-Prem form the next time you open it, with host, username, port, Magento root and branch label shown for each, and a Load button to reuse one.
  2. Test Connection. Confirms DryRunPro can reach the host over SSH with the credentials given, before anything is built.
  3. Probe PHP/Services. Reads the PHP version and running services on the target host, so DryRunPro can match the dryrun’s container stack to what your server actually runs.
  4. Launch Staging. Starts the build. The new dryrun appears in the Dryrun Environments table exactly like a Cloud dryrun, with the same lifecycle states, the same Docker packages, and the same tear-down flow.
Connection/probe output streams into a log panel on the page as each step runs, so a failed Test Connection or Probe shows the actual error (auth failure, unreachable host, wrong path) rather than a generic failure. Because the source is your own server rather than Adobe’s build pipeline, an on-premise or Open Source dryrun is not fronted by Fastly. It is reachable directly, or through whichever CDN mode you selected.

​
Tearing down

To delete a dryrun, click the red Delete action in the table row. DryRunPro asks for confirmation. On confirm, the dryrun moves to Stopping, then Stopped. The URL stops resolving within ~30 seconds. The Stopped row stays visible for 7 days for audit, then is purged. Docker packages produced by the dryrun remain available on the Docker packages tab independently.

​
Frequently asked questions

How long does a dryrun take to spin up? Typically 4 to 12 minutes for a healthy Adobe Commerce Cloud project. Larger databases (>30 GB) and projects with deep Magento extension stacks push the upper end. The Started, Ended, and Duration columns show the actual times. On-premise and Open Source timing depends on your own server’s connection speed and database size rather than the Adobe Cloud build pipeline. Do I need Adobe Commerce Cloud to use DryRunPro? No. Use the Cloud / On-Prem toggle on the Create Staging Environment page. On-premise Adobe Commerce and Magento Open Source connect directly over SSH instead of through the Add Adobe Commerce Cloud Project wizard. See Connecting an on-premise or Open Source project above. Is my SSH password or private key stored? Yes, if you click Save Connection, so the connection can be reused for future dryruns without re-entering it. Treat a saved connection the same way you would any other stored infrastructure credential; ask your DryRunPro account manager about your tenancy’s credential storage and access-control policy if you need specifics for a security review. How long does a dryrun stay alive? As long as you want. There is no automatic expiry by default. Some agency tenancies set a 7-day or 14-day default expiry policy via Settings; check with your DryRunPro account manager. Can two dryruns coexist for the same project? Yes. That is the entire point of the on-demand fleet. The Staging count on the Projects card shows how many are active per project. There is no per-project ceiling. Can I run a dryrun against a feature branch like pr-1068? Yes. Pick the branch in the Create Staging Environment wizard’s branch dropdown. Any branch listed in the project’s Adobe Cloud Environments list is selectable. What is the SWAT report? A static-analysis pass run by DryRunPro across the dryrun’s codebase (Magento extension audit, security check, deprecated API usage, performance hot-spots). The Open link in the table opens the report in the dryrun’s UI. Reports are generated automatically on Completed. Can I share a dryrun URL with a non-DryRunPro user? Yes. The dryrun URL resolves through the configured CDN and is publicly accessible by default. To gate it, set the dryrun’s CDN mode to “DRP behaviour” and add a basic-auth password on the Staging Detail page. My dryrun build is stuck in Processing for over 30 minutes. That is unusually long. Click View to open the build logs and look for errors. Most often it is a Composer dependency that cannot be resolved, or a database clone that has hit a storage cap. Open a ticket with the staging ID for support. What is the difference between Completed and Active? Completed means the build pipeline finished successfully. Active means the containers are running and the URL is live. They are usually the same instant, but a dryrun in Completed that has been “stopped” (containers paused to save resources) is still Completed but not Active.