Skip to main content
bex.co
419

Command line interface

Install the official Render CLI, connect it to bex, and manage services, deploys, logs, shells, Postgres, and Key Value from your terminal or CI.

Share
Last updated on August 20, 2026

bex works with the official, unmodified Render CLI. You keep using the render command; a bex API key and RENDER_HOST point it at bex instead of Render.

bex also ships its own binary, bex: the same upstream command implementation, already pointed at bex's API, plus Bex-native commands the Render CLI has no equivalent for. Today those are the coding-agent launchers.

Use the CLI to:

  • create, update, suspend, resume, and delete services and datastores;
  • trigger deploys, restarts, and one-off jobs;
  • tail and filter application, request, and build logs;
  • open SSH, psql, pgcli, and Key Value sessions; and
  • automate repeatable operations with JSON or YAML output.

bex's compatibility suite is currently pinned to Render CLI v2.21.0. Newer releases might work, but use the tested version when reproducibility matters. See Compatibility and differences.

Set up the CLI​

1. Install the official Render CLI​

Install the latest release with Homebrew:

bash
brew update
brew install render

Or use Render's installer on Linux or macOS:

bash
curl -fsSL https://raw.githubusercontent.com/render-oss/cli/refs/heads/main/bin/install.sh | sh

For the exact version bex verifies, download v2.21.0 from the Render CLI releases page. After installing, confirm the binary is available:

bash
render --version

2. Create a bex API key​

  1. Open Dashboard → Settings.
  2. In API Keys, select Create API Key and give the key a recognizable name such as local-cli.
  3. Copy both the key ID and secret. The secret is shown only once.

Treat the secret like a password. Do not commit it, paste it into an issue, or store it in a shell profile.

3. Connect the CLI to bex​

Download bex's setup helper, inspect it, and source it so its environment variables remain in your current shell:

bash
curl --fail --silent --show-error \
  --output setup-render-cli.sh \
  https://raw.githubusercontent.com/bex-co/bex/main/setup-render-cli.sh
 
less setup-render-cli.sh
source ./setup-render-cli.sh

The helper:

  • prompts for the key ID and secret without echoing the secret;
  • exchanges them for a short-lived bex access token;
  • sets RENDER_HOST=https://api.bex.co/v1/;
  • asks you to select a tea-… workspace; and
  • runs render whoami to verify the connection.

The access token expires after 15 minutes. Re-source the helper when it does. It unsets the API key secret as soon as the token exchange finishes.

Common commands​

Run render with no arguments to browse the interactive command menu, or run render help <command> for flags and examples.

Inspect your workspace​

bash
render whoami
render workspaces
render services

render services includes services and datastores in the active workspace. Most resource commands accept either the resource's bex ID (srv-…, dpg-…, red-…) or its exact name.

Deploy and operate a service​

bash
# Review recent deploys
render deploys list srv-abc123
 
# Deploy and wait for the result
render deploys create srv-abc123 --wait
 
# Stream live logs
render logs --resources srv-abc123 --tail
 
# Restart or open a shell
render restart srv-abc123
render ssh srv-abc123

Use render services create --help to create a web service, static site, background worker, or cron job from a Git repository or container image.

Work with datastores​

bash
render postgres list
render keyvalues list
 
# Run one query and return text
render psql dpg-abc123 -c "SELECT NOW();" -o text
 
# Open the interactive Key Value client
render kv-cli red-abc123

Database and Key Value sessions enforce the resource's IP allow list. Install the corresponding local client (psql, pgcli, or redis-cli) before opening an interactive session.

Filter logs​

bash
# Search recent application logs
render logs --resources srv-abc123 --type app --text "timeout"
 
# Inspect only error-level entries as JSON
render logs --resources srv-abc123 --level error --output json
 
# Follow build output
render logs --resources srv-abc123 --type build --tail

The CLI also supports time windows, direction, result limits, instances, host, path, method, and status-code filters. Run render logs --help for the complete flag list.

Scripts and CI​

The CLI is interactive by default. In automation, provide the resource and workspace IDs explicitly, select a machine-readable output format, and pass --confirm to skip confirmation prompts:

bash
export RENDER_HOST="https://api.bex.co/v1/"
export RENDER_WORKSPACE="tea-abc123"
export RENDER_OUTPUT="json"
 
export RENDER_API_KEY="$(
  curl --fail --silent --show-error \
    --request POST https://oauth.bex.co/oauth2/token \
    --data-urlencode grant_type=client_credentials \
    --data-urlencode "client_id=$BEX_API_KEY_ID" \
    --data-urlencode "client_secret=$BEX_API_KEY_SECRET" \
  | jq --exit-status --raw-output .access_token
)"
 
render deploys create "$BEX_SERVICE_ID" --wait --output json --confirm

Store BEX_API_KEY_ID, BEX_API_KEY_SECRET, RENDER_WORKSPACE, and resource IDs in your CI provider's encrypted secret store. Exchange the key at the start of each job instead of persisting the short-lived access token.

