The SQL lives in Git. Execution still lives in Migratrix.
Teams already review code in GitHub or GitLab. GitOps puts change scripts in that same review loop, then maps the merge back onto a pipeline with approvals, risk analysis, and rollback instead of treating merge as permission to run against production from CI.
Write in Migratrix, review in Git, promote in the pipeline
Author and open a PR
Write the change script in the SQL editor. Migratrix commits it to the connected GitHub or GitLab repository and opens the pull request. You do not copy SQL into a second tool to start review.
Review with schema context
The PR is the conversation your team already has. Inside Migratrix the same change still carries schema diff, SQL risk, and if enabled application-code impact from Risk Assessment.
Merge syncs the script
On merge, Migratrix imports the change script into the bound pipeline. Execution still honours environment approvals. Merge is not a back door around production gates.
What you connect
The artefact in Git is the change script. History, blame, and branch policy stay with the repository you already operate.
A Git review is not a production approval unless you also configure the environment gate. Separation of duties is a platform permission, not a branch protection setting.
No pipeline to write, and none to maintain
You write no GitHub Action for database changes
Migratrix runs the change itself, so there is no workflow file to write, no database credentials in CI secrets, and no runner that needs network access to production. Your CI keeps doing what it is good at tests and application delivery and the database change is executed by the Executor inside your network, the one process that holds the credentials, the journal and the rollback.
Automation can still drive it, when you want that
MCP and the API expose the same objects the UI does, so a pipeline can create a change script, ask for its risk analysis, or read where it stands. Anything that mutates state asks for an explicit confirmation, so a runner cannot quietly promote to production.
ORM migrations are not rewritten
If Entity Framework or Flyway already emits SQL, Migratrix can review and promote that SQL. It does not replace generating migrations from application models.
Push webhooks, then a very specific auto-execute rule
| Piece | Behaviour |
|---|---|
| Webhook | Only push events are processed; every other GitHub or GitLab event type is ignored. Each delivery is verified against a secret generated when you connect the repository, so a forged call cannot move a change script. |
| GitHub vs GitLab | Both support connect, sync, webhook, and pull request / merge request creation. GitHub requires the GitHub account connected first. GitLab also tries to resolve the commit author by email or username; GitHub uses the GitHub user id. |
| What is stored | PR URL, branch, file path, commit SHA, status, and the linked change script id. |
| Auto-execute after sync | Only if the first pipeline stage has Auto-start on, the environment does not require approval, the script is Pending, and a connection is present. Approval gates always win over a merge. |
| Audit | Repo connected, synced, disconnected; webhook received or rejected; pull request created all in the integrations category of the ledger. |