Render Tutorials
Render CLI for power users

Install and pin the CLI

⏱ 5 min

The CLI is a single Go binary. Install it once on your laptop and once again in CI - and pin both to the same major version so a release on Friday doesn’t ruin your Monday morning.

Install

Terminal
brew update
brew install render

Upgrade later with brew upgrade render. Homebrew tracks the latest stable release.

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

The script drops the binary into ~/.render/bin/render. Add that to your PATH if your shell didn’t already pick it up:

~/.zshrc or ~/.bashrc
export PATH="$HOME/.render/bin:$PATH"

Download the latest Windows zip from the GitHub releases page, unzip, and put render.exe somewhere on your PATH (e.g. C:\Users\you\bin\).

WSL users: use the Linux/curl instructions inside the WSL shell instead.

Terminal
git clone git@github.com:render-oss/cli.git
cd cli
go build -o render.
./render --version

Only do this if you need an unreleased feature or you’re contributing patches upstream.

Confirm the install:

Terminal
$render --version
render version 2.7.0

Anything 2.7.0 or newer is fine for this course. Older versions are missing blueprints validate and the modern -o json defaults.

Pin the version in CI

The install script always grabs the latest release. That’s the right default locally - you want bug fixes - but it’s the wrong default in CI, where you want reproducibility.

Pin to a specific release by downloading the asset directly:

ci-install-render.sh
#!/usr/bin/env bash
set -euo pipefail
RENDER_CLI_VERSION="v2.7.0"
OS="linux"
ARCH="amd64"


curl -sSfL \
  "https://github.com/render-oss/cli/releases/download/${RENDER_CLI_VERSION}/cli_${RENDER_CLI_VERSION#v}_${OS}_${ARCH}.zip" \
  -o /tmp/render.zip
unzip -q /tmp/render.zip -d /tmp/render
sudo mv "/tmp/render/cli_${RENDER_CLI_VERSION}" /usr/local/bin/render
render --version

The exact asset name follows the pattern cli_<version>_<os>_<arch>.zip - visit the releases page and check the artifact list if a new release changes the convention.

Verify the install with a smoke test

Run two read-only commands. If both succeed, you’re done with this step:

Terminal
$render --version
render version 2.7.0
$render --help
Usage:
  render [command]

Available Commands:
  blueprints, deploys, logs, login, projects, psql, services, skills, ssh, workspaces, workspace,...

If render --help only shows a subset of those commands, you’ve got a much older release on your PATH - most likely from a previous install - and it’s masking the new one. Run which -a render to find the duplicate and remove it.

Update later

MethodUpdate command
Homebrewbrew upgrade render
Linux/macOS curl installRe-run the install script
Direct downloadReplace the binary with the new release
CI scriptBump RENDER_CLI_VERSION and open a PR

The CLI follows semver. Major bumps will be called out in the release notes; minor and patch releases are safe to take as soon as they ship.

Where the install lives

The binary itself is in one place; the config lives somewhere different. You’ll meet the config file in the next step.

PathContents
/usr/local/bin/render (or ~/.render/bin/render)The binary
~/.render/cli.yamlYour CLI token, default workspace, and output preferences
$RENDER_CLI_CONFIG_PATHOverride the config file location (handy for per-project configs)

Keep the binary on PATH; keep the config out of git.

Your CI job suddenly breaks after running fine for months. Nothing in your repo changed. What's the *most* likely cause if your install step uses the `install.sh` one-liner?

What you learned

  • Install via Homebrew, the curl installer, a direct download, or `go build` - same binary either way
  • Pin the CLI version in CI by downloading a specific release asset from GitHub
  • Major-bump the pin in its own reviewable PR; let patch versions float for bug fixes
  • Config lives in `~/.render/cli.yaml` (or `$RENDER_CLI_CONFIG_PATH`); the binary lives on `PATH`