Skip to content
Renart Docs

How it works

Renart stores authored definitions as files in your Git repository. The editor, canvas, and forms update those files. Execution history and deployment pins live in a separate local database; they are not part of the source you share.

Assets are files

Section titled “Assets are files”

Every asset is one file in your repository. For a SQL asset that file contains the query you write in the editor, plus the metadata you manage in the workbench — name, description, columns, quality checks, materialization — encoded in a structured section of the same file. Renart maintains that encoding for you: when you rename an asset, add a check, or change the materialization in the UI, Renart rewrites the file.

Use the editor and properties panel to change these settings. Adding a not_null check under Checks, for example, changes the asset definition in Git. You can review or revert it together with the query that produces the column; you do not need to edit the metadata encoding yourself.

The project is a folder

Section titled “The project is a folder”

The rest of what you see in the UI maps to files the same way:

  • A pipeline is a folder of asset files, with a pipeline.yml holding the pipeline’s name and defaults.
  • Connections and environments from Project settings live in the project config file at the workspace root.
  • Notebooks are folders of cell and source files plus an ordered manifest for text, controls, and visualizations.
  • Dashboards and reports are compact YAML definitions under dashboards/ and reports/; both the visual builder and Definition editor update the same file.
  • Tracked Renart project settings and desired environment schedules live in .renart/project.yml and .renart/schedules.yml.
  • Machine-local state that shouldn’t be shared — the scheduler database, deployment pins, deployed snapshots, and run history — lives in .renart/state.db, which is safe to gitignore.

Why it’s built this way

Section titled “Why it’s built this way”
  • Review and revert. A visual edit — moving a node, adding a check, changing a schedule’s pipeline — is a file change you can diff, review in a pull request, and revert like any other code.
  • Branching works. Pipeline work happens on branches, the same as the rest of your repository. Two people can work on different assets and merge.
  • Keep the source. If you stop using Renart, your queries, metadata, and pipeline structure remain readable files.
  • Tools compose. grep, code review, CI, backups — anything that works on files works on your pipelines.
Section titled “Related”