The Vendure CLI is a command-line tool for boosting your productivity as a developer by automating common tasks such as creating new plugins, entities, API extensions and more.
It is much more than just a scaffolding tool - it is able to analyze your project and intelligently modify your existing codebase to integrate new functionality.
The Vendure CLI comes installed with a new Vendure project by default from v2.2.0+
To manually install the CLI, run:
The Vendure CLI supports both interactive and non-interactive modes:
For guidance on using the CLI together with project instructions for AI coding agents, see the AI-assisted development guide.
The add command is used to add new entities, resolvers, services, plugins, and more to your Vendure project.
From your project's root directory, run:
The CLI will guide you through the process of adding new functionality to your project.
The add command is much more than a simple file generator. It is able to
analyze your project source code to deeply understand and correctly update your project files.
For automation or when you know exactly what you need to add, you can use the non-interactive mode with specific arguments and options:
| Flag | Long Form | Description | Example |
|---|---|---|---|
-p | --plugin <n> | Create a new plugin | vendure add -p MyPlugin |
-e | --entity <n> | Add a new entity to a plugin | vendure add -e MyEntity --selected-plugin MyPlugin |
-s | --service <n> | Add a new service to a plugin | vendure add -s MyService --selected-plugin MyPlugin |
-j | --job-queue [plugin] | Add job queue support | vendure add -j MyPlugin --name job-name --selected-service ServiceName |
-c | --codegen [plugin] | Add GraphQL codegen configuration | vendure add -c MyPlugin |
-a | --api-extension [plugin] | Add API extension scaffold | vendure add -a MyPlugin --queryName getName --mutationName setName |
-d | --dashboard [plugin] | Add Dashboard extensions setup | vendure add -d MyPlugin |
--config <path> | Specify custom Vendure config file | --config ./custom-config.ts |
Entity (-e) additional options:
--selected-plugin <n>: Name of the plugin to add the entity to (required)--custom-fields: Add custom fields support to the entity--translatable: Make the entity translatableService (-s) additional options:
--selected-plugin <n>: Name of the plugin to add the service to (required)--type <type>: Type of service: basic or entity (default: basic)Job Queue (-j) additional options:
--name <name>: Name for the job queue (required)--selected-service <name>: Service to add the job queue to (required)API Extension (-a) additional options: (requires either)
--queryName <n>: Name for the GraphQL query--mutationName <n>: Name for the GraphQL mutationValidation: Entity and service commands validate that the specified plugin exists in your project. If the plugin is not found, the command will list all available plugins in the error message. Both commands require the --selected-plugin parameter when running in non-interactive mode.
The migrate command is used to generate and manage database migrations for your Vendure project.
From your project's root directory, run:
For migration operations, use specific arguments and options:
| Flag | Long Form | Description | Example |
|---|---|---|---|
-g | --generate <name> | Generate a new migration | vendure migrate -g add-user-table |
-r | --run | Run all pending migrations | vendure migrate -r |
--revert | Revert the last migration | vendure migrate --revert | |
-o | --output-dir <path> | Custom output directory for migrations | vendure migrate -g my-migration -o ./migrations |
The schema command was added in Vendure v3.5
The schema command allows you to generate a schema file for your Admin or Shop APIs, in either the GraphQL schema definition language (SDL)
or as JSON.
This is useful when integrating with GraphQL tooling such as your IDE's GraphQL plugin.
From your project's root directory, run:
To automate or quickly generate a schema in one command
| Flag | Long Form | Description | Example |
|---|---|---|---|
-a | --api <admin,shop> | Select the API (required) | vendure schema --api admin |
-d | --dir <dir> | Select the output dir (defaults to current dir) | vendure schema --api admin --dir ../.. |
-n | --file-name <name> | The name of the generated file | vendure schema --api admin --file-name introspection.graphql |
-f | --format <sdl,json> | The output format (defaults to SDL) | vendure schema --api admin --format json |
The doctor command was added in Vendure v3.7
The doctor command runs a series of diagnostic checks against your Vendure project and produces an
actionable report. It is useful for debugging a misbehaving project, verifying an upgrade, onboarding
a new machine, or as a guard rail in CI.
Unlike the other commands, doctor is non-interactive only - it runs all applicable checks and prints a report:
By default, the following checks run in order:
| Check | What it verifies |
|---|---|
| Project | Vendure project structure, config file discovery, package manager detection, lockfile consistency, and monorepo support. |
| Dependencies | @vendure/* packages are on matching versions, no duplicate singleton dependencies (graphql, typeorm, @nestjs/core, @nestjs/common, @apollo/server), and that a database driver is installed. |
| Config | Your config loads and validates via preBootstrapConfig() (custom fields, entities), and that plugin compatibility ranges are satisfied. |
| Schema | The Admin API and Shop API GraphQL schemas build successfully, so all plugin extensions and custom field types compile. |
| Database | Database connectivity, using safe read-only overrides. Warns if synchronize: true is set. |
The Production check is not run by default - enable it with --profile production (see below).
The checks are dependency-ordered. If the Project check fails, all later checks are skipped. If the Config check fails, the Schema, Database, and Production checks are skipped, since they all depend on a successfully loaded config.
Each check reports one of four statuses: pass, warn, fail, or skip.
Use --check to run only a subset of checks. The flag is variadic, so list the check names after it:
Valid check names are: project, dependencies, config, schema, database.
When preparing for a production deployment, run the production profile to surface unsafe settings:
This adds a Production check that warns about settings such as disableAuth, default superadmin
credentials, a missing cookie secret, enabled introspection/playground/debug, overly broad CORS,
in-memory job queue/cache/session strategies, and missing asset storage.
For CI pipelines, combine --strict with --format json. The --strict flag treats warnings as
failures, and the command exits with a non-zero code when the overall result is a failure - so a
warning will fail your build:
| Long Form | Description | Example |
|---|---|---|
--config <path> | Specify the path to a custom Vendure config file | vendure doctor --config ./src/my-config.ts |
--check <names...> | Run specific checks only (project, dependencies, config, schema, database) | vendure doctor --check config schema |
--profile <name> | Run profile-specific checks (production) | vendure doctor --profile production |
--format <type> | Output format: text (default) or json | vendure doctor --format json |
--strict | Treat warnings as failures (useful for CI) | vendure doctor --strict |
The Vendure CLI automatically supports monorepo structures where packages have their own tsconfig.json files that extend a shared base configuration.
For the CLI to work correctly in a monorepo, ensure that:
tsconfig.json that extends the root configtsconfig.jsonA typical monorepo structure:
Root tsconfig.json:
Package packages/vendure-app/tsconfig.json:
When you run CLI commands, it:
tsconfig.json by walking up from your Vendure config fileextends chain to merge all configurations@my-org/shared resolve correctlyThe CLI automatically detects your monorepo structure. No additional configuration flags are required as long as your tsconfig.json files are properly set up with extends.
To see all available commands and options: