Modular Schedules with the .bolt/ Folder

The modular layout keeps the same configuration format, but lets you split it across as many files as you like inside a .bolt/ folder. Each team or domain can own its own YAML. Paradime auto-discovers every .yaml/.yml file under .bolt/ and merges their schedules: lists into a single deployment — there is no entry-point file and no import declarations to maintain.

The legacy flat paradime_schedules.yml file is still fully supported, and the two layouts can coexist — see Coexistence with the flat file below.

---

File Location and Structure

Place a .bolt/ folder at the root of your dbt project, next to dbt_project.yml. Any .yaml or .yml file inside (at any depth) is treated as a schedule file.

your-dbt-project/
├── dbt_project.yml
├── .bolt/
│   ├── transforms/
│   │   ├── marketing.yaml
│   │   └── finance.yaml
│   └── ci/
│       └── pull-requests.yaml
├── models/
└── ...

There is no required entry-point file. You can keep one main.yaml if you like, but it's purely a naming convention — Paradime treats every YAML file the same way.

Detection rules

• If .bolt/ contains at least one .yaml/.yml file, the modular layout is active.

• If paradime_schedules.yml is also present, schedules from both are merged (the legacy flat file is no longer ignored).

• If neither exists, no schedules are deployed.

---

File format

Each YAML file uses the same configuration format as paradime_schedules.yml.

# .bolt/transforms/marketing.yaml
schedules:
  - name: marketing daily
    description: "Marketing models daily refresh"
    owner_email: [e-mail]
    environment: production
    git_branch: main
    commands:
      - dbt build --select tag:marketing
    schedule: '0 6 * * *'
    timezone: UTC

• schedules: is the list of schedule definitions for that file. Each schedule's name must be unique across the entire .bolt/ folder and paradime_schedules.yml combined.

---

Processing order and rules

Rule	What it means
Auto-discovery	All .yaml/.yml files under .bolt/ (recursively) are picked up.
Unique schedule names	A schedule's name must be unique across all files (.bolt/ and paradime_schedules.yml combined). Errors point at both files when a duplicate is found.
YAML mapping required	Each file must parse as a YAML mapping at the top level.
Empty files are fine	Use them as placeholders — they're skipped silently.

Files that fail validation surface errors prefixed with the originating file path, so triage is fast:

.bolt/transforms/marketing.yaml: schedule 'marketing daily' has an invalid cron expression

---

Coexistence with paradime_schedules.yml

If both .bolt/ and paradime_schedules.yml exist, Paradime merges all schedules from both sources. This makes it safe to adopt the modular layout gradually — you can move schedules out of the flat file in batches without breaking your deployment, and delete paradime_schedules.yml once it's empty.

The only failure case is a schedule name collision between the two sources, which fails the deploy with a message pointing at both file paths.

---

Related pages

• Editing YAML schedules from the Paradime UI — the in-app YAML editor works with both layouts.

• Deploying YAML schedules from a custom branch — override the default branch that Paradime reads schedules from.

---

Example: multi-team layout

your-dbt-project/
├── dbt_project.yml
└── .bolt/
    ├── marketing/
    │   ├── daily.yaml
    │   └── hourly.yaml
    ├── finance/
    │   ├── month-end.yaml
    │   └── daily.yaml
    └── platform/
        ├── ci.yaml
        └── observability.yaml

Limitations

• Only .yaml and .yml files are supported. There is no templating or variable interpolation between files.

• Schedules cannot be split across files — each schedule is a single object in a single file. You can't put a schedule's notifications: block in a different file from its definition.