Multi-set workflows
Sets
Sets let one repository contain multiple isolated Eventvisor projects while sharing one toolchain and configuration.
Initialize a project with Sets#
Start from the environment scaffold when Sets represent release lanes:
$ npx @eventvisor/cli init --project=environmentsOr enable Sets in an existing project:
Enable them in eventvisor.config.js:
module.exports = { sets: true, tags: ["all", "web", "backend"],};sets/├── consumer/│ ├── events/│ ├── attributes/│ ├── destinations/│ ├── effects/│ ├── schemas/│ ├── targets/│ └── tests/└── admin/ └── ...Each Set is a complete authoring tree. Definitions in consumer do not inherit from or modify definitions in admin.
When to use Sets#
Use Sets when definitions must be independently authored, tested, built, and promoted. Common examples include development, staging, and production, or two business areas with intentionally separate contracts.
Do not use Sets only because several applications consume Eventvisor. Targets normally solve that problem by producing focused datafiles from one shared definition tree.
Many projects use both:
- Sets for independent release lanes
- Targets for application or service datafiles inside each lane
Command behaviour#
Commands process every set by default. Pass --set to select one:
npx eventvisor lint --set consumernpx eventvisor test --set consumernpx eventvisor build --set consumerState is isolated under .eventvisor/sets/<set>. Generated datafiles are written below datafiles/sets/<set>.
The Catalog exports each set below out/sets/<set> and provides a set selector in the navigation.
Sets and promotions#
Preview changes between release lanes, then apply the reviewed plan:
npx eventvisor promote --from development --to stagingnpx eventvisor promote --from development --to staging --apply --auditSee Promotions for flow restrictions, filters, dependency handling, and conflict policies.
Sets as environments#
Sets are a good fit when development, staging, and production must have independent definitions and generated datafiles. The same event key can have different validation, transforms, routing, or tests in every release lane.
See the complete project-environments and project-test-environments references.

