Shopify CLI dev stores became a scriptable resource on September 9. Creating and deleting a dev store is now a public command instead of a click path through a dashboard, so a throwaway storefront can be born with a pull request and die when that branch merges. On its own that is a small quality-of-life change. Read next to what a Magento team is allowed, it exposes a structural gap in how the two platforms let you spend environments.
What Shopify shipped on September 9
Shopify made dev store creation and deletion available from the command line, and it needs Shopify CLI 4.8 or later. The changelog entry names four commands: shopify store create dev to spin up a store for building and testing, shopify store delete to remove one, shopify store list to enumerate the stores in an organization, and shopify store info to read metadata about a single store. Deletion requires store owner or admin access, so a contractor with theme access cannot remove a store by accident.
The full store command reference is wider than the announcement suggests. Alongside those four it documents store create preview for preview stores, store execute for running an Admin API GraphQL query or mutation against a named store, store graphiql for a local GraphiQL session, and store bulk execute for bulk operations. That is enough surface to provision a store, seed it with data through the Admin API, and tear it down again without a human opening a browser.
There is a ceiling. An organization can hold 250 dev stores. Client transfer stores and collaborator stores are excluded from the count, and organizations already above the line were given a temporary extension rather than a hard stop.
Shopify CLI dev stores vs Adobe Commerce Cloud environments
Shopify now allows 250 self-serve dev stores per organization, while Adobe Commerce on Cloud Pro allows four active environments and at most two active integration branches. Pro is documented as master and integration running on PaaS containers plus staging and production on dedicated infrastructure, with a single integration branch for development and the option to create one more. Inactive branches are unlimited, but an inactive branch is code storage. It is not a running store you can point a browser or a test suite at.
That is not a like-for-like comparison and it should not be sold as one. A Shopify dev store is a tenant on someone else's platform with no infrastructure to provision. An Adobe Commerce integration environment is containers, a database, a search cluster and a deploy pipeline, and the reason there are two of them is that each one costs money to keep warm. The comparison still earns its place, because it explains a habit Magento teams mistake for taste. They build locally in Docker because the hosted environment budget was never going to stretch to one environment per feature branch. Warden and DDEV fill a gap Shopify has now closed with a command.
The consequence lands on parallelism. If two active integration branches is the ceiling, a team of six developers queues. Feature work either waits for an environment, or gets verified locally against sample data that does not resemble production, or gets merged to integration in batches large enough that regressions are hard to attribute. All three are a quality tax paid in review time and in bugs found late. On the Shopify side the same team can hold one environment per open branch and stop thinking about it. The interesting number is not 250. It is that the marginal cost of the fortieth environment is zero.
Why 250 is a hygiene problem, not a gift
A 250 store ceiling only binds teams that never delete, which is why shopify store delete is the more important half of this release. Agencies accumulate dev stores the way they accumulate staging subdomains. One per client pitch, one per abandoned prototype, one per developer who left. Each carries an app install list, API credentials and a theme some CI job may still target. None of it is visible until an audit or a breach makes it visible.
What matters here is not creating stores faster. It is making store lifetime a property of your pipeline rather than a decision somebody forgets to revisit. shopify store list plus a naming convention gives you an inventory you can diff against your open branches. Anything in the list that does not map to a branch is a candidate for deletion, and that check can run weekly without a human in it. This is the same argument we make on every automation engagement: the value is not the create step, it is that the destroy step becomes reliable enough to trust.
Naming discipline is the cheap part that gets skipped. A store called acme-pr-412 tells a script which pull request owns it and when it is dead. A store called test-2 tells nobody anything.
What we would change this quarter
Wire store creation and deletion into the branch lifecycle so an environment is born with a pull request and removed when it closes. On Shopify that is now a small amount of CI: create on branch open, seed through store execute, run the theme or app checks against the fresh store, delete on merge or on close. Do it before the store count grows past the point where cleaning up is its own project.
Then run the inventory once by hand. List every dev store in the organization, match it to a client, a branch or a person, and delete what matches none of them. Do the same for the app installs and credentials attached to each one, because a deleted store does not retract a token you gave a third party.
On the Magento side the honest move is the opposite direction. Stop treating two integration branches as a constraint to work around and treat local parity as the actual deliverable. If every developer can bring up a container stack with production-shaped data in under ten minutes, the hosted environment ceiling stops mattering, because integration becomes the place you confirm a merge rather than the place you discover one is broken. That is unglamorous platform work and it is usually the highest-leverage thing available on a mature Magento or Hyvä build.
One framing worth handing to founders comparing platforms. Environment budget is a real line item in delivery speed, and it rarely appears next to licence fees and transaction rates. A stack where a disposable production-like environment is free and scriptable ships small changes faster than one where it is rationed. That is not a reason to pick Shopify. It is a reason to price the difference on purpose rather than discover it in month three.
Where to dig deeper
- Shopify's changelog entry for the command list, the CLI 4.8 requirement and the 250 store cap.
- The
shopify storecommand reference for the full subcommand surface, includingstore executeandstore bulk execute. - Adobe's Pro architecture documentation for the four active environments and the two active integration branch limit.