Skip to content

Data Connections

dbt Charts Cloud

This page describes dbt Charts Cloud, the hosted product — these features are not part of the open source dct engine.

Dashboards never embed credentials; YAML names a source (source: warehouse) and Cloud resolves the name to a connection: warehouse credentials stored once at the organization level and shared across the org's projects. Only org admins manage connections.

Supported warehouses

dbt Charts only reads, so the credential you provide should be a read-only one, not the credential your dbt project builds with. See warehouse privileges for how to create one and grant it access.

Type You provide
PostgreSQL Host, database, username, password. Optional: port (5432 when blank), schema (public when blank). SSL is required by default.
Redshift Host, database, username, password. Optional: port (5439 when blank), schema (public when blank).
Snowflake Account, warehouse, database, username, password. Optional: schema (PUBLIC when blank).
BigQuery The service-account JSON key file: drop it on the form and the project fills itself in. List datasets shows the datasets that key can read, then pick one. The dataset's location is read from BigQuery, never typed.

Network access

Cloud queries your warehouse over the public internet, from one fixed address. The warehouse has to be reachable from there: a host on a private or internal network address is rejected when you save, and a warehouse reachable only through a VPN, a private endpoint, or an SSH tunnel cannot be reached at all.

If your warehouse restricts inbound traffic by address, allow:

34.85.252.27/32

Every query dbt Charts runs leaves from that address, so one rule covers every connection in your organization.

Where the rule goes depends on the warehouse:

Warehouse Where to add it
PostgreSQL Your provider's allowlist (Cloud SQL authorized networks, an RDS inbound security-group rule, an Azure firewall rule), and a pg_hba.conf entry as well if the server restricts by client address.
Redshift The cluster's security group, inbound on the port you connect to. The cluster also has to be publicly accessible.
Snowflake A network policy: add the address to its ALLOWED_IP_LIST.
BigQuery Nothing. BigQuery grants access through IAM rather than by address, so there is no inbound allowlist to edit. The one exception is a VPC Service Controls perimeter around the dataset, where the address belongs in an access level.

Allowing the address lets our traffic reach your warehouse; it does not authenticate it. The credential does that, so keep it scoped; see warehouse privileges.

Testing and saving

There is no separate test step. Save is the only action on the form, and saving is what tries the credentials against the warehouse — so the first signal you get is a saved connection that either passed or failed. The result is kept: each connection shows when it was last tested and whether it succeeded, and a failure shows the warehouse's own error beneath the form.

One case is neither pass nor fail. If the check cannot finish in time, the warehouse may still be starting up, so nothing was proved either way: the connection saves without recording a failure that never happened. A new connection reads "Not tested yet"; an edited one keeps its previous result until a check finishes. Re-check it once the warehouse is up.

The form keeps a failed connection because editing it here is one field and one click. dct cloud connection create has no edit verb, so it does the opposite: a test that fails outright saves nothing, and the retry is the same command once you have fixed whatever the printed error names. A test that could not finish in time is the exception. The warehouse may still be starting up, so nothing was disproved and the connection is kept. Re-run the check with dct cloud connection test <slug> rather than the create command, which would collide with the slug already taken.

To re-run the check on a saved connection, save it again (leaving a secret field blank keeps the stored value), or use Re-check readability on the connection's page, which re-runs the same authentication check.

A connection's edit form, showing when it was last tested and whether it passed

Mapping sources

Cloud reads the source names your project's dbt_charts.yml declares on your project's working branch, the branch Cloud edits and renders from. That file is the declaration, and it is the only place Cloud looks. A name a board writes as source: warehouse is a reference to a declaration, not one itself: if dbt_charts.yml never declares it, it appears nowhere on this page and every chart that uses it fails to compile, with the error pointing back here.

Each declared name that names a warehouse starts unmapped; queries against it can't run until an admin maps it to a connection. csv, json and parquet sources are never unmapped — they read files already in your repo, so there is nothing to connect them to. When you create a connection you can map pending sources to it in the same step, and a mapping can override the schema per source when one project needs a different schema than the connection's default.

Declarations live in git and mappings live in Cloud, so the two move on different clocks: a source appears here as soon as it lands on the working branch, and the connection you pick for it belongs to the project, not to the branch: it stays picked once that branch merges.

A warehouse source's credential fields in dbt_charts.yml (password:, keyfile:, or an env_var() standing in for one) are for rendering locally. Cloud ignores them; the connection you map here is what a render uses.

Mapping, re-mapping or unmapping a source re-renders the project's boards: a render resolves its sources when it runs, so every render made before the change is stale. A project's first render happens at sync, before anything is mapped, and its boards show ERR-SOURCE-NOT-FOUND until the mapping lands and that re-render completes. To re-render on demand, a project admin runs dct cloud render --force.

A project's source-mapping table, with one source mapped to a connection and one still unmapped

Because connections are org-level and mappings are per-project, two projects can point the same source name at different warehouses, or share one connection.

Pre-filling from dbt profiles

If the repo has a committed dbt profiles.yml, Cloud uses it to pre-fill the non-secret fields of a new connection: host, database, project, dataset, and so on. Credentials are never read from the repository; secrets are always entered directly in Cloud.

How credentials are handled

  • Credentials are encrypted at rest.
  • Secrets are write-only: passwords and keys are never displayed back, and leaving a secret field blank when editing keeps the stored value.
  • Connection management requires the org Admin role; which dashboards a member can query is governed separately by access control.
  • How much the credential can reach is up to you: warehouse privileges covers granting it read access to the tables your boards need, and nothing else.