- The modular
.bolt/folder - The legacy flat
paradime_schedules.ymlfile
What the editor shows
The editor automatically detects which layout your repository uses:.bolt/folder layout — the editor shows a file tree of every.yaml/.ymlfile under.bolt/. You can open any of them in the editor, create new files, rename them, or delete them. If a flatparadime_schedules.ymlalso exists, it appears alongside.- Flat layout — the editor shows the single
paradime_schedules.ymlfile. - Nothing configured yet — the editor offers to create your first schedule file.
Source branch
The editor reads file contents from the same branch that Paradime uses to deploy schedules:- By default, your repository’s default branch (usually
mainormaster). - If a custom schedule deployment branch is configured, that branch is used instead.
- Commit directly to the deployment branch (fast path, no review).
- Commit to a feature branch and open a Pull Request back to the deployment branch (recommended for teams).
Atomic multi-file commits
When you save changes, all edited files are committed as a single Git commit. This matters most for the modular layout:- If you rename a schedule and need to update two files (the definition file and a downstream
schedule_triggerreference), both changes land in one commit. - If a commit fails partway through (e.g. a permissions issue), no file is updated — your branch is never left in a half-saved state.
- The commit shows up in your Git history as a normal commit attributed to your Paradime user.
What you can do
After saving
Saving from the UI creates a Git commit, but does not trigger a redeploy on its own. Once your changes land on the deployment branch (either directly, or via a merged PR), schedules are picked up on the regular cadence:- Automatic Refresh: every 10 minutes.
- Manual Refresh: click Parse Schedules in Bolt.
💡 Note: If you committed to a feature branch, Paradime won’t see the changes until the PR is merged into the deployment branch.