Write Cloud service connection settings to .env

Open
  • Is something wrong?
#1,164 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@sdairs is already working on this.

Since Oct 30, 2026.

  • #1167 by @sdairs — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
clickhouse, rust
Domain
cli

Research direction

An open pull request (#1167) is already linked, so check its status before starting. If the work remains available, read the existing local dotenv commands and the Cloud service create/get flows to find the relevant entry points. Add the requested parsing, variable-builder, and request-shape tests; done means both commands work as specified, including password handling and write-failure fallback, and the Cloud service guide documents them.

Written by the indexing model from the issue text.

Description

cloud enhancement

Problem

The common agent flow is "create a Cloud service, then wire it into the application's .env". Local servers have local server dotenv and local postgres dotenv; Cloud has nothing. The agent has to read the endpoints from service get and copy the one-time password out of service create output by hand. That also puts the password in the agent's context and transcript.

The password is returned only by service create and service reset-password, so a later dotenv command can't include it.

Proposal

  1. cloud service create --dotenv [FILE] (default .env): after the service is created, write its connection settings and the one-time password to the file. When the file is written, leave the password out of stdout (human and JSON), so it never reaches the agent's context. If writing fails after the service was created, print the password as today and exit nonzero, so the credential is never lost.
  2. cloud service dotenv [ID] [--name NAME] [--local]: write the connection settings for an existing service, without a password. Runs with OAuth (read-only).

Keys, matching the local commands' meanings (CLICKHOUSE_PORT is the native port; see #800 for the mcp-clickhouse difference):

Key Value
CLICKHOUSE_HOST Host of the service's endpoints
CLICKHOUSE_PORT nativesecure port
CLICKHOUSE_HTTP_PORT https port
CLICKHOUSE_USER default
CLICKHOUSE_SECURE true (Cloud endpoints require TLS)
CLICKHOUSE_PASSWORD Only from create --dotenv

An existing file is edited in place, as the local commands do: only these keys are replaced, so a CLICKHOUSE_PASSWORD written at create time survives a later service dotenv.

The JWT database auth being researched could later supply a token through a helper command instead of a stored password; that is separate work.

Done when

  • Both are implemented with parsing tests, unit tests for the variable builder, and request-shape tests for the file contents, the password kept off stdout, and the write-failure fallback.
  • The Cloud service guide documents both.
Dominant language
Rust
Stars
80
Forks
9
Avg merge
2d 18h
Merged PRs (30d)
51

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ClickHouse/clickhousectl

All issues in ClickHouse/clickhousectl

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.