Skip to main content
Two-way sync is what separates Nometria from a simple export tool. It means your AI builder and your production Git repo stay in sync — in both directions — indefinitely.

The problem it solves

When you deploy from a vibe coder, you have two sources of truth that can conflict:
  1. Your builder — where you keep iterating with AI prompts
  2. Your GitHub repo — where developers make code changes directly
Without two-way sync, these diverge. A change in the builder overwrites what a developer fixed. A developer’s change never flows back into the builder’s awareness. You end up manually reconciling two copies of the same codebase. Two-way sync uses Git branches as a coordination layer to solve this.

How it works

Nometria maintains a canonical Git repository as the single source of truth between your builder and your infrastructure.
AI Builder (Base44, Lovable, etc.)

        │ Chrome Extension detects change

  builder/latest branch

        │ Auto-merge (no conflicts) or PR (conflicts)

      main branch ◄─── Developer commits & PRs

        │ GitHub webhook notifies Nometria

  Production deploy on EC2
Builder changes always land on builder/latest. They never touch main directly. Developer changes happen on main or feature branches, via pull requests. Nometria watches both. When builder/latest has new commits:
  • If there are no conflicts with main → auto-merge (optional, configurable)
  • If there are conflicts → a PR is opened with conflict markers for you to resolve
When main gets a new commit → Nometria triggers a production redeploy.

Why this branch strategy works

The key insight is isolation by branch. The builder never directly touches main. Developers never touch builder/latest. Nometria acts as the merge coordinator. This means:
  • A bad AI prompt can’t directly break production — it lands on builder/latest first
  • Developers can work on main without worrying about the builder overwriting their work
  • Every change — from builder or developer — is a Git commit with full history and rollback

Configuration via .Nometria.yml

Fine-tune sync behavior by adding .Nometria.yml to your repo root:
sync:
  builder_branch: builder/latest    # Branch where Chrome Extension pushes
  deploy_branch: main               # Branch that triggers production deploy
  auto_merge: true                  # Auto-merge builder/latest → main when no conflicts
  auto_deploy_on_merge: true        # Deploy to production after every merge to main
  ignored_paths:                    # Paths the extension ignores (won't commit)
    - "docs/**"
    - "*.md"
    - ".github/**"
  preview:
    enabled: true                   # Create a preview URL for every builder push
    ttl: 72h                        # Preview URL lifetime
This file is version-controlled in your repo, so your sync configuration has history too.

What two-way sync gives you

Once set up, you get professional engineering workflows on top of your vibe-coded app:
  • Rollback — every builder change is a commit; revert to any previous state with one click
  • Staging vs productionbuilder/latest previews deploy to staging; main goes to production
  • Code review — PRs give you a diff of every builder change before it touches production
  • Audit trail — compliance and debugging both benefit from a complete commit history
  • Developer collaboration — contractors and teammates can open PRs without needing builder access

Day-to-day workflow

How to use two-way sync while actively building

Handling conflicts

What to do when builder and developer changes clash