Output formats and non-interactive mode

The CLI guesses what you want based on how it was invoked. That’s the right default for humans and a sharp edge for scripts. This step teaches you to never get cut.

The auto-detect rules

When you run render services in your terminal, you get a pretty paginated picker. When the same command runs in CI, you get tabular text. That’s not magic - it’s a single rule:

flowchart TD
  start["render <command>"]
  flag{"--output flag set?"}
  envvar{"RENDER_OUTPUT env set?"}
  tty{"stdout is a TTY?"}
  i["Output: interactive picker"]
  t["Output: text (tab-separated)"]
  flag -->|"yes"| useflag["Use that format"]
  flag -->|"no"| envvar
  envvar -->|"yes"| useenv["Use that format"]
  envvar -->|"no"| tty
  tty -->|"yes"| i
  tty -->|"no"| t

  start --> flag

In English: a flag beats an env var beats auto-detect. If nothing is set, the CLI checks whether stdout is a TTY and picks interactive (TTY) or text (pipe/CI).

That’s why piping accidentally “breaks” interactive mode - once stdout isn’t a TTY, the picker bails out.

The four output formats

Pick json for anything you’d want to script against. It’s stable, parseable, and jq makes the rest easy.

Set the format three ways

Per command (-o / --output)

render services -o json

Highest precedence. Use it when you’re mixing interactive and scripted use in the same session.

Per shell session (RENDER_OUTPUT)

export RENDER_OUTPUT=json
render services
render deploys list srv-xxx

Set it once, every subsequent command emits JSON. Great for scripting sessions where you don’t want to repeat -o json on every line.

Per config file (the output field)

output: interactive

Lowest precedence; the default you fall back to when nothing else is set. Most people leave this on interactive.

--confirm and why CI needs it

Several mutating commands prompt you to confirm before running. Examples: render deploys create, render psql connecting to production. The prompt is a safety net interactively, and a hang in CI.

render deploys create srv-xxx --wait --confirm -o json

Anything that mutates state, when scripted, gets --confirm. Read-only commands (services, logs, deploys list) don’t need it.

See the difference: interactive vs scripted

The same command, two ways:

$render services
[picker UI: arrow keys to navigate, enter to select, q to quit]

  Name                Type   Plan        URL
> api                 web    starter     https://api.acme.onrender.com
  worker              worker starter
  cache               kv     starter
  app-db              psql   basic-1gb

$render services -o json --confirm | jq '.[] | {name, id, type}'
{
  "name": "api",
  "id": "srv-xxxxxxxxxxxxxxxx",
  "type": "web_service"
}
{
  "name": "worker",
  "id": "srv-yyyyyyyyyyyyyyyy",
  "type": "background_worker"
}

A test you can run right now

Run this twice and look at the difference:

render services                         # interactive picker
render services | head                  # text format (because stdout is a pipe)
render services -o json | jq '.[0]'     # JSON (explicit flag)
RENDER_OUTPUT=json render services      # JSON (env var)

If render services -o json | jq '.[0]' doesn’t print a JSON object, the most common cause is jq parsing the text format - make sure -o json is on the render call, not on jq.

Practical scripting template

Whenever you’re writing a script that calls render, start from this template:

#!/usr/bin/env bash
set -euo pipefail
export RENDER_API_KEY="${RENDER_API_KEY:?must be set}"
export RENDER_OUTPUT=json
CONFIRM=( --confirm )

services=$(render services)
echo "$services" | jq -r '.[] | "\(.name)\t\(.id)"'

You’ll see this template again in step 10.

Common gotchas