> For the complete documentation index, see [llms.txt](https://docs.paradime.io/app-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.paradime.io/app-help/products/bolt/creating-schedules/schedules-as-code/modular-schedules-with-the-.bolt-folder.md). # 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. {% hint style="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. {% endhint %} *** #### 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. {% hint style="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. {% endhint %} *** #### File format Each YAML file uses the **same configuration format** as `paradime_schedules.yml`. ```yaml # .bolt/transforms/marketing.yaml schedules: - name: marketing daily 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 ``` {% hint style="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. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.paradime.io/app-help/products/bolt/creating-schedules/schedules-as-code/modular-schedules-with-the-.bolt-folder.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.