Workflow Source Control connects a SteelEngine workspace to a GitHub repository. You can protect selected workflows, make changes on branches, review those changes in pull requests, and keep every deployed version tied to an exact Git commit.
Source Control is opt-in. Enabling the integration does not change existing workflows. A workspace admin must protect each workflow individually.
How It Works
Source Control adds a review layer between editing a workflow and deploying it:
- An organization admin connects an approved GitHub repository.
- A workspace admin binds the workspace to a unique path in that repository.
- An admin protects an existing workflow through a pull request.
- Builders create a branch, edit and run the branch draft, then commit the change.
- SteelEngine validates the pull request's exact commit and reports the result as a GitHub Check.
- Merging the pull request updates the protected main draft in SteelEngine.
- An admin explicitly deploys the synchronized main draft when it is ready for production.
Merging does not deploy. A merge updates the protected main draft, while schedules, webhooks, APIs, and hosted surfaces continue to use the current deployment until you choose Deploy.
The Source-Controlled States
| State | Stored in | Editable? | Used by production triggers? |
|---|---|---|---|
| Protected main | SteelEngine, synchronized from the repository default branch | No | Only after it is deployed |
| Branch draft | SteelEngine | Yes, with branch access | No |
| Branch commit | GitHub | Only through a later commit | No |
| Active deployment | Immutable SteelEngine deployment version | No | Yes |
Opening a protected workflow starts on main. Main remains viewable and manually runnable, but all edits—including metadata changes and changes made with Chat—must happen on a source-control branch.
What Git Stores
SteelEngine writes a deterministic, reviewable bundle under the workspace's managed repository path. Workflow IDs provide stable identity, so renaming a workflow changes its metadata instead of moving its directory.
| Stored in Git | Kept in SteelEngine |
|---|---|
| Workflow name, description, color, graph, layout, variables, and interface metadata | Secret values and provider tokens |
| Block configuration, prompts, and code in sanitized files | Credential and resource assignment targets |
| Logical resource requirements, such as a required connection role | Autosaved branch working copies |
| Stable workflow and block IDs | Deployment versions and runtime history |
The managed workflow directory has this shape:
<managed-path>/workflows/<workflow-id>/
metadata.json
workflow.json
layout.json
bindings.json
nodes/SteelEngine owns the bundle files and managed nodes/ directory. Files outside the managed workflow paths are preserved, so the repository can also contain code owners, documentation, and other workspace paths.
Current Scope
- GitHub is the supported provider.
- Each workspace has one active repository binding.
- One repository can serve multiple workspaces when each uses a unique managed path.
- Source Control protects existing workflows; create the workflow in SteelEngine before protecting it.
- Folder placement is not independently source-controlled. A protected workflow cannot be moved, and an ancestor folder containing a protected workflow cannot be renamed or moved.
Get Started
Connect GitHub
Enable the organization integration, connect a repository, and bind a workspace path.
Protect and Edit
Protect a workflow, create a branch, review changes, and commit safely.
Review and Deploy
Validate a pull request, update a branch, merge, deploy, and roll back.
Troubleshoot
Recover from connection, synchronization, validation, and resource-assignment issues.