Shopify CLI: one command line for apps, themes and Hydrogen storefronts

One CLI covering three separate development workflows

The stated scope of the tool is wider than the name suggests. With the Shopify command line interface you can initialize, build, dev, and deploy Shopify apps, extensions, functions and themes, and you can build custom storefronts and manage their hosting.

That is three workflows behind one binary. Apps are the first: a project scaffolded with a create command, then developed locally and deployed. Themes are the second, the Liquid templates that render a store, with their own push and pull workflow against a live store. Hydrogen custom storefronts are the third, a separate React based stack that needs its own build and hosting handling.

The project description gives it away: build apps, themes, and hydrogen storefronts for Shopify. Each of those three has its own ecosystem, its own templates and its own deployment target, and the value of a shared CLI is that the developer experience stays the same across them.

The repository itself confirms the split. The top level tree holds a packages directory where the individual commands live, a configurations directory, a packaging directory, a docs directory for the CLI documentation, a docs-shopify.dev directory for the published docs site, and a workspace directory. The package.json in the root is private and marked as an ES module project, which tells you the published artefact is assembled from inside the monorepo rather than being the repository itself.

Apps are created by the create-app package, not by a global install

The app workflow deliberately does not require you to install the CLI first. When building a Shopify app, you can initialize your project using your preferred package manager, and a single command installs all the dependencies you need, including Shopify CLI itself.

The documented initializers are four, one per package manager: npm init @shopify/app@latest, pnpm create @shopify/create-app@latest, yarn create @shopify/app, and bun create @shopify/app@latest, which is marked as experimental.

That list is the first practical signal about the project. The npm path is described as installed by default with Node, so the cheapest route to a working app needs nothing but Node. The pnpm path names a different package, @shopify/create-app, while the yarn and bun paths use @shopify/app, so the package name is not uniform across managers. If you script project creation, check the exact create command for the manager you use rather than assuming symmetry.

The app documentation is where you would look for the create-app flow itself, and the repository root holds an UPGRADE_GUIDE.md alongside a RELEASE_NOTES directory, which is what you would read to find out what changed between CLI versions.

Themes need a global install, and there are two ways to get one

Themes invert the app story. To work with themes, the CLI has to be installed globally, and the documented npm route is:

npm install -g @shopify/cli

On macOS there is a Homebrew alternative, described as installing it through Homebrew:

brew tap shopify/shopify && brew install shopify-cli

The distinction matters for how you set up a machine or a CI image. An app project carries its own CLI dependency in the project, installed by the create command, so the version is pinned by the project and travels with it. A theme project relies on a CLI that is present on the machine, so two developers on different machines can quietly end up on different CLI versions, and a CI runner that reinstalls the tool each time gets whatever the registry serves that day.

That is why the global install exists at all. The theme commands act on a store rather than on a project scaffold, and the CLI needs to be present before it knows which store you are pointed at.

The README also flags the case where the CLI is already handled for you, with a note that the Hydrogen code lives in a separate repository at Shopify/hydrogen, under packages/cli. Hydrogen users are pointed at their own CLI package rather than at this one.

A monorepo built with pnpm and Nx

The build system tells you how the project is put together. The root package.json declares the package manager as [email protected], and the tree contains pnpm-workspace.yaml, pnpm-lock.yaml and nx.json, so this is a pnpm workspace with Nx coordinating the builds across packages.

The scripts in the root manifest show the shape of the pipeline. Build and lint run across all packages with nx run-many, and there are affected variants that limit the work to packages touched by a change:

  "packageManager": "[email protected]",

    "build": "nx run-many --target=build --all",

    "lint:affected": "nx affected --target=lint",

Release handling is scripted rather than manual. The changeset script runs a local bin/changeset.js, and the changeset-manifests script versions the packages, reinstalls, and refreshes the manifests, the README, the code documentation and the CLI kit version in one chain. The release and post-release scripts point at ./bin/release and ./bin/post-release.

There is also a per-platform release configuration in the tree, with shipit.production.yml, shipit.stable.yml.sample, shipit.nightly.yml and shipit.experimental.yml. That set of channel files is the clearest sign of how this tool ships: several tracks, from production down to experimental, each with its own configuration rather than one linear release line.

