How Git Sync Works for Generated IaC and Discovery

Git sync for generated IaC means AI-created Terraform, OpenTofu, configurations, discovery exports, and asset inventories are pushed into repositories with branches, commits, pull requests, and sync status instead of living only in a chat or dashboard. ops0 supports repository browsing, file import, file export, branch management, pull request creation, commit tracking, and purpose-specific integrations for IaC, configurations, discovery, and assets.

AI infrastructure only works in serious teams if it respects the existing review system. The code can be generated by AI, but the organization still needs Git history, approvals, diffs, and rollback paths.

Why Generated IaC Still Belongs in Git

Infrastructure code is an audit artifact. It explains what changed, who approved it, and when it became the desired state.

If AI generates infrastructure but the result never reaches Git, the team has a shadow control plane. That is fast for demos and dangerous for production.

ops0 avoids that by syncing generated outputs to GitHub or GitLab workflows. Generated code becomes reviewable code.

What Gets Synced

The product architecture supports multiple Git purposes:

• IaC projects generated from intent

• Configuration projects and Ansible or Kubernetes files

• Discovery outputs and generated Terraform from scanned cloud resources

• Asset inventories

• Workflow definitions and operational artifacts

Each use case has different paths, branches, sync status, and pull request behavior, but the principle is the same: generated output should be versioned.

How the Workflow Works

A user connects a Git provider, selects a repository, chooses a base path and branch, and then syncs the generated files. ops0 can track the last synced commit SHA, sync status, pull request number, pull request URL, branch, and whether auto-sync is enabled.

For discovery, this is especially useful. A brownfield cloud scan can generate Terraform, push it to a repository, and give the team a real review process for bringing unmanaged resources under code.

For configurations, it means generated playbooks and Kubernetes manifests can move through the same review system as application code.

ops0 Does Not Replace GitOps

A common concern about AI-generated infrastructure is that it bypasses GitOps. It does not, at least in this design. ops0 uses AI to generate code, then keeps that code in Git-centered workflows with sync, branch, PR, commit SHA, and audit metadata. The repository remains the source of truth and the review surface.

That is a stronger position than "we integrate with GitHub." It defines the operational control model: AI accelerates writing, Git enforces review, and policy gates enforce safety.

What Teams Should Check

When evaluating Git sync for AI-generated infrastructure, ask:

• Can generated code be pushed to an existing repo?

• Can the platform create branches and pull requests?

• Does it track commit SHA and sync status?

• Can discovery-generated code use the same workflow?

• Can configurations and Kubernetes manifests be synced too?

• Are credentials encrypted and scoped by organization?

These details determine whether AI-generated IaC fits the way real teams work.

How It Works

Git sync inside ops0 is not a single integration. It is a family of mappings, one per sync purpose, each with its own table and its own semantics.

IaC sync uses iacGithubMappings and iacGitlabMappings. Each mapping records the connected repository, the base path, the branch, an autoSync flag, the lastSyncedCommitSha for change detection, and a syncStatus field that moves between idle, syncing, success, and error along with a syncError message when a sync fails.

Configuration sync uses configurationGithubMappings and configurationGitlabMappings for Ansible playbooks and Kubernetes manifests. The semantics are intentionally different from IaC sync. Configuration mappings expose a syncOnChange flag rather than autoSync because configuration files often change in response to upstream events and the sync trigger is per-file rather than per-project.

Discovery is treated differently. Discovery output is pull-only from cloud APIs into the database. There is no dedicated discovery sync table because discovery is not a Git-managed artifact by default. When a discovery scan generates Terraform for unmanaged resources, that generated Terraform flows through the IaC sync path, not a separate discovery sync.

Assets are inventoried in iacDiscoveredResources and live in the database alongside the projects they belong to. They are queryable through Resource Graph and the Query Console rather than synced to Git.

How Credentials Are Stored

GitHub credentials live in githubIntegrations with the access_token field encrypted using AES-256-GCM. GitLab credentials live in gitlabIntegrations with personalAccessToken encrypted the same way. The encryption key format is iv:authTag:ciphertext and the key is sourced from the ENCRYPTION_KEY environment variable padded to thirty-two bytes.

Decryption happens at sync time, not at boot. The plaintext token is held only for the duration of the API call and never logged. This is why a leaked database backup does not give an attacker a working GitHub token.

The Clone And Overlay Pattern

Generated Terraform often references modules that live elsewhere in the repository. A generated main.tf might call a module at modules/networking which only exists in the user is repo, not in the database. Pushing only the generated file would break the project for anyone who pulls it.

ops0 solves this with a cloneAndOverlay flow inside the IaC sync routes. At sync time, ops0 clones the full target repository and overlays the database-managed files on top of the working tree. terraform init then resolves modules and providers correctly because the local file system contains both the generated files and the user is existing module tree.

This is also why the sync respects the user is branch and base path: the overlay needs to match the directory structure the rest of the repository expects.

Branches, PRs, And Commit Tracking

Sync flows can push directly to a branch or open a pull request. GitHub PR creation runs through Octokit with title, body, head branch, and base branch parameters. GitLab merge requests are created over the GitLab GraphQL API. Both providers support optional auto-merge configuration when the team trusts the policy and review setup enough to skip manual merge for low-risk changes.

Change detection uses lastSyncedCommitSha rather than timestamps. A commit pushed by another tool, a coworker, or a CI job changes the SHA and ops0 picks it up on the next pull. lastPulledAt records when ops0 last reconciled the upstream state. Together, the SHA and the pull timestamp are how ops0 knows whether the local view of the repo matches reality.

What Happens When Sync Fails

Sync failures are first-class. syncStatus moves to error and syncError captures the underlying message. The UI surfaces the failure on the project so it does not silently fall behind.

Common failure modes are scoped tokens that lost permission to a repo, branch protection rules that block a force push, merge conflicts with upstream changes, and rate limits on the provider API. Each of these has a different recovery path. Permission errors require re-authorizing the integration. Branch protection is resolved by opening a PR rather than pushing directly. Conflicts are resolved by pulling first via cloneAndOverlay and re-running the sync. Rate limits are handled by retry with backoff inside the sync worker.

The principle is the same across all of them: a sync that fails should be visible, recoverable, and never quietly drop the change.

What Teams Should Verify

When evaluating whether ops0 Git sync fits the way a team works, the useful checks are concrete.

Does the team need separate IaC and Configuration sync, or one of them? Are the repos protected by branch policies that require PRs? Does the team rely on module references that need cloneAndOverlay to resolve? Is auto-merge acceptable for any class of change, or should every change open a PR? Do they need GitLab MR support, GitHub PR support, or both? Which credentials should be encrypted at rest and rotated, and on what cadence?

These are the questions that decide whether AI-generated infrastructure becomes an operational asset or a parallel system that bypasses governance.

The Bottom Line

AI changes who writes infrastructure code. It should not remove the review system around that code.

ops0 keeps generated IaC, discovery exports, configurations, and asset inventories attached to Git workflows so teams get speed without losing governance.

Example Sync Record

{
  "provider": "github",
  "purpose": "iac",
  "branch": "ops0/generated-infrastructure",
  "pullRequestNumber": 42,
  "syncStatus": "synced",
  "lastSyncedCommitSha": "abc123"
}