Managing connections

A connection tells Renart how to reach a data platform — a local DuckDB file, a Postgres database, a Snowflake or Databricks warehouse, or S3-compatible or Google Cloud Storage. An environment is a named set of connections (for example default and production) so the same pipeline can run against different targets.

Manage both from the Connections and Environments tools in Build. They are also available through Project settings.

Add a connection

1. Open Build → Connections and click New connection, or the + beside an environment.
2. Choose its environment, database or storage type, and a name such as pg-analytics.
3. Enter the connection details. Open Credentials for secret fields and Advanced for tuning options.
4. Choose Access → Read-only if Renart should only read from this connection.
5. Click Verify to test the draft, then Create connection. The saved connection stays open.

Assets refer to connections by name. Choose the connection in the asset’s General properties; set defaults through Pipeline settings.

Import tables from a database

To start from tables that already exist, click Connect and import tables on the Connections overview, or Connect a database in the Data Browser before you choose a table.

1. Choose the database or warehouse and enter its details.
2. Click Test connection. Renart lists the tables it can read.
3. Click Choose tables, which saves the connection, then select tables by schema and the pipeline to add them to.
4. Click Import. Each table becomes a source asset on the pipeline canvas, ready for SQL assets that read from it.

New projects offer the normal database and storage connections. Ingestr-only types are hidden unless creation is explicitly enabled in project settings. Existing legacy connections remain editable; their presence does not enable Ingestr suggestions for new assets or connections.

Sensitive values are write-only. By default Renart stores a replacement in the operating system’s credential store and keeps only a symbolic placeholder in the project config. The connection editor also supports an encrypted local vault for interactive SSH or headless sessions and environment-variable bindings for CI and unattended runs. See Manage connection credentials for the complete setup, rotation, and recovery guidance.

Find and edit a connection

The sidebar groups connections by environment. Filter by connection name, type, or environment, then select a row to open its editor in the main area. On a phone, tap Connections again to reopen the navigator; selecting a row closes it.

Click Save changes when ready. If you navigate away with a draft, choose Save and continue, Discard, or Stay. A failed save keeps your draft. Links from diagnostics open the relevant field in this same editor, including when you open the link in a new tab.

Shared configuration

A nested project can inherit its connection definitions from another directory. Renart shows the destination and asks you to Allow editing shared configuration before saving there. Those changes can affect other projects using that configuration.

Environments

In Build → Environments, select an environment in the sidebar or click New environment. Edit its name, schema prefix, default status and execution guardrails in the main area. Clone copies an environment’s connections and guardrails. Its connection links open the corresponding connection editors.

Selecting an environment here does not change where queries or pipelines run. Use Use for execution, or the execution picker in the top bar, to switch the active target. Default environment is a separate saved setting, used when no explicit environment is selected. Schedules remain per environment: the same pipeline can run nightly against default and on weekday mornings against production.

Execution guardrails

Execution policy in an environment’s editor sets its guardrails. They apply when you choose Save changes, and Renart enforces them for every run in that environment, whether it starts from the workspace, the terminal or a schedule.

Guardrail	What it does
Protected	Blocks runs you start yourself in the workspace or terminal. Materialize is disabled with This environment is protected: interactive execution is disabled. Scheduled runs still run.
Deployed only	Runs only deployed versions. Review run runs the latest deployment instead of your working files, and runs from the working tree are rejected, including scheduled runs without a deployment.
Confirm destructive operations	Requires typing the environment name before a destructive run, such as a full refresh or a backfill.

A typical setup leaves default open for development and marks production Deployed only, so production only runs versions you reviewed and deployed. See Deployments & scheduling for how deployments are created and pinned.

Read-only connections

Use Access → Read-only for a production database that Renart should read without changing. The setting belongs to the connection in the selected environment: the same name can remain writable in development.

You can browse its tables, preview data, and add tables to the canvas as Source assets. Source assets describe existing tables; you can still edit their columns and descriptions. To transform the data elsewhere, add a Load asset downstream and choose a writable destination.

Read-only connections are not offered as materialization or Load destinations. Existing assets that write there are blocked rather than moved to another connection. Code checks explain the conflict and link to the connection’s Access setting. Verified single-query reads are allowed; DDL, DML, scripts, write hooks, and opaque operators are not.

When editing an existing connection, choosing Read-only shows a collapsible preview of affected saved assets. Deployed versions are checked when they run, too. New tasks use the saved access mode, but operations already in progress may finish. Review and cancel active runs separately if necessary.

Use database permissions as well

This setting restricts operations managed by Renart. It does not change your database account’s grants or sandbox arbitrary code. Use credentials with read-only database permissions when the source must be protected outside Renart too. Another writable connection to the same database can still change it.

Existing native DuckDB read-only settings remain effective even if Access is set to Read and write. Read-only DuckLake connections are not supported yet; Renart refuses to initialize them rather than opening them in a writable mode.

Supported platforms

SQL targets include DuckDB, PostgreSQL, ClickHouse, StarRocks, Trino, Snowflake, BigQuery, and others. See the platform reference for the complete SQL list and materialization limits. Storage connections such as S3 and GCS are separate from SQL targets.

Keep legacy inline credentials private

Newly replaced sensitive values use a write-only credential source. Existing inline values remain readable for compatibility until you replace them, so keep any project config containing them private and out of version control. Renart does not fall back to plaintext storage.

Related

• Manage connection credentials
• Scheduling
• Security and privacy