`dct cloud`¶

Operate dbt Charts Cloud from the terminal: connect a project's repository, wire up a warehouse connection, map sources, and render — the CLI surface behind the cloud-setup product skill.

dct cloud [OPTIONS] COMMAND [ARGS]...

Every verb accepts --json for machine-readable output and --host to target a non-default Cloud deployment (env var DCT_CLOUD_HOST). Most also resolve an org, and sometimes a project, from context rather than requiring --org/--project on every call — see Context resolution below.

Authentication¶

dct cloud login

Signs you in with the OAuth device grant: it opens the approval page in your browser (and prints the URL, for when it can't), you sign in (or create an account), pick or create the organization the CLI should reach, and approve. dct cloud login then stores the resulting token in the local config file (dct cloud use prints its path) — one browser approval, once per machine, and it covers every repository you work in and every organization you approved.

Unchecking an organization at the consent screen narrows what the token can reach; running dct cloud login again re-consents and replaces the stored credential. dct cloud logout revokes and clears it, and dct cloud whoami reports the host, where the credential came from, and what it can reach.

A token may also come from the DCT_CLOUD_TOKEN environment variable — the way CI and other agents authenticate without a browser. Every verb that needs a credential reads it from DCT_CLOUD_TOKEN first, then the config file. Run a read-only verb like dct cloud orgs to confirm it works.

The same token also reads board pages, so a script or an agent can check its own work rather than handing a URL to a person:

curl -H "Authorization: Bearer $DCT_CLOUD_TOKEN" \
  "$(dct cloud boards --json | jq -r '.boards[0].url')"

That is read-only: board pages, their .svg / .png / .pdf exports, and their render artifacts. It grants nothing the token's owner does not already have. See Access control for the exact bounds.

Context resolution: org and project¶

Resolution order for the org (and project, where a verb takes one):

Explicit --org (and --project) flags.
This repository's own published_to: record: a published_to: key in the nearest dbt_charts.yml above the current directory, written by a successful dct cloud project connect. It is the project's home URL, trailing slash included — published_to: "https://dbtcharts.com/acme-data/analytics/" — so pasting it into a browser opens the project. This only applies when neither --org nor --project is given.
This repository's git remotes, matched against the projects connected to your organizations. An unambiguous match wins even with no flag; two matches is an error naming both, so you pick.
The stored default from dct cloud use.
Otherwise, a loud error listing the orgs/projects you can choose from.

A published_to: naming a different host than the one this call is using (--host, DCT_CLOUD_HOST, or the configured default) is an error naming both hosts, not a silent skip to step 3: a stale or moved record is worth fixing, not working around quietly.

Destructive verbs are strict: dct cloud org delete, dct cloud project delete, dct cloud connection delete, dct cloud member remove, dct cloud invite revoke, and dct cloud grant revoke skip steps 2 and 4. Only an explicit flag or an unambiguous repo match can name what gets deleted, so a stale dct cloud use default can never silently pick which org, project, or connection loses its data. published_to: is skipped for the same reason: a fork of a connected repository carries the record verbatim, and unlike a git-remote match it does not correct itself in the fork, so honoring it would let a delete run in the fork remove the upstream project.

dct cloud project connect skips step 4 too, for a reason of its own: a repository being connected matches nothing yet (steps 2 and 3 answer nothing either, before the connect that would create the record), so the stored default would answer every time. A stale default would bind the repo into whatever org it happened to point at, so connect refuses instead and lists your orgs; pass --org. A successful connect then writes published_to: into the local dbt_charts.yml (printed to the terminal, with a reminder to commit it) so the next call in this repo resolves from step 2 instead of falling through to git-remote matching.

The write is verified, never assumed. Because the record outranks the git-remote match, connect writes it only when the checkout you are standing in really is the repository it just connected — its git remotes have to match. When they do not, when no dbt_charts.yml exists yet at the connected root, or when the file is one the splice cannot edit safely, connect prints the exact key and value to add by hand instead of writing. The project is already connected either way: a local write that cannot happen never takes the connect result (or its --json body) away from you.

Pin a default so routine verbs don't need --org/--project every time:

dct cloud use acme                  # org only
dct cloud use acme/analytics        # org and project

Secrets input¶

dct cloud connection create never takes a credential on the command line: --set refuses any field that carries one (password, credentials_json, private_key, private_key_passphrase), because a value on argv sits in shell history and the process list. Supply the credential through exactly one of:

Flag	Use for
`--keyfile FILE`	A key file — BigQuery's service-account JSON, Snowflake's private key
`--password-stdin`	A password typed or piped into stdin
`--password-env VAR`	A password already sitting in an environment variable

A connection whose test fails outright is reported as a failure and is not saved: the command exits non-zero, prints the warehouse's own error, and leaves nothing behind, so the retry is the same command once you have fixed whatever that error names.

A test that could not finish in time is different. The warehouse may simply still be starting up: a suspended Snowflake warehouse resumes on the first query, so the check disproved nothing and the connection is saved. The command still exits non-zero, and the error names the connection's slug and the dct cloud connection test <slug> command that re-runs the check once the warehouse answers. Re-running connection create in that state fails on the slug that already exists.

Automating setup¶

The whole Cloud onboarding runs from a script or a coding agent. A person is needed twice, to approve the login and to pick the repository on GitHub, and the --start/--wait split hands each of those to them without the script blocking. This example publishes a repository named analytics into a new acme organization, with its boards' source: warehouse backed by BigQuery:

# 1. Sign in: a person approves the printed URL.
dct cloud login --start
dct cloud login --wait

# 2. Create the organization.
dct cloud org create Acme --slug acme

# 3. Connect this repository: a person installs the GitHub App and picks it.
dct cloud project connect --org acme --start
dct cloud project connect --wait

# 4. Add a warehouse connection; the key comes from a file, never a flag.
dct cloud connection create --org acme --type bigquery --keyfile key.json \
    --set project=acme-gcp --set dataset=analytics

# 5. Point the boards' source at it (the slug `connection create` printed).
dct cloud source map warehouse acme-gcp --org acme --project analytics

# 6. Publish: pull the repository and render its boards.
dct cloud project sync --org acme --project analytics

# 7. Invite a teammate.
dct cloud member invite alex@acme.com --org acme --role creator

# 8. Confirm the boards are live.
dct cloud boards --org acme --project analytics

A few things the sequence relies on:

Step 3 needs --org. Connect never falls back to the dct cloud use default (see Context resolution). A public repository can skip the browser entirely: dct cloud project connect --org acme --git-url https://github.com/acme/analytics.git.
The project slug defaults to the repository name, analytics here; pass --slug to --start to choose another.
Connection fields depend on the warehouse. BigQuery needs --set project=... and --set dataset=... beside --keyfile; the server names any missing field. Password warehouses take --password-stdin or --password-env VAR instead. See Secrets input and Data connections.
Map sources before syncing. dct cloud sources lists the source names the project's boards declare. A board synced before its source is mapped renders without one.
Explicit --org and --project keep a script independent of what the checkout or the stored default would resolve to. At any point, dct cloud status --org acme names the next step still missing.
Every verb takes --json when a script needs to read the result.

In CI¶

A CI job cannot approve a browser login. Store a token as a CI secret and expose it as DCT_CLOUD_TOKEN; every verb reads that variable before the config file, so the job skips step 1. The token is the one a dct cloud login stored in the config file, and it reaches only the organizations approved at that login. dct cloud whoami confirms which ones before the job does anything else.

Command catalog¶

Setup¶

Command	Purpose
`login` / `logout` / `whoami`	Sign in, sign out, or check who you're signed in as
`use`	Set the default org (and project) for this machine
`status`	What's set up in an org, and what it needs next
`org create` / `delete`	Create or delete an organization
`project connect` / `sync` / `scaffold` / `delete`	Connect, sync, scaffold, or delete a project
`connection create` / `test` / `schema-refresh` / `delete`	Create, test, refresh, or delete a warehouse connection
`source map`	Point a board source at a connection
`render`	Start renders for boards that have none yet

Read-only listing¶

Command	Scope	Purpose
`orgs`	—	Organizations you belong to
`members`	org	The organization's members
`invites`	org	Pending invitations
`grants`	org	Live connector grants
`projects`	org	Projects connected to an organization
`connections`	org	Warehouse connections available in an organization
`boards`	project	A project's boards, render state, render time, served commit, and view URLs
`sources`	project	A project's declared sources and what backs them

Membership management¶

Command	Purpose
`member invite` / `remove` / `role`	Invite, remove, or change the role of a member
`invite revoke` / `resend`	Revoke or re-send a pending invitation
`grant revoke`	Revoke a connector grant

`dct cloud login`¶

dct cloud login [--host HOST] [--no-browser] [--start | --wait]

Runs the OAuth device grant against --host (default: the configured host). Opens the approval page in your browser and prints the same instruction (a URL to open, with a code to enter if the URL doesn't already carry it), then waits for you to approve. On a machine with no display (a Linux SSH session, say) it only prints; --no-browser forces that anywhere, and still waits. On success, prints the host and the organizations the new token can reach; the token itself is never printed. Running it again re-consents and replaces whatever credential was stored before. login refuses to run while DCT_CLOUD_TOKEN is set, since that token would outrank the one it stores.

Flag	Description
`--no-browser`	Print the approval URL instead of opening it in a browser
`--start`	Begin the login, print the approval URL, and exit without waiting for approval
`--wait`	Wait for a login begun with `--start` to be approved, then store the token
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

dct cloud login
dct cloud login --host https://selfhosted.example.com
dct cloud login --no-browser

Approving in a separate call¶

Bare login blocks until someone approves in the browser, which can take longer than the timeout a script or coding agent runs each command under. Split it into two calls instead:

URL=$(dct cloud login --start)
echo "Approve this login: $URL"
dct cloud login --wait

--start begins the grant, prints the approval URL on stdout with nothing around it, and exits without opening a browser. The pending grant is saved beside the config file, so --wait can pick it up from a separate process. Hand the URL to whoever approves; --wait then blocks until they do, stores the token, and prints the organizations it reaches, exactly as bare login finishes. Put --host on --start: --wait reads the host from the pending grant. With --json, --start emits host, verification_uri, verification_uri_complete, user_code, and expires_in instead of the bare URL.

--wait uses up the pending grant whether it succeeds or not. If the approval was denied or the code expired first (expires_in seconds), run --start again. A --wait with no pending grant is an error that points back at --start. Pass one of the two flags, never both.

`dct cloud logout`¶

dct cloud logout

Revokes the stored token and clears it from the config file. Refuses if DCT_CLOUD_TOKEN is set — that env var is the credential actually in effect, so unset it to log out.

`dct cloud whoami`¶

dct cloud whoami

Prints the host in use, whether the credential came from DCT_CLOUD_TOKEN or the config file, and the organizations (and your role in each) the credential can reach; the consented-orgs list is the answer to "what can this token do." Run inside a checkout with a published_to: record, it adds a PUBLISHED HERE column marking which of those organizations (and which project) this checkout is connected to, instead of leaving you to guess among however many the credential administers. That marking is a display detail of the human output: --json answers the same shape it always has, the one the HTTP API returns.

`dct cloud use`¶

dct cloud use ORG(/PROJECT)

Set the default org (and project) for commands run on this machine. Stored locally and never checked against Cloud — a slug that doesn't exist fails loudly on the next verb that uses it.

dct cloud use acme
dct cloud use acme/analytics

`dct cloud status`¶

dct cloud status [OPTIONS]

Readiness: what is set up in this org, and what it needs next. This is the verb the cloud-setup skill loops on — read its next-step instruction, run the verb it names, check status again, repeat until it reports nothing left to do.

The stages, in order: missing_project, unsynced, untested_connection, unmapped_sources, missing_boards, unrendered_boards, done. The org reports the earliest incomplete stage across its projects. A synced project with no boards on its branch is missing_boards, never done. Each project also gets a boards: line: total, ready, unrendered, rendering, failed, errored; done points at dct cloud boards for the URLs. The ready and errored counts print unknown, not 0, against a Cloud deployment older than the installed dct.

Flag	Description
`--org TEXT`	Organization slug (default: inferred, then `use`)
`--host TEXT`	Cloud deployment to talk to (default: the configured host) [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

Read-only listing verbs¶

orgs, members, invites, grants, projects, connections, boards, sources all follow the same shape: no arguments, --host and --json as above, plus --org (and, for the project-scoped ones, --project) — resolved per Context resolution when omitted. orgs takes no --org; it lists every organization the token belongs to.

dct cloud orgs
dct cloud members --org acme
dct cloud connections --org acme --json
dct cloud boards --org acme --project analytics
dct cloud sources --project analytics

boards carries the two facts that answer "is my change live":

SLUG            STATUS  RENDERED_AT       COMMIT   URL
exec-overview   ready   2026-09-06 10:50  8a2f27c  https://dbtcharts.com/acme/analytics/d/exec-overview
new-board       not_rendered  -           -        https://dbtcharts.com/acme/analytics/d/new-board

RENDERED_AT is when the board's latest render finished, in your own timezone. COMMIT is the commit that render read the board from, abbreviated to seven characters (--json carries the full SHA, and null for both when the board has no finished render).

A board you edited is live once its own two values move: read the listing before your push and again after the sync, and each board your commit changed gets a later RENDERED_AT and a different COMMIT. A board your commit did not change normally keeps both, because nothing re-renders content that did not change, so compare only the boards you touched.

Neither value moving means the re-render has not landed yet, not that the commit was dropped: a sync queues renders that run behind live page views and re-run each board's queries. A failed render writes no new complete render, so the two columns cannot move for one — they only ever prove success, and STATUS is what covers the rest. A warning that appeared since your first reading means the re-render ran and failed, since only a newer failed attempt puts a board there. A warning that was already there is inconclusive: it is undated, so it may be the old failure or a new one of your commit. An unchanged errored belongs to the render RENDERED_AT names, so it is the previous one's. A board still reading ready or not_rendered is waiting on its queued re-render; look again shortly, and run dct cloud project sync if you are unsure a sync ever ran.

COMMIT is a commit in Cloud's copy of your repository. For a project only ever edited through git that is your own commit, so it matches your git rev-parse HEAD; once boards are edited in Cloud too, its work branch carries those commits and the merge commits each sync creates, so the sha stops matching your HEAD and is Cloud's coordinate rather than yours. Either way, the sha changing is what tells you your content landed.

STATUS: ready alone means only that a render exists, not that it is a render of your edit. A board rendered before Cloud began recording commits shows -; those rows are never backfilled with a guess, and the column fills in the next time the board renders.

Board render statuses¶

boards reports each board's render_status, plus an error explaining it where there is something to explain:

Status	Meaning
`ready`	A render exists and every chart in it came back clean.
`errored`	The board rendered, but some charts came back as error cards. `error` carries the first chart diagnostic.
`warning`	The last render attempt failed outright. `error` carries that attempt's message.
`blocked`	A source this board names maps to a connection that has not passed its last test, so no render of this board can hold real data. `error` names the source and, for a connection your token may list, its slug, whether that connection failed its last test or has never been tested, and the `dct cloud connection test` command to run. It never carries the warehouse driver's own error text: run the named command to see that. A token holding only `dashboards:read` is told which source is blocked and to ask an organization admin, since a connection's slug is a connection fact.
`not_rendered`	No render has been started for this board yet.

blocked outranks the render-derived values: a connection that never answered means the board's contents are not trustworthy no matter what the last render did, and re-rendering will not change that. The block is per board: a sibling board over a passing connection, or over a csv/json/parquet file in the repo, is not blocked and render starts it. A board that names no source: at all resolves through the default it inherits, so it is judged against every source its project maps. Fix the connection first:

dct cloud connection test prod-dwh

`dct cloud render`¶

dct cloud render [OPTIONS]

Start renders for the project's boards that have none yet, or all of them. It reports how many it started and how many are still unrendered. A board over a connection that has not passed its last test is skipped, and the command prints which connection to test, so a count of zero is never the whole answer. Boards over passing connections and repo file sources start regardless.

Flag	Description
`--force`	Re-render every board with fresh query results, including ones that already rendered — the lever for a board that stays errored after its source was mapped or its warehouse fixed. Needs project admin.
`--org TEXT`	Organization slug (default: inferred, then `use`)
`--project TEXT`	Project slug (default: inferred, then `use`)
`--host TEXT`	Cloud deployment to talk to (default: the configured host) [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

`dct cloud org create`¶

dct cloud org create [OPTIONS] NAME

Create an organization. You become its admin.

Argument	Description
`NAME`	Display name for the organization

Flag	Description
`--slug TEXT`	URL slug (default: from the name)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

dct cloud org create Acme
dct cloud org create Acme --slug acme

`dct cloud org delete`¶

dct cloud org delete [OPTIONS]

Delete an organization and all its data. Refused while it has projects.

Flag	Description
`--org TEXT`	Organization slug (inferred from this repo, else required; never the `use` default)
`--yes`	Skip the confirmation prompt (required, non-interactively)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

Strict org resolution applies (see Context resolution); the resolved coordinate is printed before deleting. Without --yes, an interactive terminal is asked to type it back to confirm; a non-interactive run is refused outright.

`dct cloud project connect`¶

dct cloud project connect [OPTIONS]

Connect a GitHub repository as a project. Two paths:

--git-url URL — fully headless; public GitHub repos only.
Default (no --git-url) — prints a URL, waits for you to install the GitHub App and pick the repository in the browser, then finishes here. This browser pick isn't bypassable: Cloud authorizes it from your own GitHub account's list of repositories you administer.

Connect never uses the stored dct cloud use default: binding a repository to an organization is not something to guess from a setting that was never checked against Cloud. Pass --org; it is only optional when this repository is already connected to exactly one organization (re-connecting, or a second project from the same repo).

Flag	Description
`--git-url TEXT`	Connect a public GitHub URL, with no browser hop
`--root TEXT`	Folder holding `dbt_project.yml` inside the repo
`--trunk TEXT`	Branch Cloud pulls from (default: the repo's)
`--name TEXT`	Project name (default: the repo's)
`--slug TEXT`	Project slug (default: from the name)
`--timeout FLOAT`	Seconds to wait for the browser repo pick (default: `300.0`)
`--poll-interval FLOAT`	Seconds between pick checks (default: `3.0`)
`--start`	Print the install/pick URL and exit without waiting for the pick
`--wait`	Wait for a connect begun with `--start` to finish
`--org TEXT`	Organization slug (inferred from this repo, else required; never the `use` default)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

dct cloud project connect --org acme
dct cloud project connect --git-url https://github.com/acme/analytics.git --org acme

Picking the repository in a separate call¶

The browser path blocks for up to --timeout seconds while someone installs the GitHub App and picks the repository. A script or agent that cannot wait that long splits it the same way as login:

URL=$(dct cloud project connect --org acme --start)
echo "Install the GitHub App and pick the repository: $URL"
dct cloud project connect --wait

--start resolves the org, prints the install/pick URL on stdout with nothing around it, and exits. It saves the pending connect together with any --name, --slug, --trunk, and --root you passed, so give those to --start: --wait takes the org, host, and those values from what --start saved. --wait polls for the pick for up to --timeout seconds, then creates the project and records published_to: just as the blocking form does. A --wait that times out keeps the pending connect, so running it again resumes the same pick. With --json, --start emits org and url.

Neither flag combines with --git-url, which has no browser step to split, and you pass one of the two, never both.

`dct cloud project sync`¶

dct cloud project sync [OPTIONS]

Pull the project's repository and refresh its branches, and re-render the boards the new commits changed.

A git push does not publish; this does. A push puts your commit on your git host, and Cloud serves it only after a sync. A GitHub App project syncs itself within seconds of the push (a webhook), with a daily reconcile behind it; a project connected by repository URL has nothing watching the remote, so its only automatic sync is an hourly sweep. Running this verb publishes immediately in both cases.

The sync runs in the background, so this verb reports what it queued rather than a finished result. Confirm the landing with dct cloud boards: each board your commit changed gets a new RENDERED_AT and a new COMMIT once its re-render finishes.

Flag	Description
`--org TEXT`	Organization slug (default: inferred, then `use`)
`--project TEXT`	Project slug (default: inferred, then `use`)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

`dct cloud project scaffold`¶

dct cloud project scaffold [OPTIONS]

Open the dbt_charts.yml scaffold PR. GitHub-connected projects only.

Flag	Description
`--org TEXT`	Organization slug (default: inferred, then `use`)
`--project TEXT`	Project slug (default: inferred, then `use`)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

`dct cloud project delete`¶

dct cloud project delete [OPTIONS]

Delete a project and all its data.

Flag	Description
`--org TEXT`	Organization slug (inferred from this repo, else required; never the `use` default)
`--project TEXT`	Project slug (default: inferred, then `use`)
`--yes`	Skip the confirmation prompt (required, non-interactively)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

Strict project resolution applies (see Context resolution).

`dct cloud connection create`¶

dct cloud connection create [OPTIONS]

Create a connection and test it in one call. Non-secret fields go in --set; which ones a type needs is the server's answer, and it names any that are missing:

dct cloud connection create --type bigquery --keyfile key.json \
    --set project=acme-gcp --set dataset=analytics

Key material is never a flag value — see Secrets input above.

Every later verb addresses the connection by its slug, which is the slugified --name. Leave --name off and the display name defaults to the field that names the warehouse — BigQuery's project, otherwise the database — and a successful create prints the slug it derived:

Created acme-gcp — connection test passed.
Next: dct cloud source map <source> acme-gcp

A test that fails outright saves nothing, so a retry, after you fix whatever the error names, is the same command; there is no slug left over to collide with, and no connection delete to run first. A test that could not finish in time does keep the connection. Re-run the check with dct cloud connection test <slug> rather than re-running connection create, which would collide with the slug already taken.

Flag	Description
`--type TEXT`	Warehouse type, e.g. `bigquery`, `snowflake` (required)
`--set KEY=VALUE`	A connection field, repeatable (e.g. `--set dataset=analytics`); not `name`, which is `--name`, and not a credential
`--keyfile FILE`	File holding the service-account key or private key
`--password-stdin`	Read the password from stdin
`--password-env VAR`	Env var holding the password
`--name TEXT`	Display name; its slug is the connection's id (default: BigQuery's project, otherwise the database)
`--org TEXT`	Organization slug (default: inferred, then `use`)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

Per-warehouse field names and security notes: Data connections.

`dct cloud connection test`¶

dct cloud connection test [OPTIONS] CONNECTION

Ask Cloud to re-run a connection's credential check.

Argument	Description
`CONNECTION`	Connection slug, as `dct cloud connections` lists it

Flag	Description
`--org TEXT`	Organization slug (default: inferred, then `use`)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

`dct cloud connection schema-refresh`¶

dct cloud connection schema-refresh [OPTIONS] CONNECTION

Re-run a connection's schema profile.

Argument	Description
`CONNECTION`	Connection slug, as `dct cloud connections` lists it

Flag	Description
`--org TEXT`	Organization slug (default: inferred, then `use`)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

`dct cloud connection delete`¶

dct cloud connection delete [OPTIONS] CONNECTION

Delete a warehouse connection. Boards that query it start failing.

Argument	Description
`CONNECTION`	Connection slug, as `dct cloud connections` lists it

Flag	Description
`--yes`	Skip the confirmation prompt (required, non-interactively)
`--org TEXT`	Organization slug (inferred from this repo, else required; never the `use` default)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

Strict org resolution applies (see Context resolution).

`dct cloud source map`¶

dct cloud source map [OPTIONS] SOURCE CONNECTION

Point one declared source at a connection. Omitting --schema preserves whatever override the source already has; --schema "" clears it deliberately.

Argument	Description
`SOURCE`	Source name a board's `source:` uses
`CONNECTION`	Connection slug to point it at

Flag	Description
`--schema TEXT`	Schema this source resolves against
`--org TEXT`	Organization slug (default: inferred, then `use`)
`--project TEXT`	Project slug (default: inferred, then `use`)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

dct cloud source map warehouse acme-bigquery --org acme --project analytics
dct cloud source map warehouse acme-bigquery --schema staging

`dct cloud member`¶

dct cloud member invite [OPTIONS] EMAIL
dct cloud member remove [OPTIONS] EMAIL
dct cloud member role [OPTIONS] EMAIL ROLE

Command	Arguments	Purpose
`invite`	`EMAIL`	Invite one address to the organization (`--role TEXT` to set the role on acceptance)
`remove`	`EMAIL`	Remove a member from the organization
`role`	`EMAIL ROLE`	Change a member's role

Each also takes --org, --host, and --json as above.

dct cloud member invite alex@acme.com --role admin
dct cloud member role alex@acme.com admin
dct cloud member remove alex@acme.com

`dct cloud invite`¶

dct cloud invite revoke [OPTIONS] EMAIL
dct cloud invite resend [OPTIONS] EMAIL

Command	Arguments	Purpose
`revoke`	`EMAIL`	Revoke a pending invitation
`resend`	`EMAIL`	Re-send a pending invitation

Each also takes --org, --host, and --json as above.

`dct cloud grant revoke`¶

dct cloud grant revoke [OPTIONS] GRANT_ID

Revoke a connector grant. May cut the credential making this call.

Argument	Description
`GRANT_ID`	Grant id, as `dct cloud grants` lists it

Flag	Description
`--org TEXT`	Organization slug (default: inferred, then `use`)
`--host TEXT`	Cloud deployment to talk to [env var: `DCT_CLOUD_HOST`]
`--json`	Emit the raw API response as JSON

Getting Started with Cloud: the guided walkthrough this CLI drives
Data connections: warehouse types, per-field connection details, and security notes
Access control: org roles referenced by member role

dct cloud¶

Authentication¶

Context resolution: org and project¶

Secrets input¶

Automating setup¶

In CI¶

Command catalog¶

Setup¶

Read-only listing¶

Membership management¶

dct cloud login¶

Approving in a separate call¶

dct cloud logout¶

dct cloud whoami¶

dct cloud use¶

dct cloud status¶

Read-only listing verbs¶

Board render statuses¶

dct cloud render¶

dct cloud org create¶

dct cloud org delete¶

dct cloud project connect¶

Picking the repository in a separate call¶

dct cloud project sync¶

dct cloud project scaffold¶

dct cloud project delete¶

dct cloud connection create¶

dct cloud connection test¶

dct cloud connection schema-refresh¶

dct cloud connection delete¶

dct cloud source map¶

dct cloud member¶

dct cloud invite¶

dct cloud grant revoke¶

Related¶