Coding-agent launchers​

The bex binary registers Bex-native commands beside the imported Render command tree. The first of them are the coding-agent launchers: one command per Anthropic-compatible model provider, each starting a Claude Code session against that provider's endpoint. Claude Code stays an external runtime and is never forked — a launcher sets only its documented environment seams (ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, CLAUDE_CONFIG_DIR, and the model-slot variables) at exec time.

Install bex​

The install script detects your OS and architecture, verifies checksums.txt, and installs atomically to ~/.local/bin:

bash
curl -fsSL https://raw.githubusercontent.com/bex-co/bex/main/scripts/install-bex.sh | sh

Or install from the Homebrew tap:

bash
brew install bex-co/tap/bex

Both channels install the same signed release binaries for macOS and Linux on arm64 and amd64, and every release ships checksums.txt alongside a keyless cosign signature bundle for provenance verification. Windows is not currently built; use WSL. Confirm the install — the same command reports when a newer release exists:

bash
bex -v

Launch a provider​

A launcher needs the claude binary on your PATH:

bash
npm install -g @anthropic-ai/claude-code
bex glm

Each command targets one provider's Anthropic-compatible endpoint — the integration pattern each of these providers documents itself. Keys are bring-your-own: the provider bills your session directly, and bex brokers nothing.

  • bex glm runs Claude Code against Z.ai's Anthropic-compatible endpoint, the pairing Z.ai documents for its coding plan. The key is read from ZAI_API_KEY or GLM_API_KEY. See GLM CLI with Claude Code.
  • bex kimi runs it against the Moonshot platform's Anthropic-compatible endpoint, keyed with MOONSHOT_API_KEY or KIMI_API_KEY. Moonshot's general-purpose and small/fast model ids land in different Claude Code model slots. See Kimi CLI with Claude Code.
  • bex deepseek runs it against DeepSeek's Anthropic-compatible endpoint, keyed with DEEPSEEK_API_KEY — the one entry in the catalog with a single key variable and the same model id in both slots. See DeepSeek CLI with Claude Code.
  • bex muse runs it against the Meta Model API, putting Muse Spark behind Claude Code's workflow, keyed with META_MODEL_API_KEY or META_API_KEY. See Muse Spark with Claude Code.

Each provider's page carries its endpoint, its API-key console, its current default and small/fast model ids, and a copy-paste quickstart. The launcher index lists all four with their default models.

Keys and isolation: bex code​

  • Each provider is isolated. A launcher points CLAUDE_CONFIG_DIR at that provider's own directory under ~/.bex/code (move the base with BEX_CODE_HOME), so settings, history, and permissions never collide, instances run in parallel, and your personal ~/.claude is neither read nor modified. Inherited ANTHROPIC_* and CLAUDE_CONFIG_DIR values are stripped so the surrounding environment cannot leak into the session.
  • A key is captured once. A provider's first launch opens its API-key console, takes one hidden paste, verifies the key live against the provider's Messages endpoint, and stores it owner-only in ~/.bex/code/keys.toml. The key is injected into the child process at launch and written into no configuration file.
  • The environment always overrides the store. A key already set in that provider's environment variables wins, first set variable first, so a CI job or a one-off shell can bring its own key without touching keys.toml.
  • Everything after the provider name goes to claude unchanged — bex glm --continue, bex glm -p "one prompt", or bex glm --help for Claude Code's own flags.
  • bex code is the hub. bex code (or bex code keys) shows which providers have a stored key; bex code keys set|unset <provider> manage the store, and set accepts piped stdin for scripting.

The provider catalog lives in the bex repository, so adding a provider is a data change rather than new command code.

Compatibility and differences​

bex continuously exercises the unmodified Render CLI against its Render-compatible REST API. Services, deploys, jobs, logs, Postgres, Key Value, projects, environments, Blueprints, registry credentials, custom domains, SSH, and workspace commands have verified coverage.

Important boundaries:

  • bex stamps its configured region; it does not pretend to run in a Render region.
  • Render preview environments and Workflows are deliberate non-goals today.
  • Postgres Datadog flags and deploy-after-CI-checks are rejected rather than silently accepted.
  • The CLI does not switch a service's runtime after creation.
  • render docs opens Render's documentation. Bookmark this bex guide instead.
  • render skills is a client-side Render CLI feature, not a bex integration.

For the command-by-command status, verified version, limitations, and live test evidence, read the Render CLI compatibility checklist.

Troubleshooting​

The CLI is calling Render instead of bex​

Confirm the API base ends in /v1/:

bash
printf '%s\n' "$RENDER_HOST"
# https://api.bex.co/v1/

Then re-source setup-render-cli.sh in the same shell.

Authentication expired​

bex access tokens last 15 minutes. Re-source the setup helper to exchange the API key for a new token. If the key itself was revoked, create a replacement in Dashboard → Settings.

A command is waiting for input​

Pass an explicit resource ID and workspace, then add --output json --confirm. This is required for reliable CI and agent workflows.

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex