# Render CLI Reference — Look up supported commands and options.



This reference is automatically generated from the Render CLI source.

View documentation for any command in the CLI itself by running the following:

```shell
render help <command>
```

## Global options

| Option | Description |
| --- | --- |
| `--confirm` | Skip all confirmation prompts |
| `--output`, `-o` | Set output format to interactive, json, yaml, or text. Auto-switches to text on non-TTY |

## Top-level commands

###### `docs`

Open the Render docs in your browser

*Usage:*

```bash
render docs
```

*Examples:*

```bash
# Open Render documentation
render docs
```

*Options:*

[Global options](#global-options) only

###### `environments <projectID>`

List environments for a specified project in the active workspace. In interactive mode you can view each environment's individual services.

*Usage:*

```bash
render environments <projectID>
```

*Examples:*

```bash
# List environments for a project
render environments prj-abc123
```

*Options:*

[Global options](#global-options) only

###### `kv-cli [keyValueID|keyValueName]`

Open a redis-cli or valkey-cli session for a Render Key Value instance. This command only supports interactive mode.

You can optionally pass the key value ID or name as an argument. To pass arguments to redis-cli or valkey-cli, use:
  render kv-cli [keyValueID|keyValueName] -- [redis-cli args]

*Usage:*

```bash
render kv-cli [keyValueID|keyValueName]
```

*Examples:*

```bash
# Open an interactive kv-cli session
render kv-cli kv-abc123

# Pass through redis-cli arguments
render kv-cli kv-abc123 -- --scan
```

*Options:*

[Global options](#global-options) only

###### `login`

Log in to Render using the Render Dashboard

*Usage:*

```bash
render login
```

*Examples:*

```bash
# Authenticate with Render
render login
```

*Options:*

[Global options](#global-options) only

###### `logout`

Log out of Render

*Usage:*

```bash
render logout
```

*Options:*

[Global options](#global-options) only

###### `logs`

View logs for services and datastores.

Use flags to filter logs by resource, instance, time, text, level, type, host, status code, method, or path. Unlike in the Render Dashboard, you can view logs for multiple resources at once.

In interactive mode you can update the filters and view logs in real time, or set `--tail=true` to stream new logs.

*Usage:*

```bash
render logs
```

*Examples:*

```bash
# Tail logs for a service
render logs --resources srv-abc123 --tail

# Query logs in a time range
render logs --resources srv-abc123 --start 2026-03-01T00:00:00Z --end 2026-03-01T01:00:00Z

# Output logs as JSON in non-interactive mode
render logs --resources srv-abc123 --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--direction` | Set log query direction (backward or forward) |
| `--end` | Filter logs at or before the specified end time |
| `--host` | Filter logs by comma-separated host values |
| `--instance` | Filter logs by comma-separated instance IDs |
| `--level` | Filter logs by comma-separated log levels |
| `--limit` | Limit the number of logs returned |
| `--method` | Filter logs by comma-separated HTTP methods |
| `--path` | Filter logs by comma-separated request paths |
| `--resources`, `-r` | Filter logs by comma-separated resource IDs (Required in non-interactive mode) |
| `--start` | Filter logs at or after the specified start time |
| `--status-code` | Filter logs by comma-separated status codes |
| `--tail` | Stream new logs |
| `--task-id` | Filter logs by comma-separated task IDs |
| `--task-run-id` | Filter logs by comma-separated task run IDs |
| `--text` | Filter logs by comma-separated text values |
| `--type` | Filter logs by comma-separated log types |

###### `pgcli [postgresID|postgresName]`

Open a pgcli session to a Render Postgres database instance. This command only supports interactive mode.

You can optionally pass a database ID or name as an argument. To pass arguments to pgcli, use:
  render pgcli [postgresID|postgresName] -- [pgcli args]

*Usage:*

```bash
render pgcli [postgresID|postgresName]
```

*Examples:*

```bash
# Open an interactive pgcli session
render pgcli pg-abc123

# Pass through pgcli arguments
render pgcli pg-abc123 -- --csv -q
```

*Options:*

[Global options](#global-options) only

###### `projects`

Browse projects in the active workspace. In interactive mode, select a project to view its environments.

*Usage:*

```bash
render projects
```

*Examples:*

```bash
# List projects in JSON
render projects --output json
```

*Options:*

[Global options](#global-options) only

###### `psql [postgresID|postgresName]`

Open a psql session to a Render Postgres database.

Optionally pass the database ID or name as an argument. To pass arguments to psql, use:
  render psql [postgresID|postgresName] -- [psql args]

For non-interactive usage, use the `--command` flag:
  render psql [postgresID|postgresName] -c "SELECT * FROM users;" -o text

Additional psql flags can be passed after --:
  render psql [postgresID|postgresName] -c "SELECT 1;" -o json -- `--csv` -q

*Usage:*

```bash
render psql [postgresID|postgresName]
```

*Examples:*

```bash
# Open an interactive psql session
render psql pg-abc123

# Execute a SQL command in non-interactive mode
render psql pg-abc123 --command "SELECT * FROM users;" --output text

# Pass through psql arguments
render psql pg-abc123 -- --csv -q
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--command`, `-c` | Execute a SQL command in non-interactive mode |

###### `restart <resourceID>`

Restart a service by resource ID

*Usage:*

```bash
render restart <resourceID>
```

*Examples:*

```bash
# Restart a service
render restart srv-abc123

# Restart a service without confirmation prompts
render restart srv-abc123 --confirm
```

*Options:*

[Global options](#global-options) only

###### `ssh [serviceID|serviceName|instanceID]`

SSH into a service instance. This command only supports interactive mode.

You can specify the service ID, service name, or specific instance ID as an argument. To pass arguments to ssh, use:
  render ssh [serviceID|serviceName|instanceID] -- [ssh args]

*Usage:*

```bash
render ssh [serviceID|serviceName|instanceID]
```

*Examples:*

```bash
# Open an SSH session for a service
render ssh srv-abc123

# Connect to an ephemeral instance
render ssh srv-abc123 --ephemeral

# Connect to an ephemeral instance with a specific plan
render ssh srv-abc123 --ephemeral --plan 1c-2g

# Pass through ssh arguments
render ssh srv-abc123 -- -L 5432:localhost:5432
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--ephemeral`, `-e` | Connect to an ephemeral instance |
| `--plan` | Plan name to use for the ephemeral instance (e.g. 0.5c-512mb, 1c-2g, 2c-4g). Only valid with `--ephemeral`. |

###### `whoami`

Display information about the current user

*Usage:*

```bash
render whoami
```

*Examples:*

```bash
# Show the currently authenticated user
render whoami
```

*Options:*

[Global options](#global-options) only

###### `workspaces`

List workspaces available to your account

*Usage:*

```bash
render workspaces
```

*Examples:*

```bash
# List workspaces available to the current user
render workspaces
```

*Options:*

[Global options](#global-options) only

## Blueprints

###### `blueprints validate [file]`

Validate a Blueprint file for errors before committing.

Validates:
  - YAML syntax
  - Schema validation (Required fields, types)
  - Semantic validation (valid plans, regions, etc.)
  - Conflict checking against existing resources

*Usage:*

```bash
render blueprints validate [file]
```

*Examples:*

```bash
# Validate ./render.yaml
render blueprints validate

# Validate a specific Blueprint file
render blueprints validate ./my-blueprint.yaml

# Output validation results as JSON
render blueprints validate -o json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--workspace`, `-w` | Validate against the specified workspace ID (defaults to current workspace) |

## Deploys

###### `deploys cancel <serviceID> <deployID>`

Cancel a running deploy

*Usage:*

```bash
render deploys cancel <serviceID> <deployID>
```

*Examples:*

```bash
# Cancel a running deploy
render deploys cancel srv-abc123 dep-xyz789
```

*Options:*

[Global options](#global-options) only

###### `deploys create [serviceID]`

Trigger a service deploy and stream logs in real time

*Usage:*

```bash
render deploys create [serviceID]
```

*Examples:*

```bash
# Trigger a deploy for a service
render deploys create srv-abc123

# Deploy a specific commit
render deploys create srv-abc123 --commit 0123abcd

# Wait until deploy completes
render deploys create srv-abc123 --wait
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--clear-cache` | Clear build cache before deploying |
| `--commit` | Deploy the specified commit ID |
| `--image` | Deploy the specified Docker image URL |
| `--wait` | Wait for deploy completion and exit non-zero if deploy fails |

###### `deploys list [serviceID]`

List deploys for a service

*Usage:*

```bash
render deploys list [serviceID]
```

*Examples:*

```bash
# List deploys for a service
render deploys list srv-abc123

# Browse deploys interactively
render deploys list
```

*Options:*

[Global options](#global-options) only

## Jobs

###### `jobs cancel <serviceID> <jobID>`

Cancel a running job

*Usage:*

```bash
render jobs cancel <serviceID> <jobID>
```

*Examples:*

```bash
# Cancel a running job
render jobs cancel srv-abc123 job-xyz789
```

*Options:*

[Global options](#global-options) only

###### `jobs create [serviceID]`

Create a new job for a service

*Usage:*

```bash
render jobs create [serviceID]
```

*Examples:*

```bash
# Create a job for a service
render jobs create srv-abc123 --start-command "bundle exec rake task"

# Create a job with a specific plan
# See https://render.com/docs/one-off-jobs for available job plans
render jobs create srv-abc123 --start-command "npm run worker" --plan-id plan-srv-006
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--plan-id` | Set the plan ID for the job (Optional) |
| `--start-command` | Set the job start command |

###### `jobs list [serviceID]`

List jobs for a service

*Usage:*

```bash
render jobs list [serviceID]
```

*Examples:*

```bash
# List jobs for a service
render jobs list srv-abc123

# Browse jobs interactively
render jobs list
```

*Options:*

[Global options](#global-options) only

## Key Value

###### `kv create`

Create a new Render Key Value instance.

In interactive mode, a prompt guides you through each option one at a time.
In non-interactive mode (`--output` text/json/yaml), flags use defaults if not supplied.
Use `--confirm` to skip all prompts (including final confirmation) and create immediately.
Output will be human-readable; use `--output` json/yaml/text for machine-readable output.

*Usage:*

```bash
render kv create
```

*Examples:*

```bash
# Interactive wizard (guided prompts for each option)
render kv create

# Specify all options; wizard still asks for confirmation before creating
render kv create --name my-cache --plan 256mb --region oregon

# Skip all prompts and create immediately (no confirmation)
render kv create --name my-cache --plan free --confirm

# Machine-readable output (non-interactive, no prompts)
render kv create --name my-cache --plan 256mb --output json

# Use as a cache with no on-disk persistence
render kv create --name my-cache --plan 256mb --persistence-mode off

# With IP allow-listing (repeat the flag for multiple entries)
render kv create --name my-cache \
--ip-allow-list "cidr=203.0.113.5/32,description=office" \
--ip-allow-list "cidr=10.0.0.0/8,description=internal"
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Set the environment to create the Key Value in (ID or name, optional). Example: Production or evm-abc123def456 |
| `--ip-allow-list` | Restrict inbound traffic to specific IP ranges (format: `cidr=<range>,description=<label>`). Repeat the flag for multiple entries. |
| `--memory-policy` | Set the eviction policy used when the instance runs out of memory. Accepts a friendly alias — cache (= allkeys_lru, for caching) or queue (= noeviction, for job queues) — or any raw policy: noeviction \| allkeys_lru \| allkeys_lfu \| allkeys_random \| volatile_lru \| volatile_lfu \| volatile_random \| volatile_ttl |
| `--name` | Set the Key Value instance name (generated if not provided) |
| `--persistence-mode` | Set the on-disk persistence mode: journal_snapshot \| snapshot \| off (off loses data on restart; omit to use the plan default). |
| `--plan` | Set the plan to one of: free \| 256mb \| 1g \| 5g \| 10g \| 20g \| 40g. Custom enterprise plan names are also accepted. |
| `--project` | Scope environment lookup to a project (ID or name, optional); if the project has exactly one environment it is used automatically. |
| `--region` | Set the region: frankfurt \| ohio \| oregon \| singapore \| virginia |
| `--workspace` | Set the workspace to create the Key Value in (ID or name). Defaults to the active workspace (set via 'render workspace set'). |

###### `kv delete <keyValueID|keyValueName>`

Delete a Render Key Value instance.

Without `--confirm`, this command previews what would be deleted and makes no
changes. Pass `--confirm` to actually delete the instance.

The positional argument accepts either a Key Value ID (red-...) or a name.
If the name matches more than one instance, narrow the search with
`--environment` <id|name>, or pass the Key Value ID directly.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Key Value ID instead (which works across workspaces).

*Usage:*

```bash
render kv delete <keyValueID|keyValueName>
```

*Examples:*

```bash
# Preview deletion (no changes made)
render kv delete red-abc123def456ghi789jkl0

# Delete by ID
render kv delete red-abc123def456ghi789jkl0 --confirm

# Delete by name
render kv delete my-cache --confirm

# Disambiguate a name that exists in multiple environments
render kv delete my-cache --environment production --confirm

# JSON output
render kv delete red-abc123def456ghi789jkl0 --confirm --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Key Value name exists in multiple environments. |

###### `kv get <keyValueID|keyValueName>`

Get details and connection info for a Render Key Value instance.

The positional argument accepts either a Key Value ID (red-...) or a name.
If the name matches more than one instance, narrow the search with
`--project` <id|name>, `--environment` <id|name>, or pass the Key Value ID
directly.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Key Value ID instead (which works across workspaces).

*Usage:*

```bash
render kv get <keyValueID|keyValueName>
```

*Examples:*

```bash
# Get by ID
render kv get red-abc123def456ghi789jkl0

# Get by name
render kv get my-cache

# Include connection strings (contains credentials)
render kv get my-cache --include-sensitive-connection-info

# Disambiguate by project
render kv get my-cache --project my-project

# Disambiguate a name that exists in multiple environments
render kv get my-cache --environment production

# JSON output
render kv get red-abc123def456ghi789jkl0 --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Key Value name exists in multiple environments. |
| `--include-sensitive-connection-info` | Include connection strings and credentials in the output |
| `--project` | Narrow lookup to a project (ID or name, optional) within the active workspace. |

###### `kv list`

List Render Key Value instances in the active workspace.

Use `--project` to narrow results to a single project, `--environment` to narrow
to a single environment, or both — when both are supplied, the environment is
resolved within that project.

*Usage:*

```bash
render kv list
```

*Examples:*

```bash
# List all Key Value instances in the active workspace
render kv list

# List all Key Value instances in a project
render kv list --project my-project

# Filter by environment name
render kv list --environment production

# Disambiguate an environment name by project
render kv list --project my-project --environment production

# JSON output
render kv list --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow results to a single environment (ID or name, optional). |
| `--project` | Narrow results to environments in a project (ID or name, optional). |

###### `kv resume <keyValueID|keyValueName>`

Resume a suspended Render Key Value instance.

The positional argument accepts either a Key Value ID (red-...) or a name.
If the name matches more than one instance, narrow the search with
`--environment` <id|name>, or pass the Key Value ID directly.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Key Value ID instead (which works across workspaces).

*Usage:*

```bash
render kv resume <keyValueID|keyValueName>
```

*Examples:*

```bash
# Resume by ID
render kv resume red-abc123def456ghi789jkl0

# Resume by name
render kv resume my-cache

# Disambiguate a name that exists in multiple environments
render kv resume my-cache --environment production

# JSON output
render kv resume red-abc123def456ghi789jkl0 --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Key Value name exists in multiple environments. |

###### `kv suspend <keyValueID|keyValueName>`

Suspend a Render Key Value instance.

Without `--confirm`, this command previews what would be suspended and makes no
changes. Pass `--confirm` to actually suspend the instance.

The positional argument accepts either a Key Value ID (red-...) or a name.
If the name matches more than one instance, narrow the search with
`--environment` <id|name>, or pass the Key Value ID directly.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Key Value ID instead (which works across workspaces).

*Usage:*

```bash
render kv suspend <keyValueID|keyValueName>
```

*Examples:*

```bash
# Preview suspension (no changes made)
render kv suspend red-abc123def456ghi789jkl0

# Suspend by ID
render kv suspend red-abc123def456ghi789jkl0 --confirm

# Suspend by name
render kv suspend my-cache --confirm

# Disambiguate a name that exists in multiple environments
render kv suspend my-cache --environment production --confirm

# JSON output
render kv suspend red-abc123def456ghi789jkl0 --confirm --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Key Value name exists in multiple environments. |

###### `kv update <keyValueID|keyValueName>`

Update an existing Render Key Value instance.

The positional argument is the target Key Value (ID red-... or name). At least
one mutating flag must be supplied. Use `--name` to rename the instance; the
positional argument always identifies the target and is never the new name.

Environment, project, workspace, and region are immutable. A Key Value instance
cannot be moved between them; the `--environment` flag is for name disambiguation
only.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Key Value ID instead (which works across workspaces). If a name matches more
than one instance, narrow the search with `--environment` <id|name>.

The `--ip-allow-list` flag replaces the server-side list; pass it once per entry.
To remove all allow-list entries, pass `--clear-ip-allow-list`. The two flags are
mutually exclusive.

*Usage:*

```bash
render kv update <keyValueID|keyValueName>
```

*Examples:*

```bash
# Rename
render kv update red-abc123def456ghi789jkl0 --name new-cache-name

# Change plan
render kv update my-cache --plan 1g

# Replace the IP allow-list (entire list, not append)
render kv update my-cache \
--ip-allow-list "cidr=203.0.113.5/32,description=office" \
--ip-allow-list "cidr=10.0.0.0/8,description=internal"

# Clear the IP allow-list
render kv update my-cache --clear-ip-allow-list

# Disambiguate a name that exists in multiple environments
render kv update my-cache --environment production --memory-policy queue

# Turn off on-disk persistence
render kv update my-cache --persistence-mode off

# JSON output
render kv update red-abc123def456ghi789jkl0 --plan 5g --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--clear-ip-allow-list` | Remove all IP allow-list entries. Mutually exclusive with `--ip-allow-list` |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Key Value name exists in multiple environments |
| `--ip-allow-list` | Replace the IP allow-list with the supplied entries (format: `cidr=<range>,description=<label>`). Repeat the flag for multiple entries. |
| `--memory-policy` | Set the eviction policy used when the instance runs out of memory. Accepts a friendly alias — cache (= allkeys_lru, for caching) or queue (= noeviction, for job queues) — or any raw policy: noeviction \| allkeys_lru \| allkeys_lfu \| allkeys_random \| volatile_lru \| volatile_lfu \| volatile_random \| volatile_ttl |
| `--name` | Rename the Key Value instance |
| `--persistence-mode` | Set the on-disk persistence mode: journal_snapshot \| snapshot \| off (off loses data on restart). |
| `--plan` | Set the plan to one of: free \| 256mb \| 1g \| 5g \| 10g \| 20g \| 40g. Custom enterprise plan names are also accepted. |

## Postgres

###### `pg create`

Create a new Render Postgres database.

In interactive mode, a wizard guides you through the core choices for the
database. The wizard owns those prompted values. Flag-only settings, such as
`--disk-size-gb`, `--database-name`, `--database-user`, `--ip-allow-list`, and `--read-replica`,
are still included in the create request.

Use `--confirm` to skip the wizard and create immediately from flags and defaults.
When `--confirm` is used with the default interactive output mode, output is
printed as text. Use `--output` json, yaml, or text for non-interactive output.

*Usage:*

```bash
render pg create
```

*Examples:*

```bash
# Launch the interactive wizard
render pg create

# Create immediately with defaults and text output
render pg create --confirm

# Create immediately with explicit values
render pg create --confirm --name analytics --plan 2c-8g --version 17 --region ohio

# Include flag-only settings while using the wizard for prompted values
render pg create \
--ip-allow-list "cidr=203.0.113.5/32,description=office" \
--ip-allow-list "cidr=10.0.0.0/8,description=internal"

# Machine-readable output
render pg create --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--connection-pool` | Set connection pool to 'none' or 'pgbouncer' |
| `--database-name` | Set the Postgres database name (server generates one if unset) |
| `--database-user` | Set the Postgres database user (server generates one if unset) |
| `--datadog-api-key` | Set the Datadog API key for monitoring |
| `--datadog-site` | Set the Datadog region/site (e.g. US1, US3, EU). Server default is US1. |
| `--disk-autoscaling` | Enable disk autoscaling |
| `--disk-size-gb` | Set the disk size in GB. Must be 1 or a multiple of 5. Server picks a sensible default based on compute size if unset. |
| `--environment` | Set the environment to create the database in (ID or name, optional). Example: Production or evm-abc123def456 |
| `--high-availability` | Enable high availability (available for plans with at least 1 CPU) |
| `--ip-allow-list` | Restrict inbound traffic to specific IP ranges (format: `cidr=<range>,description=<label>`). Repeat the flag for multiple entries. |
| `--name` | Set the database name (generated if not provided) |
| `--plan` | Set the plan to one of: free \| 0.1c-256mb \| 0.5c-1g \| 1c-2g \| 1c-4g \| 2c-4g \| 2c-8g \| 2c-16g \| 4c-16g \| 4c-32g \| 8c-32g \| 8c-64g \| 16c-64g \| 16c-128g \| 32c-128g \| 32c-256g \| 48c-192g \| 48c-384g \| 64c-256g \| 64c-512g \| 96c-384g \| 96c-768g \| 128c-512g \| 128c-1024g. Custom enterprise plan names are also accepted. |
| `--project` | Scope environment lookup to a project (ID or name, optional); if the project has exactly one environment it is used automatically. |
| `--read-replica` | Create a read replica with the given name alongside the primary. Repeat the flag for multiple replicas. |
| `--region` | Set the region: frankfurt \| ohio \| oregon \| singapore \| virginia (server picks if unset) |
| `--version` | Set the Postgres major version. Defaults to 18. |
| `--workspace` | Set the workspace to create the database in (ID or name). Defaults to the active workspace (set via 'render workspace set'). |

###### `pg delete <postgresID|postgresName>`

Delete a Render Postgres database.

Without `--confirm`, this command previews what would be deleted and makes no
changes. Pass `--confirm` to actually delete the database.

The positional argument accepts either a Postgres ID (dpg-...) or a name.
If the name matches more than one database, narrow the search with
`--project` <id|name>, `--environment` <id|name>, or pass the Postgres ID directly.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Postgres ID instead (which works across workspaces).

*Usage:*

```bash
render pg delete <postgresID|postgresName>
```

*Examples:*

```bash
# Preview deletion (no changes made)
render pg delete dpg-abc123def456ghi789jkl0

# Delete by ID
render pg delete dpg-abc123def456ghi789jkl0 --confirm

# Delete by name
render pg delete my-db --confirm

# Disambiguate a name that exists in multiple environments
render pg delete my-db --environment production --confirm

# Disambiguate a name that exists in multiple projects
render pg delete my-db --project analytics --confirm

# JSON output
render pg delete dpg-abc123def456ghi789jkl0 --confirm --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Postgres database name exists in multiple environments. |
| `--project` | Narrow lookup to a project (ID or name, optional) when the same Postgres database name exists in multiple projects. |

###### `pg get <postgresID|postgresName>`

Get details and connection info for a Render Postgres database.

The positional argument accepts either a Postgres ID (dpg-...) or a name.
If the name matches more than one database, narrow the search with
`--project` <id|name>, `--environment` <id|name>, or pass the Postgres ID directly.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Postgres ID instead (which works across workspaces).

*Usage:*

```bash
render pg get <postgresID|postgresName>
```

*Examples:*

```bash
# Get by ID
render pg get dpg-abc123def456ghi789jkl0

# Get by name
render pg get my-db

# Include connection strings (contains credentials)
render pg get my-db --include-sensitive-connection-info

# Disambiguate by project
render pg get my-db --project my-project

# Disambiguate a name that exists in multiple environments
render pg get my-db --environment production

# JSON output
render pg get dpg-abc123def456ghi789jkl0 --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Postgres database name exists in multiple environments. |
| `--include-sensitive-connection-info` | Include connection strings and credentials in the output |
| `--project` | Narrow lookup to a project (ID or name, optional) within the active workspace. |

###### `pg list`

List Render Postgres databases in the active workspace.

Use `--project` to narrow results to a single project, `--environment` to narrow
to a single environment, or both — when both are supplied, the environment is
resolved within that project.

*Usage:*

```bash
render pg list
```

*Aliases:* `ls`

*Examples:*

```bash
# List all Postgres databases in the active workspace
render pg list

# List all Postgres databases in a project
render pg list --project my-project

# Filter by environment name
render pg list --environment production

# Disambiguate an environment name by project
render pg list --project my-project --environment production

# JSON output
render pg list --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow results to a single environment (ID or name, optional). |
| `--project` | Narrow results to environments in a project (ID or name, optional). |

###### `pg resume <postgresID|postgresName>`

Resume a suspended Render Postgres database.

The positional argument accepts either a Postgres ID (dpg-...) or a name.
If the name matches more than one database, narrow the search with
`--project` <id|name>, `--environment` <id|name>, or pass the Postgres ID directly.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Postgres ID instead (which works across workspaces).

*Usage:*

```bash
render pg resume <postgresID|postgresName>
```

*Examples:*

```bash
# Resume by ID
render pg resume dpg-abc123def456ghi789jkl0

# Resume by name
render pg resume my-db

# Disambiguate a name that exists in multiple environments
render pg resume my-db --environment production

# Disambiguate a name that exists in multiple projects
render pg resume my-db --project analytics

# JSON output
render pg resume dpg-abc123def456ghi789jkl0 --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Postgres database name exists in multiple environments. |
| `--project` | Narrow lookup to a project (ID or name, optional) when the same Postgres database name exists in multiple projects. |

###### `pg suspend <postgresID|postgresName>`

Suspend a Render Postgres database.

Without `--confirm`, this command previews what would be suspended and makes no
changes. Pass `--confirm` to actually suspend the database.

The positional argument accepts either a Postgres ID (dpg-...) or a name.
If the name matches more than one database, narrow the search with
`--project` <id|name>, `--environment` <id|name>, or pass the Postgres ID directly.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Postgres ID instead (which works across workspaces).

*Usage:*

```bash
render pg suspend <postgresID|postgresName>
```

*Examples:*

```bash
# Preview suspension (no changes made)
render pg suspend dpg-abc123def456ghi789jkl0

# Suspend by ID
render pg suspend dpg-abc123def456ghi789jkl0 --confirm

# Suspend by name
render pg suspend my-db --confirm

# Disambiguate a name that exists in multiple environments
render pg suspend my-db --environment production --confirm

# Disambiguate a name that exists in multiple projects
render pg suspend my-db --project analytics --confirm

# JSON output
render pg suspend dpg-abc123def456ghi789jkl0 --confirm --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Postgres database name exists in multiple environments. |
| `--project` | Narrow lookup to a project (ID or name, optional) when the same Postgres database name exists in multiple projects. |

###### `pg update <postgresID|postgresName>`

Update an existing Render Postgres database.

The positional argument is the target database (ID dpg-... or name). At least
one mutating flag must be supplied. Use `--name` to rename the database; the
positional argument always identifies the target and is never the new name.

Environment, project, workspace, and region are immutable. A database cannot be
moved between them; the `--project` and `--environment` flags are for name
disambiguation only.

Only the fields you pass are changed; everything else is left untouched.

Name lookup is scoped to your active workspace. If a name isn't found, switch
workspaces with 'render workspace set <name|ID>' and try again, or pass the
Postgres ID instead (which works across workspaces). If a name matches more
than one database, narrow the search with `--project` <id|name> or
`--environment` <id|name>.

The `--ip-allow-list` flag replaces the server-side list; pass it once per entry.
To remove all allow-list entries, pass `--clear-ip-allow-list`. The two flags are
mutually exclusive.

*Usage:*

```bash
render pg update <postgresID|postgresName>
```

*Examples:*

```bash
# Rename
render pg update dpg-abc123def456ghi789jkl0 --name application_db

# Change plan
render pg update my-db --plan 1c-4g

# Grow the disk and enable autoscaling
render pg update my-db --disk-size-gb 50 --disk-autoscaling

# Replace the IP allow-list (entire list, not append)
render pg update my-db \
--ip-allow-list "cidr=203.0.113.5/32,description=office" \
--ip-allow-list "cidr=10.0.0.0/8,description=internal"

# Clear the IP allow-list
render pg update my-db --clear-ip-allow-list

# Disambiguate a name that exists in multiple environments
render pg update my-db --environment production --plan 2c-8g

# JSON output
render pg update dpg-abc123def456ghi789jkl0 --plan 1c-4g --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--clear-ip-allow-list` | Remove all IP allow-list entries. Mutually exclusive with `--ip-allow-list` |
| `--connection-pool` | Set connection pool to 'none' or 'pgbouncer' |
| `--datadog-api-key` | Set the Datadog API key for monitoring. Pass an empty string to remove. |
| `--datadog-site` | Set the Datadog region/site (e.g. US1, US3, EU) |
| `--disk-autoscaling` | Enable disk autoscaling. Pass `--disk-autoscaling=false` to disable. |
| `--disk-size-gb` | Set the disk size in GB. Must be 1 or a multiple of 5. |
| `--environment` | Narrow lookup to an environment (ID or name, optional) when the same Postgres database name exists in multiple environments. |
| `--high-availability` | Enable high availability (available for plans with at least 1 CPU). Pass `--high-availability=false` to disable. |
| `--ip-allow-list` | Replace the IP allow-list with the supplied entries (format: `cidr=<range>,description=<label>`). Repeat the flag for multiple entries. |
| `--name` | Rename the database |
| `--plan` | Set the plan to one of: free \| 0.1c-256mb \| 0.5c-1g \| 1c-2g \| 1c-4g \| 2c-4g \| 2c-8g \| 2c-16g \| 4c-16g \| 4c-32g \| 8c-32g \| 8c-64g \| 16c-64g \| 16c-128g \| 32c-128g \| 32c-256g \| 48c-192g \| 48c-384g \| 64c-256g \| 64c-512g \| 96c-384g \| 96c-768g \| 128c-512g \| 128c-1024g. Custom enterprise plan names are also accepted. |
| `--project` | Narrow lookup to a project (ID or name, optional) when the same Postgres database name exists in multiple projects. |

## Services

###### `services`

Lists all services and datastores for the active workspace. In interactive mode, you can view logs, restart services, trigger deploys, SSH into instances, and connect to Render Postgres databases and Render Key Value instances.

*Usage:*

```bash
render services
```

*Aliases:* `service`

*Available commands:*

| Command | Description |
| --- | --- |
| [`create`](#services-create) | Create a new service or clone an existing one |
| [`delete`](#services-delete) | Delete a service |
| [`instances`](#services-instances) | List instances for a service |
| [`update`](#services-update) | Update configuration for an existing service |

*Examples:*

```bash
# List all services
render services

# Output as JSON
render services --output json

# Filter by environment
render services -e env-abc123

# Include preview environments
render services --include-previews

# Combine filters
render services -e env-abc123,env-def456 --include-previews --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--environment-ids`, `-e` | Filter services by comma-separated environment IDs |
| `--include-previews` | Include preview environments |

###### `services create`

Create a new service on Render. This command only runs in non-interactive modes. Provide configuration options with flags.

*Usage:*

```bash
render services create
```

*Examples:*

```bash
# Create a service from repository configuration
render services create --name my-api --type web_service --repo https://github.com/org/repo --runtime node --build-command "npm install" --start-command "npm start" --output json

# Clone configuration from an existing service
render services create --from srv-abc123 --name my-api-clone --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--auto-deploy` | Enable auto-deploy |
| `--branch` | Set the Git branch |
| `--build-command` | Set the build command |
| `--build-filter-ignored-path` | Set build filter ignored paths (can be specified multiple times) |
| `--build-filter-path` | Set build filter paths (can be specified multiple times) |
| `--cron-command` | Set the cron command |
| `--cron-schedule` | Set the cron schedule |
| `--env-var` | Set environment variables in `KEY=VALUE` format (can be specified multiple times) |
| `--environment-id` | Set the environment ID |
| `--from` | Clone configuration from an existing service ID or name and override cloned values with other flags |
| `--health-check-path` | Set the health check path |
| `--image` | Set the Docker image URL |
| `--ip-allow-list` | Set IP allow list entries in `cidr=`..., `description=`... format (can be specified multiple times) |
| `--maintenance-mode` | Enable maintenance mode |
| `--maintenance-mode-uri` | Set the maintenance mode URI |
| `--max-shutdown-delay` | Set max shutdown delay in seconds |
| `--name` | Set the service name |
| `--num-instances` | Set the number of instances |
| `--plan` | Set the service plan |
| `--pre-deploy-command` | Set the pre-deploy command |
| `--previews` | Set preview generation mode |
| `--publish-directory` | Set the publish directory |
| `--region` | Set the deployment region |
| `--registry-credential` | Set the registry credential |
| `--repo` | Set the Git repository URL |
| `--root-directory` | Set the root directory |
| `--runtime` | Set the runtime environment |
| `--secret-file` | Set secret files in NAME:`LOCAL_PATH` format (can be specified multiple times) |
| `--start-command` | Set the start command |
| `--type` | Set the service type |

###### `services delete <serviceID|serviceName>`

Delete a service on Render.

Without `--confirm`, this command previews what would be deleted and makes no
changes. Pass `--confirm` to actually delete the service.

The positional argument accepts a service ID (including srv- or crn- IDs) or a
name. Name lookup is scoped to your active workspace. If the name matches more
than one service, pass the service ID directly.

This command only runs non-interactively. If `--output` interactive is requested,
it falls back to text output.

*Usage:*

```bash
render services delete <serviceID|serviceName>
```

*Examples:*

```bash
# Preview deletion (no changes made)
render services delete srv-abc123def456ghi789jkl0

# Delete by ID
render services delete srv-abc123def456ghi789jkl0 --confirm

# Delete by name
render services delete my-api --confirm

# JSON output
render services delete srv-abc123def456ghi789jkl0 --confirm --output json
```

*Options:*

[Global options](#global-options) only

###### `services instances [serviceID]`

List instances for a service

*Usage:*

```bash
render services instances [serviceID]
```

*Examples:*

```bash
# List instances for a service
render services instances srv-abc123

# Browse instances interactively
render services instances
```

*Options:*

[Global options](#global-options) only

###### `services update <service>`

Update a service on Render. This command only runs in non-interactive modes.

Provide configuration updates with flags.

*Usage:*

```bash
render services update <service>
```

*Examples:*

```bash
# Rename a service
render services update my-service --name my-new-name --output json

# Change a service plan
render services update srv-abc123 --plan 2c-4g --output json
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--auto-deploy` | Enable auto-deploy |
| `--branch` | Git branch |
| `--build-command` | Build command |
| `--build-filter-ignored-path` | Build filter ignored path (can be specified multiple times) |
| `--build-filter-path` | Build filter path (can be specified multiple times) |
| `--cron-command` | Cron command |
| `--cron-schedule` | Cron schedule |
| `--health-check-path` | Health check path |
| `--image` | Docker image URL |
| `--ip-allow-list` | IP allow list entry in `cidr=`..., `description=`... format (can be specified multiple times) |
| `--maintenance-mode` | Enable maintenance mode |
| `--maintenance-mode-uri` | Maintenance mode URI |
| `--max-shutdown-delay` | Max shutdown delay in seconds |
| `--name` | Service name |
| `--plan` | Service plan |
| `--pre-deploy-command` | Pre-deploy command |
| `--previews` | Preview generation mode |
| `--publish-directory` | Publish directory |
| `--registry-credential` | Registry credential |
| `--repo` | Git repository URL |
| `--root-directory` | Root directory |
| `--runtime` | Runtime environment |
| `--start-command` | Start command |

## Skills

###### `skills`

Install and manage Render agent skills for AI coding tools such as Claude Code, Codex, OpenCode, and Cursor. Skills add deployment, debugging, and monitoring capabilities to your AI coding assistant.

*Usage:*

```bash
render skills
```

*Available commands:*

| Command | Description |
| --- | --- |
| [`install`](#skills-install) | Install Render skills to AI coding tools |
| [`list`](#skills-list) | List installed Render skills and detected tools |
| [`remove`](#skills-remove) | Remove installed Render skills from AI coding tools |
| [`update`](#skills-update) | Update previously installed Render skills |

*Options:*

[Global options](#global-options) only

###### `skills install`

Install Render agent skills from https://github.com/render-oss/skills to detected AI coding tools.

Supported tools: Claude Code, Codex, OpenCode, Cursor.

Skills can be installed at two scopes:
  - user:    Install to ~/.{tool}/skills/ (default, current user only)
  - project: Install to ./.{tool}/skills/ (committed to Git, all collaborators)

By default an interactive prompt lets you pick scope, tools, and skills. Use `--scope`, `--tool`, and `--skill` flags to skip the prompts (useful for CI).

*Usage:*

```bash
render skills install
```

*Examples:*

```bash
# Install skills interactively
render skills install

# Install for a specific tool and scope
render skills install --tool cursor --scope project

# Preview install changes
render skills install --dry-run
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--dry-run` | Show what would be installed without making changes |
| `--scope` | Set installation scope to user or project (defaults to user) |
| `--skill` | Install specific skills only (use `--skill` multiple times) |
| `--tool` | Install skills to a specific tool only (claude, codex, opencode, or cursor) |

###### `skills list`

List installed Render skills and the AI tools they've been installed in. This reads from local state only, so the command doesn't require network access.

Use `--scope` to filter by installation scope (user or project).

*Usage:*

```bash
render skills list
```

*Examples:*

```bash
# List all installed skills
render skills list

# List project-scoped skills only
render skills list --scope project
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--scope` | Filter skills by installation scope (user or project) |

###### `skills remove`

Remove previously installed Render skills from detected AI coding tools.

By default an interactive prompt lets you pick which skills to remove. Use `--skill` and `--all` flags to skip the prompts.

Use `--scope` to remove from a specific scope (user or project).

*Usage:*

```bash
render skills remove
```

*Examples:*

```bash
# Remove skills interactively
render skills remove

# Remove specific skills
render skills remove --skill render-deploy --skill render-debug

# Remove all project-scoped skills
render skills remove --all --scope project
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--all` | Remove all installed Render skills |
| `--scope` | Remove skills from the specified scope (user or project) |
| `--skill` | Remove specific skills only (use `--skill` multiple times) |
| `--tool` | Remove skills from a specific tool only (claude, codex, opencode, or cursor) |

###### `skills update`

Reinstall Render skills using the tool and skill selections saved by a previous "render skills install" run.

This fetches the latest version of each selected skill from the skills repository, compares with installed versions, and updates any that have changed.

Use `--scope` to update skills at a specific scope (user or project).

*Usage:*

```bash
render skills update
```

*Examples:*

```bash
# Update installed skills
render skills update

# Force reinstall all skills
render skills update --force

# Update project-scoped skills
render skills update --scope project
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--force` | Reinstall all skills even if already up to date |
| `--scope` | Update skills at the specified scope (user or project) |

## Workflows

###### `workflows cancel <taskRunID>`

Cancel an in-progress task run.

Use `--local` to cancel a task run in the local workflow development server.

*Usage:*

```bash
render workflows cancel <taskRunID>
```

*Examples:*

```bash
# Cancel a remote task run
render workflows cancel trn-abc123

# Cancel a task run in the local dev server
render workflows cancel --local trn-xyz789
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--local` | Run against the local workflow development server |
| `--port` | Set the port of the local task server |

###### `workflows create`

Create a new workflow service on Render.

In interactive mode, a form guides you through the required fields.
In non-interactive mode, provide all required config with flags.

Environment variables (non-interactive only for now):

- Pass individual vars with `--env-var` `KEY=VALUE` (repeatable).

- Load from one or more .env files with `--env-file` PATH (repeatable). Every

    listed file must exist.

- Inline `--env-var` values override values from `--env-file`.

*Usage:*

```bash
render workflows create
```

*Examples:*

```bash
render workflows create
render workflows create --name my-workflow --repo https://github.com/org/repo --build-command "npm install" --runtime node --run-command "npm start" --region oregon -o json
render workflows create --repo . --name my-workflow --build-command "npm install" --runtime node --run-command "npm start"
render workflows create --repo . --name my-workflow --build-command "pip install -r requirements.txt" --runtime python --run-command ".venv/bin/python main.py" --env-file .env.production --env-var LOG_LEVEL=debug
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--auto-deploy-trigger` | Autodeploy behavior (commit, off, checksPass; default: commit) |
| `--branch` | Git branch (Optional) |
| `--build-command` | Build command. Required in non-interactive mode. |
| `--env-file` | Path to an env file to load. Repeat to load multiple files (later files override earlier ones). Every listed file must exist. |
| `--env-var` | Set environment variables in `KEY=VALUE` format (can be specified multiple times). Inline values override values loaded from `--env-file`. |
| `--name` | Workflow name. Required in non-interactive mode. |
| `--region` | Deployment region (default: oregon) |
| `--repo` | Git repository URL, or a local directory path (e.g. '.') to resolve via the repo's origin remote. Required in non-interactive mode. |
| `--root-directory` | Root directory in the repository (Optional) |
| `--run-command` | Command to run the workflow. Required in non-interactive mode. |
| `--runtime` | Runtime (node, python, go, ruby, elixir). Required in non-interactive mode. |

###### `workflows dev -- <command to start a workflow service>`

Start a workflow service in development mode for local testing.
Required input: -- <command to start a workflow service>

This command runs your workflow service locally on port 8120, allowing you to list and run tasks without deploying to Render. Task runs and their logs are stored in memory, so you can query them after tasks complete.

The command will spawn a new subprocess with your specified command whenever it needs to run a task or list the defined tasks.

To interact with the local task server:

- Use the `--local` flag with other task commands (e.g., 'render workflows tasks list `--local`')

- Or set `RENDER_USE_LOCAL_DEV=true` when using the workflow client SDK

To use a different port:

- Specify `--port` when starting the dev server

- Then use `--port` with other task commands, or set `RENDER_LOCAL_DEV_URL` in the SDK

Environment variables:

- A .env file in the current directory is loaded automatically if present

- Use `--env-file` to load one or more specific files (later files override earlier ones)

- Loaded values override variables inherited from the parent shell

*Usage:*

```bash
render workflows dev -- <command to start a workflow service>
```

*Examples:*

```bash
# Start local workflow development server
render workflows dev -- "python main.py"

# Start local workflow development server on a custom port
render workflows dev --port 9000 -- "npm start"

# Load environment variables from custom files
render workflows dev --env-file .env --env-file .env.local -- "python main.py"

# List local tasks from another terminal
render workflows tasks list --local
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--debug` | Print detailed workflow task execution events |
| `--env-file` | Path to an env file to load into the workflow subprocess. Repeat to load multiple files (later files override earlier ones). |
| `--port` | Set the port of the local task server |

###### `workflows init`

Scaffold a new Render Workflows project with example tasks.

Creates a working example project with task definitions, dependencies, and a README with instructions for local development and Client SDK integration.

In interactive mode you'll be prompted to select a language, template, output directory, and optional features. Use `--confirm` to skip all prompts and accept defaults, or pass individual flags to skip specific prompts.

With `--confirm` or non-interactive output (-o text/json/yaml), dependencies are installed and Git is initialized by default. Pass `--install-deps=false` or `--git=false` to opt out.

*Usage:*

```bash
render workflows init
```

*Examples:*

```bash
# Scaffold with default settings
render workflows init

# Skip prompts and use Python
render workflows init --confirm --language python

# Skip prompts and disable Git initialization
render workflows init --confirm --language python --git=false

# Customize output directory and enable optional features
render workflows init --language python --dir my-project --install-deps --git

# Use Node.js with a custom directory
render workflows init --language node --dir my-project
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--dir` | Output directory (default: ./workflows-demo) |
| `--git` | Initialize a Git repository (default true with `--confirm`) |
| `--install-agent-skill` | Install the Workflows agent skill for detected AI coding tools |
| `--install-deps` | Install dependencies after scaffolding (default true with `--confirm`) |
| `--language` | Language for the Render Workflows project (python, node) |
| `--template` | Template to scaffold (defaults to the repo's default template) |

###### `workflows list`

List workflow services in your workspace

*Usage:*

```bash
render workflows list
```

*Examples:*

```bash
# List workflows in the active workspace
render workflows list
```

*Options:*

[Global options](#global-options) only

###### `workflows start [taskSlug]`

Start a task with the provided input. In non-interactive mode, provide input with `--input` or `--input-file`.

You can specify the task by its workflow slug and task name (e.g., my-workflow/my-task), either as a positional argument or with `--task`.

Input Format:
The input should be a JSON array where each element is an argument to the task. For example, if your task takes two arguments, provide: ["arg1", "arg2"]

You can provide input via:

- `--input` with inline JSON

- `--input-file` with a path to a JSON file

In interactive mode, you will be prompted to select the task and provide the input.

*Usage:*

```bash
render workflows start [taskSlug]
```

*Examples:*

```bash
# Start a task run by task slug
render workflows start my-workflow/my-task --input='["arg1"]'

# Start a task run with --task
render workflows start --task tsk-1234 --input='["arg1", "arg2"]'

# Start a task run with input from a file
render workflows start my-task --input-file=input.json

# Start against the local workflow development server
render workflows start my-task --local --input='["test"]'
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--input` | Provide task input as a JSON array |
| `--input-file` | Read task input from a JSON file path |
| `--local` | Run against the local workflow development server |
| `--port` | Set the port of the local task server |
| `--task` | ID or slug of the task to run (alternative to the positional argument) |

###### `workflows tasks`

List tasks and manage their runs

*Usage:*

```bash
render workflows tasks
```

*Available commands:*

| Command | Description |
| --- | --- |
| [`list`](#workflows-tasks-list) | List tasks in a workflow version |
| [`runs`](#workflows-tasks-runs) | Start, list, and inspect task runs |

*Examples:*

```bash
# List tasks in a workflow version
render workflows tasks list wfv-1234

# Start a task run
render workflows tasks runs start --task my-task --input='["arg1"]'

# List task runs for a task
render workflows tasks runs list --task my-task
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--local` | Run against the local workflow development server |
| `--port` | Set the port of the local task server |

###### `workflows tasks list [workflowVersionID]`

List all tasks defined in a workflow version.

Tasks are user-defined functions registered with the Render Workflows SDK. Each time you release a workflow service, Render creates a new workflow version and registers all tasks it finds in that version.

In interactive mode, you will be prompted to select a workflow if not provided.

Local Development:
When using the `--local` flag, you don't need to provide a workflow version ID. Instead, the command connects to your local dev server (default port 8120) to list tasks from your running workflow service. Start the dev server first with:
  render workflows dev -- "<your command>"

*Usage:*

```bash
render workflows tasks list [workflowVersionID]
```

*Examples:*

```bash
# List tasks for a workflow version
render workflows tasks list wfv-1234

# List tasks from local workflow development server
render workflows tasks list --local
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--local` | Run against the local workflow development server |
| `--port` | Set the port of the local task server |

###### `workflows tasks runs`

Manage runs of workflow tasks.

A task run represents a single execution of a task with specific input parameters. Use these commands to start new runs, view task run history, inspect details, and cancel in-progress runs.

*Usage:*

```bash
render workflows tasks runs
```

*Available commands:*

| Command | Description |
| --- | --- |
| [`cancel`](#workflows-tasks-runs-cancel) | Cancel a running task run |
| [`list`](#workflows-tasks-runs-list) | List all execution runs for a specific task |
| [`show`](#workflows-tasks-runs-show) | Show detailed information about a task run |
| [`start`](#workflows-tasks-runs-start) | Start a task run with the provided input |

*Examples:*

```bash
# Start a task run
render workflows tasks runs start --task my-task --input='["arg1"]'

# List task runs for a task
render workflows tasks runs list --task my-task

# Show details for a task run
render workflows tasks runs show trn-1234

# Cancel a task run
render workflows tasks runs cancel trn-1234
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--local` | Run against the local workflow development server |
| `--port` | Set the port of the local task server |

###### `workflows tasks runs cancel [taskRunID]`

Cancel an in-progress task run.

Use `--local` to cancel a task run in the local workflow development server.

*Usage:*

```bash
render workflows tasks runs cancel [taskRunID]
```

*Examples:*

```bash
# Cancel a remote task run
render workflows tasks runs cancel trn-abc123

# Use the top-level shortcut
render workflows cancel trn-abc123

# Cancel a task run in the local dev server
render workflows tasks runs cancel --local trn-xyz789
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--local` | Run against the local workflow development server |
| `--port` | Set the port of the local task server |

###### `workflows tasks runs list [taskID]`

List all execution runs for a specific task.

A task run represents a single execution of a task with specific input parameters. This command shows the history of all runs for a given task.

You can specify the task by its workflow slug and task name (e.g., my-workflow/my-task), either as a positional argument or with `--task`.

In interactive mode, you will be prompted to select a task if not provided.

*Usage:*

```bash
render workflows tasks runs list [taskID]
```

*Examples:*

```bash
# List task runs by task ID
render workflows tasks runs list --task tsk-1234

# List task runs by task slug
render workflows tasks runs list --task my-workflow/my-task

# List task runs by passing the task as a positional argument
render workflows tasks runs list my-workflow/my-task

# List task runs from local workflow development server
render workflows tasks runs list --local --task my-task
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--local` | Run against the local workflow development server |
| `--port` | Set the port of the local task server |
| `--task` | ID or slug of the task whose runs to list (alternative to the positional argument) |

###### `workflows tasks runs show [taskRunID]`

Display detailed information about a specific task run execution.

This command shows comprehensive information about a task run, including:

- Task run ID and status

- Input parameters provided

- Output or error result

- Start and completion timestamps

The task run ID is returned when you execute a task with:
  render workflows tasks runs start

In interactive mode, you will be prompted to select a task run if not provided.

*Usage:*

```bash
render workflows tasks runs show [taskRunID]
```

*Examples:*

```bash
# Show details for a task run
render workflows tasks runs show trn-1234

# Show details from local workflow development server
render workflows tasks runs show --local trn-5678
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--local` | Run against the local workflow development server |
| `--port` | Set the port of the local task server |

###### `workflows tasks runs start [taskSlug]`

Start a task with the provided input. In non-interactive mode, provide input with `--input` or `--input-file`.

You can specify the task by its workflow slug and task name (e.g., my-workflow/my-task), either as a positional argument or with `--task`.

Input Format:
The input should be a JSON array where each element is an argument to the task. For example, if your task takes two arguments, provide: ["arg1", "arg2"]

You can provide input via:

- `--input` with inline JSON

- `--input-file` with a path to a JSON file

In interactive mode, you will be prompted to select the task and provide the input.

*Usage:*

```bash
render workflows tasks runs start [taskSlug]
```

*Examples:*

```bash
# Start a task run with inline JSON input
render workflows tasks runs start --task tsk-1234 --input='["arg1", "arg2"]'

# Start a task run by passing the task as a positional argument
render workflows tasks runs start my-workflow/my-task --input='["arg1"]'

# Start a task run with input from a file
render workflows tasks runs start --task my-task --input-file=input.json

# Start a task run against local workflow development server
render workflows tasks runs start --task my-task --local --input='["test"]'
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--input` | Provide task input as a JSON array |
| `--input-file` | Read task input from a JSON file path |
| `--local` | Run against the local workflow development server |
| `--port` | Set the port of the local task server |
| `--task` | ID or slug of the task to run (alternative to the positional argument) |

###### `workflows versions`

List and release workflow versions

*Usage:*

```bash
render workflows versions
```

*Available commands:*

| Command | Description |
| --- | --- |
| [`list`](#workflows-versions-list) | List versions of a workflow |
| [`release`](#workflows-versions-release) | Release a new workflow version |

*Examples:*

```bash
# List versions for a workflow
render workflows versions list wf-abc123

# Release a new workflow version
render workflows versions release wf-abc123
```

*Options:*

[Global options](#global-options) only

###### `workflows versions list [workflowID]`

List all versions of a workflow service.

Each time you release a workflow service, Render creates a new workflow version. A version represents a specific snapshot of your workflow service code and its registered tasks at the time of release.

This command displays all versions for a workflow, showing:

- Version ID

- Creation timestamp

- Associated tasks

In interactive mode, you will be prompted to select a workflow if not provided.

*Usage:*

```bash
render workflows versions list [workflowID]
```

*Examples:*

```bash
# List versions by workflow ID
render workflows versions list wf-1234

# List versions by workflow slug
render workflows versions list my-workflow-slug
```

*Options:*

[Global options](#global-options) only

###### `workflows versions release [workflowID]`

Release a new version of a workflow service.

This command triggers a new release of your workflow service on Render. With a new release, Render:

1. Pulls the latest code from your repository (or a specific commit)

2. Builds your workflow service

3. Registers all tasks it finds in the service

4. Creates a new workflow version

You can optionally specify a commit ID to release a specific version of your code.

In interactive mode, you will be prompted to:

- Select a workflow if not provided

- Confirm the release

*Usage:*

```bash
render workflows versions release [workflowID]
```

*Examples:*

```bash
# Release a new version
render workflows versions release wf-1234

# Release from a specific commit
render workflows versions release wf-1234 --commit abc123

# Wait for release completion
render workflows versions release wf-1234 --wait
```

*Options:*

[Global options](#global-options), plus:

| Option | Description |
| --- | --- |
| `--commit` | Release the specified commit ID |
| `--wait` | Wait for release completion and exit non-zero if release fails |

## Workspace

###### `workspace current`

Show the currently selected workspace

*Usage:*

```bash
render workspace current
```

*Examples:*

```bash
# Show the active workspace
render workspace current
```

*Options:*

[Global options](#global-options) only

###### `workspace set [workspaceName|workspaceID]`

Set the CLI's active workspace. All CLI commands run against the active workspace.

The active workspace is saved in cli.yaml in the Render CLI config directory. Set the `RENDER_CLI_CONFIG_DIR` environment variable to override this directory. If unspecified, the config file is saved in $HOME/.render/cli.yaml.

*Usage:*

```bash
render workspace set [workspaceName|workspaceID]
```

*Options:*

[Global options](#global-options) only