Teams & Git Deploy

Larger organizations rarely want every user editing every DAG. DagSmith's team model ties permissions to a directory inside a DAG bundle.

How teams work

• An admin creates a team: a set of member users plus an owned subtree (bundle + path_prefix — longest prefix wins when subtrees overlap).
• Only team members (or configured admins) can create or edit drafts under that path; deploy and git-push are enforced the same way.
• New DAGs created by a team member land in the team's directory and are tagged team:<name>, so the native Airflow DAG list can be filtered by team.
• An admin can reassign an individual file to a different team at any time — this override wins over the path-prefix match.

Admins (configured via [dagsmith] admins) bypass team restrictions entirely; if that list is empty, deployers are treated as admins.

Git on deploy

Deploy always writes to the DAG bundle's own checkout — if it's a git repository and git_commit = True is set, DagSmith commits with you as the author. This happens independently of teams.

A team can additionally carry its own git remote (git_remote_url + git_branch). A Commit & Push button pushes HEAD:refs/heads/<branch> straight to that remote (GitHub and GitLab both supported, with a web commit URL returned in the response), and git_push = True makes this happen automatically on every deploy. Git failures never roll back a deploy — they surface in the deploy result and the audit log instead.

Audit log

Every deploy, git push, and team/file reassignment is appended to a JSONL audit log, viewable in the UI (requires edit permission) or read directly from disk.