Seeds

Seeds are small, canonical records required for the application to operate correctly across environments. They define baseline data that belongs with the app itself.

Use seeds for records that are effectively part of your system design rather than normal business data.

Typical examples include:

  • roles and permission levels
  • statuses and enums stored in tables
  • subscription plans
  • default locales
  • global settings
  • required system-owned records
  • feature definitions
  • email template definitions

Seeds should be safe to run in development, testing, and production. They are expected to be idempotent, stable, and low in volume.

Unlike fixtures, seeds are not demo data and should not contain arbitrary sample content. If removing a record would break application behavior or configuration, it likely belongs in seeds.

Good seeds behave like schema-adjacent data: versioned with the application, intentionally maintained, and consistent across environments.

Think of seeds as the baseline records your app depends on.

Seeds are stored in data/seeds directory.

Syntax

$ vela seeds <subcommand>

The subcommand can be one of the following:

  • load - Load seeds into the database

  • save - Save the current data as seeds

  • clear - Clear all seed data from the database