Account Resources YAML Reference Beta

This guide serves as a detailed reference for the CLI project YAML files that contain definitions of your Reverse ETL warehouse account resources.

Account support requires Rudder CLI v0.25.0 or later.

Upgrade if you are using an earlier version.

Overview

An account holds the credentials and connection settings for a data warehouse. A Reverse ETL SQL model does not carry its own credentials — it points at an account through its account_id. Defining accounts in YAML keeps warehouse credentials under the same Git-based workflow as your other CLI resources.

You define accounts by setting kind to account. As with every other resource type, you can store the YAML files anywhere within the project’s root directory or subdirectories.

Account specs reference secrets as variables, so pass --var-file when you apply them. See How to Use Variable Substitution in Rudder CLI.

Account resources

The spec parameter of the YAML file has the following structure:

account_definition_name is immutable. Changing it on an existing account fails the apply rather than silently recreating the resource — a warehouse account is a credential, and recreating one would break every Reverse ETL source pointing at it. To move to a different warehouse type, define a new account.

Supported account definitions

BigQuery configuration

The config object for SOURCE_BIGQUERY accepts the following keys:

Although config is a single flat map in YAML, it is split on the way to the API — the secret keys are sent as a write-only credential payload and everything else as plain options. You do not need to model that split yourself.

Example definition

version: "rudder/v1"
kind: "account"
metadata:
  name: "prod-bq"
spec:
  id: "prod-bq"
  name: "Production BigQuery"
  account_definition_name: "SOURCE_BIGQUERY"
  config:
    project: "acme-analytics-prod"
    location: "US"
    credentials: "{{ .BQ_CREDENTIALS }}"

With a var file (credentials.vars.yaml) alongside it:

BQ_CREDENTIALS: '{"type":"service_account","project_id":"acme-analytics-prod","private_key":"..."}'

Apply the two together:

rudder-cli apply --location ./project --var-file ./credentials.vars.yaml

PostgreSQL configuration

The config object for SOURCE_POSTGRES accepts the following keys:

version: "rudder/v1"
kind: "account"
metadata:
  name: "prod-postgres"
spec:
  id: "prod-postgres"
  name: "Production Postgres"
  account_definition_name: "SOURCE_POSTGRES"
  config:
    host: "warehouse.acme.internal"
    dbname: "analytics"
    user: "rudderstack"
    port: "5432"
    sslMode: "require"
    password: "{{ .PG_PASSWORD }}"

Snowflake configuration

The config object for SOURCE_SNOWFLAKE accepts the following keys:

authenticationType decides which secret keys are legal. The combination is validated rather than ignoring surplus keys:

• keyPair accepts only privateKey and privateKeyPassphrase.
• password accepts only password.

Supplying a secret that does not belong to the selected authentication type — for example, a password alongside authenticationType: keyPair — is rejected, not silently dropped.

version: "rudder/v1"
kind: "account"
metadata:
  name: "prod-snowflake"
spec:
  id: "prod-snowflake"
  name: "Production Snowflake"
  account_definition_name: "SOURCE_SNOWFLAKE"
  config:
    account: "acme-prod.us-east-1"
    dbname: "ANALYTICS"
    warehouse: "TRANSFORMING"
    user: "RUDDERSTACK"
    role: "RUDDERSTACK_ROLE"
    authenticationType: "keyPair"
    privateKey: "{{ .SF_PRIVATE_KEY }}"
    privateKeyPassphrase: "{{ .SF_PRIVATE_KEY_PASSPHRASE }}"

version: "rudder/v1"
kind: "account"
metadata:
  name: "prod-snowflake"
spec:
  id: "prod-snowflake"
  name: "Production Snowflake"
  account_definition_name: "SOURCE_SNOWFLAKE"
  config:
    account: "acme-prod.us-east-1"
    dbname: "ANALYTICS"
    warehouse: "TRANSFORMING"
    user: "RUDDERSTACK"
    role: "RUDDERSTACK_ROLE"
    authenticationType: "password"
    password: "{{ .SF_PASSWORD }}"

Secret handling

Secret fields must be written as {{ .VARIABLE_NAME }} references, not literals.

See How to Use Variable Substitution in Rudder CLI.

Import existing accounts

You can bring warehouse accounts created through the dashboard under Git control:

rudder-cli import workspace --location ./project

This scaffolds two things under ./project/imported:

• accounts/<id>.yaml — one spec per importable account, with every secret field masked to a {{ .VAR }} reference.
• secrets.vars.yaml — a fill-in-the-blanks var file with one placeholder line per variable the generated specs reference.

Fill in each placeholder with the real credential, then run apply with --var-file to adopt the accounts. Import scaffolds the files; the accounts are claimed on apply, after which they are managed resources and are no longer offered for import.

See Fill placeholders after import for how placeholders and empty values behave.

You can list the accounts in your workspace, managed or not, with:

rudder-cli workspace accounts list

See more

• SQL Model Resources YAML Reference — SQL models reference accounts through account_id
• How to Use Variable Substitution in Rudder CLI — var files and secret fields
• How to Import Workspace Resources into Your Rudder CLI Project — general import workflow