Try free

Git Sync

Your context layer, in a repo you own.

Git Sync moves your open-source Wren project to enterprise GenBI as plain YAML and Markdown. Keep authoring with git push, review metrics in pull requests, and deploy one governed answer to your team and every AI agent that calls Wren.

Request a demoRead the Git Sync docs
  • Plain git, no wrapper CLI
  • Open YAML and Markdown
  • GitHub, GitLab, Bitbucket, or your own remote
your-org/wren-analytics
Bound to Wren Cloud
RepositoryYAML and Markdown
  • wren_project.yml
  • models/
  • orders/metadata.yml
  • relationships.yml
  • knowledge/
  • glossary/
  • metrics/
  • rules/
  • sql/
Terminalnative git
$ git push
Enumerating objects: 12, done.
To cloud.getwren.ai/your-org/wren-analytics.git
9f2c1a4..b71e0d3 main -> main
deploy queued, model queryable in Wren Cloud
Plain git
Open formats
Enterprise-ready

Context layer as code, in the standard Wren project layout.

Trusted by data teams worldwide, with 17,799 GitHub stars

Why it matters

The context that makes AI answers correct shouldn't live in someone else's database.

Most AI-BI platforms keep your model, and everything the agent learns on top of it, inside their own storage. It works until the day you want it somewhere else. Git Sync writes the same context to a git repository you control, as plain, open files.

DimensionProprietary database storageWren Git Sync (open repo)
FormatVendor's internal schemaOpen MDL as YAML, knowledge as Markdown
PortabilityExport path is vendor-defined, often nonegit clone and walk, any time
Version historyWhatever the UI chooses to surfaceFull git history: every commit, author, and diff
PR review workflowNot availableStandard pull requests on GitHub, GitLab, or Bitbucket
Diffing changesScreenshot comparisongit diff two versions of a metric before you deploy
Backup custodyHeld by the vendorIn every clone your team already holds

This is what teams mean by CI/CD for BI: metric changes arrive as commits, get reviewed as pull requests, and promote from staging to production like application code.

How it works

From open-source project to governed GenBI.