oclif underneath, with GraphQL code generation in the build

The command framework is oclif, listed in the references section of the project description. That choice explains the shape of the source tree, with each command a package under packages, each one carrying its own manifest and its own documentation, and it is why the commands reference lives inside the CLI package rather than in a separate site.

GraphQL is a first class concern rather than an afterthought. The scripts include a graphql-codegen target that runs across all packages, and a separate script, bin/get-graphql-schemas.js, whose name says it fetches the schemas that the generator consumes. There is also a graphql.config.ts at the root. For a tool that talks to the Shopify Admin API, generated types for that API surface are the difference between a command that compiles and one that does not, and the repository treats schema refresh as a scripted step in the release chain rather than something a developer does by hand.

Dead code detection is wired in as well, through a knip script and a tool directive for golang.org/x/tools/cmd/deadcode in the go.mod of the tooling tree. Combined with the TypeScript configuration files at the root, the eslint config, and the prettier ignore file, this is a repository with a strict definition of what counts as used.

None of this is visible from the outside when the command works. It matters when you contribute, or when you are trying to work out whether a version bump will break something.

What the CLI does not do for you

There is no explicit limitations section here, so the boundaries have to be read off the documentation, and they are real.

First, this is a tool for building against Shopify, not a general purpose API client. The commands wrap platform specific workflows: creating an app project, pushing theme files to a store, deploying a Hydrogen storefront to its hosting. If your task is to read a list of orders from a script that runs on a schedule, an HTTP client with an access token is the right tool and this CLI is a detour.

Second, the theme workflow requires a global installation, and the app workflow requires the create command. Neither is a single answer to the question of how do I install this, and a CI configuration that assumes one path will break on the other.

Third, the bun initializer is marked experimental, and the CLI itself ships on several release channels including nightly and experimental. The four recent published versions, 4.9.2 and 4.9.3 on 2026-10-09 and 4.9.4 on 2026-10-14, show a fast cadence, which is good for fixes and awkward for reproducibility. The channel configuration files in the repository are where that decision is made, and if you need a stable line for production you should pick one deliberately rather than tracking latest.

There is also a documentation boundary worth stating plainly. The repository holds the CLI documentation under docs, and the published docs site source under docs-shopify.dev, but the README itself is thin on behaviour. Anything about exact command flags, authentication flows and error handling lives in those documentation trees, not in the file most people read first.

Contributing means joining a monorepo, not a single package

The contribution path is documented, and it starts by pointing at two files in the repository: the contributors docs under docs, and the steps to get started at docs/cli/get-started.md.

Before that, the basics are in the root README. Install the latest version of Node.js and npm, or another package manager of your choice. There is a .nvmrc file and a .npmrc file in the tree, which is how the repository pins the Node version it expects and the npm behaviour it relies on.

The tree also carries a set of directories aimed at tooling rather than code: .agents, .claude, .cursor and .jules, plus an AGENTS.md at the root, a .gworkspace-mcp directory and a .spin directory. Whatever they are exactly, they show a project that has adopted a set of assistant and MCP conventions in its workflow, and contributors will encounter them.

The support routes are community based. To report a bug you create a post in Shopify CLI and Libraries on the dev community, to ask a question or request a feature you create a post in Dev Platform, and the Shopify Community Forums are listed as the place to connect with the community and learn about CLI development. There is no issue tracker link in the README for bug reports, because the community forum is the reported route.

The licence is MIT, and the repository root carries a LICENSE file. That is the permissive choice, and it matters for a tool most teams install rather than fork.

Editorial conclusion

Adopt Shopify CLI if you are building on the Shopify platform, because the app, theme and Hydrogen workflows it wraps are the documented path and the tool is still moving, with the last push on 2026-10-20 and version 4.9.4 published on 2026-10-14. Do not adopt it to call the Shopify Admin API from a script, since that is a different job and a plain HTTP client does it. Verify first which of the three install routes suits your setup, because themes need a global npm install or a Homebrew tap while apps are created through the create-app package.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Shopify/cli on GitHub