# Managing connections

> Point Renart at your warehouses and organize them into environments.

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](https://getrenart.com/docs/connections-environments/managing-credentials.md) 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](https://getrenart.com/docs/scheduling/overview.md) 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](https://getrenart.com/docs/asset-types/load-assets.md) 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](https://getrenart.com/docs/reference/supported-platforms.md) 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](https://getrenart.com/docs/connections-environments/managing-credentials.md)
- [Scheduling](https://getrenart.com/docs/scheduling/overview.md)
- [Security and privacy](https://getrenart.com/docs/reference/security-and-privacy.md)