> ## Documentation Index
> Fetch the complete documentation index at: https://docs.paradime.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

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

***

#### 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.

<Warning>
  **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.
</Warning>

***

#### File format

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

```yaml theme={"system"}
# .bolt/transforms/marketing.yaml
schedules:
  - name: marketing daily
    slug: marketing-daily-w1x2y3
    description: "Marketing models daily refresh"
    owner_email: marketing-data@acme.io
    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
```

<Info>
  **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.
</Info>


## Related topics

- [Schedules as Code](/products/bolt/creating-schedules/schedules-as-code/index.md)
- [Editing YAML Schedules from the Paradime UI](/products/bolt/creating-schedules/schedules-as-code/editing-yaml-schedules-from-the-paradime-ui.md)
- [Deploying YAML Schedules from a Custom Branch](/products/bolt/creating-schedules/schedules-as-code/deploying-yaml-schedules-from-a-custom-branch.md)
- [Amazon S3](/integrations/amazon-s3.md)
- [GitHub](/products/bolt/ci-cd/turbo-ci/github.md)