@serve.zone/cli

@serve.zone/cli is the published Cloudly CLI submodule. It provides the servezone binary and currently acts as a thin environment-driven client for connecting to a Cloudly control plane and listing clusters through @serve.zone/api.

Issue Reporting and Security

For reporting bugs, issues, or security vulnerabilities, please visit community.foss.global/. This is the central community hub for all issue reporting. Developers who sign and comply with our contribution agreement and go through identification can also get a code.foss.global/ account to submit Pull Requests directly.

Current Scope

This submodule is intentionally small in the current codebase:

• Reads CLOUDLY_URL through @push.rocks/qenv.
• Authenticates with either CLOUDLY_TOKEN or CLOUDLY_USERNAME plus CLOUDLY_PASSWORD.
• Starts a CloudlyApiClient registered as cli.
• Creates a CliClient wrapper around the API client.
• Without arguments, calls CliClient.getClusters() and prints the result.
• Runs servezone gateway bootstrap and servezone gateway status for Cloudly's dcrouter gateway enrollment.
• Runs servezone relay export-authorization to write a cluster relay's bearer to a private file.
• Runs servezone corestore set-control-token and servezone corestore control-token-state for the Corestore control token the cluster relays use.

It is not currently a full command tree for services, secrets, deployments, logs, profiles, or shell completion. Those flows should be implemented against @serve.zone/api before documenting them as CLI commands.

Installation

Every Cloudly release publishes the package from cloudly/ts_cliclient, through its tspublish.json, under the name @serve.zone/cli with the servezone binary and at the Cloudly version. Its registry versions therefore jump from 5.5.1 to Cloudly's 32.x line.

pnpm add --global @serve.zone/cli

For local development inside the Cloudly repository, build the parent package:

pnpm install
pnpm build

Usage

Authenticate with a machine token:

CLOUDLY_URL=https://cloudly.example.com \
CLOUDLY_TOKEN=cluster-or-api-token \
servezone

Authenticate with username and password:

CLOUDLY_URL=https://cloudly.example.com \
CLOUDLY_USERNAME=admin \
CLOUDLY_PASSWORD=change-me \
servezone

When CLOUDLY_TOKEN is present, the CLI exchanges it for an identity and tags the WebSocket with a JWT-only credential. Cloudly verifies the JWT and reconstructs authoritative identity fields from persisted user data. Machine JWTs never outlive their source tokens, and cluster machine users must belong to exactly one persisted cluster. When username/password are present instead, the CLI uses Cloudly's admin login flow. If no credentials are provided, it prints a warning before attempting the default cluster-list operation.

Gateway Enrollment

Cloudly enrolls itself at dcrouter as one gateway client, with a dcrouter admin token an administrator hands in once. Both commands sign in exactly as the default action does and need an administrator identity.

# Mint a short-lived admin token at dcrouter first, then pipe it in:
CLOUDLY_URL=https://cloudly.example.com \
CLOUDLY_USERNAME=admin CLOUDLY_PASSWORD=change-me \
servezone gateway bootstrap --gateway-url https://gateway.example.com --client-id cloudly.example.com < admin-token.txt

servezone gateway status

• gateway bootstrap --gateway-url <https url> --client-id <id> names Cloudly's dcrouterGatewayUrl and dcrouterGatewayClientId as its settings state them; Cloudly refuses any other target. The admin token is read from stdin and from nowhere else: an argument, --token, or any other extra argument is refused as usage without echoing it, and the environment is never read for it. stdin must not be a terminal. One trailing line break (\n or \r\n) is stripped; what remains must be 1 to 1024 bytes of visible ASCII. The token is checked before anything connects, sealed by @serve.zone/api for Cloudly, and wiped afterwards. The command prints the resulting enrollment state as JSON and exits 0; a refusal (External gateway bootstrap refused: <refusal>.) or a refused stdin is printed to stderr with exit code 1.
• gateway status prints the current enrollment state as JSON.

Revoke the admin token at dcrouter once gateway status reads ready.

Relay Bearer Export

relay export-authorization hands a cluster relay's bearer to the operator who deploys that relay, without any access to Cloudly's process. It needs an administrator who signed in within the last five minutes.

install -d -m 0700 /root/relay-export
CLOUDLY_URL=https://cloudly.example.com \
CLOUDLY_USERNAME=admin CLOUDLY_PASSWORD=change-me \
servezone relay export-authorization --cluster-id <clusterId> --expected-generation <n> \
  --output /root/relay-export/relay-authorization

• --expected-generation is the exact generation getClusterRelayCredential answered (a positive integer without leading zeros); Cloudly refuses any other one by name (relay-credential-generation-mismatch), so a rotation that committed in between is never exported by accident.
• --output must be a normalized absolute path. Its directory must exist, resolve to itself (no symbolic link on its path), be owned by you and be writable by neither its group nor other users, and nothing may exist at the path yet. Otherwise the command refuses (output-directory-missing, output-directory-not-private, output-exists) before it asks Cloudly, so no bearer is fetched and no audit receipt is written.
• The bearer is fetched with @serve.zone/api (cluster.exportClusterRelayAuthorization, which checks the answer against the request) and written with @push.rocks/smartfs as a new file, mode 0600 whatever the umask, exclusive and atomic: the whole bearer or no file, never over an existing entry and never through a symbolic link at the path.
• It is never written to stdout. stdout carries one JSON line of metadata: clusterId, generation, outputPath, byteLength, sha256 (what sha256sum prints for the file) and receiptId, the audit receipt Cloudly recorded. A refusal is printed to stderr with exit code 1 and never carries the bearer.

