Data Connections¶
Dataface Cloud
This page describes Dataface Cloud, the hosted
product — these features are not part of the open source dft
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 and owners manage connections.
Supported warehouses¶
| 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. Test the connection to list the datasets that key can read, then pick one. The dataset's location is read from BigQuery, never typed. |
The warehouse must be reachable from the internet — connections to private or internal network addresses are rejected. (DuckDB is a local-development source for the open source engine, not a Cloud connection type.)
Testing and saving¶
You can test a connection before saving it — the credentials are tried against the warehouse without being stored. Saving runs the test again and keeps the result, so each connection shows when it was last tested and whether it succeeded; you can re-test any time.
Mapping sources¶
Cloud discovers source names from your project's dataface.yml and from the
face YAML files in faces/. Each discovered name starts unmapped —
queries against it can't run until an admin maps it to a connection. 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.
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 or Owner role; which dashboards a member can query is governed separately by access control.
Related¶
- Getting started — the full setup flow
- Sources — how the open source engine defines and uses sources in YAML