A familiar path from local, version-controlled context models to production generative BI, without locking the context that makes answers correct inside a proprietary database.

  1. 1. Own the context

    Keep your source of truth open

    Models, relationships, business rules, metric definitions, and NL-to-SQL examples live as human-readable files in a repo you own. The compiled MDL is build output; what syncs is the YAML your team actually edits.

    knowledge/metrics/net_revenue.ymlyaml
    name: net_revenue
    label: Net revenue
    description: Revenue after refunds, before tax
    expression: SUM(orders.amount) - SUM(orders.refund_amount)
    owners: [finance-data]

  2. 2. Review every change

    Bring BI into your PR workflow

    Diff a metric, review it in a pull request, and promote it through staging and production like application code. A change to how a metric is defined shows up as a readable diff, not an opaque row in someone else's database.

    PR #142 fix: net revenue excludes refundsPull request
    @@ knowledge/metrics/net_revenue.yml @@
    name: net_revenue
    description: Revenue after refunds, before tax
    -expression: SUM(orders.amount)
    +expression: SUM(orders.amount) - SUM(orders.refund_amount)
    owners: [finance-data]
    2 approvals, CI metric validation passed

  3. 3. Serve trusted answers

    Deploy GenBI with governance

    Merge to the bound branch and a deploy makes the approved context layer queryable. Business users and AI agents get reliable SQL, charts, and analytics grounded in definitions your team reviewed.

    cloud.getwren.ai/your-org/wren-analyticslive
    push received on main (b71e0d3)
    context layer compiled: 38 models, 112 metrics
    deploy complete, model queryable
    > "What was net revenue by region last quarter?"
    ✔ grounded in net_revenue (PR #142)

No reusable credential, ever

Every push authenticates with a token that dies in 600 seconds.

The durable key stays on disk, locked down. What git presents on each operation is a freshly minted token that expires in ten minutes and is never written to disk or reused. A leak is worth ten minutes and nothing else.

600 sgit token lifetime
Three credentials, three lifetimes
  • org keyosk-
    long-lived
    Stored
    Passed through create's setup calls; not stored by it
    Used by
    create, or any project in the org via auth add
  • project keysk-
    long-lived
    Stored
    ~/.wren/cloud.yml, mode 0600
    Used by
    The credential helper, to buy git tokens
  • git tokenEd25519 JWT
    600 seconds
    Stored
    Never on disk, never reused
    Used by
    git itself, as a Basic-auth password

A credential helper, not a wrapper

git calls a standard credential helper on every operation. The helper trades the durable key for a fresh token and hands it back. No second code path to keep honest.

The remote is the binding

Nothing on the machine stores a directory-to-project mapping. The git remote already is that binding, and git manages remotes for you.

Caches are reset on purpose

git wants to store credentials after every operation. The config Wren writes resets the inherited helper chain so the ephemeral token is never kept on your behalf.

Git-native by design

Bind once. After that, it's just git.

Four commands cover onboarding. Which one you reach for depends only on whether the cloud project already exists. There is deliberately no wren push and no wren diff.

Create the project, connect a data source, mint a project key, configure git, bind the directory, and push, in one command. Your local YAML just has to compile.

terminalnew project
$ cd my-wren-project
 
$ wren cloud create --org 42 --type BIG_QUERY \
    --connection-info-file ./conn.json
  ✔ Created project 1234 (my-wren-project) on cloud.getwren.ai
  ✔ Minted project key at ~/.wren/cloud.yml (0600)
  ✔ Configured git credential helper for cloud.getwren.ai
  ✔ Bound this directory to project 1234, and pushed
  • Works with GitHub, GitLab, Bitbucket, or your own git remote
  • After binding, git push and git pull are the entire interface
  • Run CI on pull requests to validate a metric before it merges
  • A push to the bound branch queues a deploy that makes the model queryable
Step-by-step setup in the Git integration guide

Open source to enterprise

The same context, on the deployment your enterprise requires.

Start with Wren AI open source, then bring the same context-layer-as-code approach to collaborative cloud environments or a self-hosted enterprise deployment.

  1. Start

    Local project

    Wren AI open source

    Model your data, define metrics, and teach the agent in plain files on your laptop. Free, Apache-licensed, and yours.

    Open source and open core

  2. Sync

    git push to deploy

    Wren Cloud

    Bind the repo once. Managed hosting, collaboration, and the hardening that makes a deployment production-ready, over plain git.

    Compare plans

  3. Control

    Your network

    Self-hosted enterprise

    Bring the same files and the same review workflow to infrastructure you govern, including private and air-gapped environments.

    On-premise GenBI

Designed for governed analytics

Give AI the business definitions and rules it needs to generate useful, consistent answers, not just plausible SQL.

Designed for portability

Your team can read, diff, back up, and migrate the files that encode your data knowledge at any time.

FAQ

Git Sync questions, answered.

Your context model syncs as YAML (models/<name>/metadata.yml, relationships.yml, and cubes/ for pre-aggregations), and your knowledge base syncs as Markdown and YAML under a committed knowledge/ folder. The only JSON in a Wren project is target/mdl.json, compiled build output that isn't committed. Everything you author and review is plain, open, human-readable text.

Yes. Git Sync uses standard git against a repository you own, so it works with GitHub, GitLab, Bitbucket, or any git remote you already run. There's no proprietary transport: after a one-time bind, git push and git pull are the entire interface.

Yes. Because Git Sync is ordinary git, a git push is a normal push event your existing CI can react to: run validation on a pull request, diff a metric definition before it merges, and promote from staging to production the same way you ship application code. On the Wren side, a push to the bound branch queues a deploy that makes the updated model queryable.

No. The durable key lives at ~/.wren/cloud.yml with 0600 permissions and is only ever used to buy short-lived tokens. What git presents on each operation is a fresh Ed25519 JWT that expires in 600 seconds and is never written to disk or reused, so a leaked token is worth ten minutes and nothing more.

No. There is deliberately no wren push and no wren diff. You bind a directory to a cloud project once with wren cloud create or wren cloud link; from then on, plain git push and git pull do exactly what they always have. The full setup is in the Git integration guide.

Yes. The repository is yours, and the files in it are open Wren MDL in YAML plus knowledge in Markdown and YAML. You can read them, diff them, back them up, feed them to another tool, or clone the whole thing at any time. Wren Cloud is where the model becomes queryable and collaborative, not where it's trapped. Read the full design rationale in the Git Sync announcement.

See it in action

Bring your git workflow to every answer.

See how Wren AI helps your team ship governed analytics, in the cloud or self-hosted, without giving up control of the context layer.

Request a demoRead the announcement