Corestore Control Token

Every cluster relay calls its nodes' Corestore control API with one control token, which Cloudly stores for both Corestore provider configs. These commands set and read it over the API, without any access to Cloudly's process. Both sign in exactly as the default action does; the set needs an administrator who signed in within the last five minutes.

CLOUDLY_URL=https://cloudly.example.com \
CLOUDLY_USERNAME=admin CLOUDLY_PASSWORD=change-me \
servezone corestore control-token-state

# Pipe the token in, naming the state the read answered:
servezone corestore set-control-token --stdin --expect absent < control-token.txt
servezone corestore set-control-token --stdin --expect 3 < control-token.txt

• control-token-state prints one JSON line: {"ok":true,"command":"corestore control-token-state","state":…,"receipts":[…]}. state is {"state":"absent"} or {"state":"present","revision":<n>}; receipts are the value-free audit receipts (id, revision, via, actorId, setAt), oldest first.
• set-control-token --stdin --expect absent|<revision> stores the token only while it is still exactly at the state --expect names: absent, or the revision control-token-state answered (a positive integer without leading zeros). It is never a minimum, so a set that committed in between is refused rather than overwritten.
• The token is read from stdin and from nowhere else: --stdin names that, and an argument, --token, or any other extra argument is refused as usage without echoing it; the environment is never read for it. stdin must not be a terminal. One trailing line break (\n or \r\n) is stripped; what remains must pass the contract's isCorestoreControlToken (32 to 4096 bytes of UTF-8 without whitespace). A refused stdin is named (token-input-terminal, token-input-oversized, token-input-invalid) before anything connects, and every byte read is wiped.
• The token is sent once with @serve.zone/api (platform.setCorestoreControlToken, past every TypedRequest hook), and the answer is checked against the request. stdout carries one JSON line with the state the set produced and its receipt, never the token: {"ok":true,"command":"corestore set-control-token","state":{"state":"present","revision":<n>},"receipt":{…}}.
• A refusal is printed to stderr with exit code 1 as The Corestore control token was not stored: <refusal>., naming one of the contract's corestoreControlTokenSetRefusals: token-present (--expect absent, and a token is stored), token-absent (a revision was expected, and none is stored), token-revision-mismatch (the stored token is at another revision), token-invalid or provider-unavailable (a Corestore provider config is missing or disabled). Every other failure, an unauthorized or stale administrator included, is Cloudly's one denial text, Corestore control token request denied., with exit code 1.

Programmatic Use

The published submodule exports the runCli() entry point. For automation, most callers should use @serve.zone/api directly; the internal CliClient currently wraps CloudlyApiClient only to run the default cluster-list action:

import { CloudlyApiClient } from '@serve.zone/api';
import { CliClient } from './classes.cliclient.js';

const apiClient = new CloudlyApiClient({
  registerAs: 'cli',
  cloudlyUrl: 'https://cloudly.example.com',
});

await apiClient.start();
await apiClient.loginWithUsernameAndPassword('admin', 'change-me');

const cli = new CliClient(apiClient);
await cli.getClusters();

Files

| Path | Purpose | | --- | --- | | index.ts | Runtime entry point for the published CLI. | | classes.cliclient.ts | Minimal client wrapper: getClusters(), bootstrapGateway(), getGatewayStatus(), exportRelayAuthorization(), setCorestoreControlToken() and getCorestoreControlTokenState(). | | commands.ts | Parses the argument vector into one command, refusing anything else as usage. | | tokeninput.ts | Reads the dcrouter admin token and the Corestore control token from stdin, each bounded and checked by its contract. | | corestorecontroltoken.ts | Sets and reads the Corestore control token through the API client and names the contract's refusals. | | relayauthorization.ts | Checks the private output directory and writes a cluster relay's bearer as a new 0600 file. | | plugins.ts | Centralized imports for the submodule. | | tspublish.json | Published package name, dependencies, servezone bin metadata, and useBase, which takes the registries from the release's npm target. |

License and Legal Information

This repository contains open-source code licensed under the MIT License. A copy of the license can be found in the license file.

Please note: The MIT License does not grant permission to use the trade names, trademarks, service marks, or product names of the project, except as required for reasonable and customary use in describing the origin of the work and reproducing the content of the NOTICE file.

Trademarks

This project is owned and maintained by Task Venture Capital GmbH. The names and logos associated with Task Venture Capital GmbH and any related products or services are trademarks of Task Venture Capital GmbH or third parties, and are not included within the scope of the MIT license granted herein.

Use of these trademarks must comply with Task Venture Capital GmbH's Trademark Guidelines or the guidelines of the respective third-party owners, and any usage must be approved in writing. Third-party trademarks used herein are the property of their respective owners and used only in a descriptive manner, e.g. for an implementation of an API or similar.

Company Information

Task Venture Capital GmbH
Registered at District Court Bremen HRB 35230 HB, Germany

For any legal inquiries or further information, please contact us via email at [email protected].

By using this repository, you acknowledge that you have read this section, agree to comply with its terms, and understand that the licensing of the code does not imply endorsement by Task Venture Capital GmbH of any derivative works.