How Git is used

Git is Smeltr's configuration control plane: it stores the versions that workers run. Your edits live on a draft branch until you deploy them to main. Workers follow main and report the commit they are running. A commit identifies a saved version of the configuration.

See the leader, workers, and data connections in one diagram →

What Git holds

Sources, destinations, routes, pipelines, saved samples, tests, and supporting resource files are versioned together. Each worker group has its own configuration under groups/<group-id>/. Reusable configuration lives under shared/. A worker loads its group's configuration together with the shared content at the same commit.

Configuration refers to credentials by name and version. You manage secret values through Secrets or the worker environment. Host startup settings, accounts, and worker state have their own storage. To recover an installation, follow the leader backup procedure; a copy of the Git repository alone does not contain all of that state.

Workers clone the whole configuration repository, including other groups. The leader also trusts an enrolled worker with every credential it stores. A group selects what a worker runs; it does not restrict what that worker can access. Use separate clusters for workloads that require this isolation.

From a branch to main

From a draft to running workersDraft changes go to review. Review can send them back for revision. Approval and deployment publish a commit on main. Each worker fetches main and reports its running commit.ReviseDraft branchSave your editsReviewDiff and test resultsApprove & deployPublish to mainWorker AFetch main · report commitWorker BFetch main · report commitFrom a draft to running workersDraft changes go to review. Review can send them back for revision. Approval and deployment publish a commit on main. Each worker fetches main and reports its running commit.ReviseDraft branchSave your editsReviewDiff and test resultsApprove & deployPublish to mainWorker AFetch mainReport commitWorker BFetch mainReport commit
Review the diff and test results before approval. Each worker fetches main independently; check its running commit to confirm adoption.

Work on a branch in the Smeltr UI. Save your changes, run the tests, and open the change for review. Review the diff and the pipelines and routes it reaches. Bring the branch current if main has moved, then review the result again.

Approval and deployment publish the change as a commit on main. That commit becomes the configuration workers follow. Saving a draft branch leaves the deployed configuration in place. See Review and deploy for the procedure.

To return to an earlier configuration, use Branches → History → Roll back to here. Review its effect across worker groups and check that its secret versions are still available. Then check the workers’ running commits and destination output, just as you would for any other deployment.

A rollback writes no commit. It deploys the earlier commit and holds the fleet there: the leader does not deploy commits that reach main afterwards. History shows the hold, who made it, and how many commits wait, and Status reports Deploy held for as long as it lasts. Release deploys main's head and ends the hold. A change approved during the hold merges to main and waits there for Release.

How workers follow main

  1. An enrolled worker completes its initial check-in with the leader.
  2. It periodically fetches the deployed commit into its local Git repository: main's head, or the commit a rollback holds. The worker discovers it itself; its heartbeat reports deployment state back to the leader.
  3. It prepares the configuration for its worker group and the shared resources at that commit. If preparation fails, it can keep running its previous configuration and report the failure.
  4. It reports the commit it is running. When a change leaves its group and shared content unchanged, the worker can adopt the new commit without restarting its pipeline runtime.

Each worker finds and loads changes independently. Publishing a commit does not switch the whole fleet at once. If a fetch fails, a worker keeps its current configuration and retries. A running worker keeps running through a leader outage; a worker that restarts runs nothing until the leader answers its first check-in. Check its setting for stopping when the leader cannot be reached.

Check the running version

Record the deployed commit on main, then open Status for each intended worker.

In the selected worker's details, compare Commit with the deployed main commit. This is the version the worker reports running. Check its last-seen time and active issues if it differs or the worker is offline.

Once the intended workers report the deployed commit, send a fresh record and verify its output at the destination.