Render connector for AI agents

Tools your DevOps agent reaches for on Render, scoped per user.

CALL ANY TOOL

205 tools for cloud hosting on Render: services, deploys, jobs, logs, metrics, Postgres, Key Value, environment groups, custom domains, and workspace settings.

render_blueprint_disconnect

Blueprint disconnect

Disconnect a Blueprint by its ID, stopping automatic resource syncing from its render.yaml file. Returns no content on success. Disconnecting does not delete any services or other resources previously managed by the Blueprint. Use render_blueprint_disconnect when you want to stop a Blueprint from auto-syncing without removing the resources it created.

Parameters

Name

Type

Required

Description

blueprint_id

string

Required

The ID of the Blueprint to disconnect. Render Blueprint IDs use the `exs-` prefix, e.g. exs-cph1rs3idesc73a2b2mg.

render_blueprint_get

Get blueprint

render_blueprint_syncs_list

List blueprint syncs

render_blueprint_update

Update blueprint

render_cron_job_run

Run cron job

render_cron_job_run_cancel

Cancel cron job run

render_custom_domain_create

Create custom domain

render_custom_domain_delete

Delete custom domain

render_env_groups_list

List env groups

render_environment_delete

Delete environment

render_environment_resources_add

Add environment resources

render_environment_resources_remove

Remove environment resources

render_event_get

Get event

render_job_create

Create job

render_key_value_instance_resume

Resume key value instance

render_key_value_instance_update

Update key value instance

Update settings on an existing Key Value instance (Render's managed Redis-compatible data store) by ID, such as its name, plan, eviction policy, persistence mode, or IP allow list. Changing the plan, max memory policy, or persistence mode restarts the instance, causing a brief interruption. Returns the updated instance record with its current status, plan, region, owner, connection options, and IP allow list. Use render_key_value_instance_update to change configuration on an existing instance. Use render_key_value_instance_suspend or render_key_value_instance_resume to pause or resume it without changing its configuration.

Parameters

Name

Type

Required

Description

redis_id

string

Required

The ID of the Key Value instance to update, as returned by render_key_value_instances_list or render_key_value_instance_create.

ip_allow_list

array

Optional

Replacement list of CIDR blocks allowed to connect to this Key Value instance from outside Render's private network. Each entry needs a cidrBlock (e.g. 203.0.113.0/24) and a description explaining what it's for. Providing this replaces the existing allow list entirely. Example: [{"cidrBlock": "203.0.113.0/24", "description": "office network"}].

maxmemory_policy

string

Optional

The key eviction policy to use once the instance reaches its memory limit. Valid values: noeviction, allkeys_lfu, allkeys_lru, allkeys_random, volatile_lfu, volatile_lru, volatile_random, volatile_ttl. Leave unset to keep the current policy. Changing this restarts the instance. One of: `noeviction`, `allkeys_lfu`, `allkeys_lru`, `allkeys_random`, `volatile_lfu`, `volatile_lru`, `volatile_random`, `volatile_ttl`.

name

string

Optional

New name for the Key Value instance. Leave unset to keep the current name.

persistence_mode

string

Optional

The persistence mode for the instance. Valid values: journal_snapshot, snapshot, off. Only turn off persistence if you're using this instance purely as a cache and can tolerate losing data. Leave unset to keep the current setting. Changing this restarts the instance. One of: `journal_snapshot`, `snapshot`, `off`.

plan

string

Optional

New plan for the instance, which determines memory size and pricing. Valid values: free, starter, standard, pro, pro_plus, custom, 256mb, 1g, 5g, 10g, 20g, 40g. Leave unset to keep the current plan. Changing this restarts the instance. One of: `free`, `starter`, `standard`, `pro`, `pro_plus`, `custom`, `256mb`, `1g`, `5g`, `10g`, `20g`, `40g`.

render_maintenance_runs_list

List maintenance runs

render_metrics_bandwidth_sources_get

Get metrics bandwidth sources

render_metrics_memory_get

Get metrics memory

render_postgres_connection_info_get

Get postgres connection info

render_postgres_instance_delete

Delete postgres instance

render_postgres_instance_update

Update postgres instance

Update settings on an existing Postgres instance, such as its name, plan, disk size, disk autoscaling, high availability, connection pooling, IP allow list, read replicas, parameter overrides, or Datadog monitoring. Returns the updated Postgres instance record with its id, name, status, plan, region, disk size, high availability setting, and connection pool setting. Use render_postgres_instance_update to change how an existing database is configured. Any field left blank is unchanged; only the fields you provide are updated.

Parameters

Name

Type

Required

Description

postgres_id

string

Required

The ID of the Postgres instance to update. Render Postgres IDs use the `dpg-` prefix, e.g. dpg-cph1rs3idesc73a2b2mg.

connection_pool

string

Optional

Connection pooling mode for the database. Valid values: pgbouncer, none. Leave blank to keep the current setting. One of: `pgbouncer`, `none`.

datadog_api_key

string

Optional

Datadog API key for the Datadog agent to monitor this database. Pass an empty string to remove existing monitoring. Changing this restarts Postgres.

datadog_site

string

Optional

Datadog region/site to use for monitoring this database, e.g. US1. Leave blank to keep the current setting.

disk_size_gb

integer

Optional

The number of gigabytes of disk space to allocate for the database. Leave blank to keep the current disk size.

enable_disk_autoscaling

boolean

Optional

Whether to automatically grow the database's disk as it fills up. Leave blank to keep the current setting.

enable_high_availability

boolean

Optional

Whether to enable a high-availability standby for this database. Leave blank to keep the current setting.

ip_allow_list

array

Optional

Replacement list of CIDR blocks allowed to access this database from outside Render's network. Each entry needs a cidrBlock (e.g. 203.0.113.0/24) and a description. Example: [{"cidrBlock": "203.0.113.0/24", "description": "Office network"}]. Leave blank to keep the current list.

name

string

Optional

New display name for the database in the Render Dashboard. Leave blank to keep the current name.

parameter_overrides

object

Optional

Postgres configuration parameter overrides, as a JSON object mapping parameter name to string value. Example: {"max_connections": "200"}. Leave blank to keep the current overrides.

plan

string

Optional

New instance plan/size for the database. Leave blank to keep the current plan. One of: `free`, `starter`, `standard`, `pro`, `pro_plus`, `custom`, `basic_256mb`, `basic_1gb`, `basic_4gb`, `pro_4gb`, `pro_8gb`, `pro_16gb`, `pro_32gb`, `pro_64gb`, `pro_128gb`, `pro_192gb`, `pro_256gb`, `pro_384gb`, `pro_512gb`, `accelerated_16gb`, `accelerated_32gb`, `accelerated_64gb`, `accelerated_128gb`, `accelerated_256gb`, `accelerated_384gb`, `accelerated_512gb`, `accelerated_768gb`, `accelerated_1024gb`, `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`.

read_replicas

array

Optional

Read replica instances to create alongside the primary database. Each entry needs a name and may include parameterOverrides (a JSON object of parameter name to string value). Example: [{"name": "my-app-db-replica"}]. Leave blank to keep the current replicas.

render_postgres_processes_list

List postgres processes

render_redis_instance_resume

Resume redis instance

render_registry_credential_create

Create registry credential

render_registry_credentials_list

List registry credentials

render_service_autoscaling_delete

Delete service autoscaling

render_service_env_vars_update

Update service env vars

render_service_outbound_ips_get

Get service outbound ips

render_tasks_list

List tasks

For more tools, view docs.

Build your Agent

Same auth pattern across LangChain, OpenAI, Anthropic, and Google ADK.

import { ScalekitClient } from "@scalekit-sdk/node";
import { createReactAgent } from "@langchain/langgraph/prebuilt";

const sk = new ScalekitClient(env.SCALEKIT_ENV_URL, env.SCALEKIT_CLIENT_ID, env.SCALEKIT_CLIENT_SECRET);

// Render tools scoped to this user
const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["render"], toolNames: [
    "render_services_list",
    "render_deploys_list",
    "render_logs_list"] },
  pageSize: 100,
});

const agent = createReactAgent({ llm, tools });
await agent.invoke({ messages: [{ role: "user", content: "Show the last 5 deploys for the checkout-api service" }] });

import OpenAI from "openai";
import { ScalekitClient } from "@scalekit-sdk/node";

const sk = new ScalekitClient(env.SCALEKIT_ENV_URL, env.SCALEKIT_CLIENT_ID, env.SCALEKIT_CLIENT_SECRET);
const openai = new OpenAI();

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["render"] }, pageSize: 100,
});

const res = await openai.chat.completions.create({
  model: "gpt-5",
  messages: [{ role: "user", content: "Show the last 5 deploys for the checkout-api service" }],
  tools,
});

// Execute the tool call with the user's vaulted Render access token
await sk.tools.executeTool(res.choices[0].message.tool_calls[0], "user_123");

import Anthropic from "@anthropic-ai/sdk";
import { ScalekitClient } from "@scalekit-sdk/node";

const sk = new ScalekitClient(env.SCALEKIT_ENV_URL, env.SCALEKIT_CLIENT_ID, env.SCALEKIT_CLIENT_SECRET);
const anthropic = new Anthropic();

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["render"] }, pageSize: 100,
});

const msg = await anthropic.messages.create({
  model: "claude-sonnet-5",
  max_tokens: 1024,
  messages: [{ role: "user", content: "Show the last 5 deploys for the checkout-api service" }],
  tools,
});

// Tool call runs with the user's vaulted Render access token
await sk.tools.executeTool(msg.content, "user_123");

import { Agent } from "@google/adk/agents";
import { ScalekitClient } from "@scalekit-sdk/node";

const sk = new ScalekitClient(env.SCALEKIT_ENV_URL, env.SCALEKIT_CLIENT_ID, env.SCALEKIT_CLIENT_SECRET);

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["render"] }, pageSize: 100,
});

const agent = new Agent({
  name: "devops_agent",
  model: "gemini-2.5-pro",
  instruction: "Render tools scoped to this user",
  tools,
});

await agent.run("Show the last 5 deploys for the checkout-api service");

Try these prompts

Copy any prompt into your agent. Each maps directly to a Render tool. Click to copy, paste into your agent, done.

Services and deploys

Copy the prompt

Copied

List every service in my workspace and its current status.

Copy the prompt

Copied

Show the last 5 deploys for the checkout-api service.

Copy the prompt

Copied

Roll back checkout-api to its previous deploy.

Logs and metrics

Copy the prompt

Copied

Pull error logs for checkout-api from the last hour.

Copy the prompt

Copied

Show CPU and memory usage for the worker service today.

Copy the prompt

Copied

Get HTTP request latency for the web service over the last 24 hours.

Databases

Copy the prompt

Copied

List my Postgres instances and their plans.

Copy the prompt

Copied

Show the top queries on the production Postgres instance.

Copy the prompt

Copied

Get connection info for the cache Key Value instance.

SEE HOW AUTH WORKS

Each user connects their own Render access token once; Scalekit sends it with every call. Access tokens stay vaulted, every call is scope checked, and every action is logged.

Authorize

Your user connects

Render

once. We tie it to their identity and the meetings they approved — no shared bot account, no org-wide access

Who:

user ‘A’

when:

Once per user

access:

Limited to user

Store

Their

Render

token lives in a vault scoped to them. User A's meetings are never reachable by an agent acting for user B, even on the same connection

vault:

encrypted

scope:

per-user

tokens:

auto-refreshed

Resolve

When your agent calls a

Render

tool, we fetch the right token server-side. It never touches your agent, never appears in the LLM context, never shows up in your logs

speed:

~40ms

check:

before every call

seen by:

nobody

Audit

Every

Render

tool call is logged — who triggered it, which meeting was fetched, what came back. 90 days of history, tied to the user who authorized it

history:

90 days

export:

SIEM-ready

logged:

every call

Test other agents

See the same per-user auth pattern across other developer tools and hosting connectors.

Engineering Teams

DevOps assistant agent

Polls GitHub for failing checks and stale PRs, opens Linear issues for the ones that need work, and posts a daily digest to Slack. It acts as the engineer, not a shared service account.

Engineering Teams

Engineering standup agent

Pulls commits from GitHub and GitLab, tracks issue movement in Jira, and posts a per-engineer standup brief to Slack. Each engineer's activity is read on their own delegated OAuth.

Engineering Teams

Auto release notes agent

Reads merged GitHub PRs, groups them into structured release notes, publishes the page to Notion, and announces the release in Slack. Every call runs on the engineer's own delegated OAuth.

Engineering Teams

Slack triage

Polls Slack for new messages, classifies bugs and support requests with a LangGraph router, files GitHub issues or Zendesk tickets, and confirms in the thread.

Why Scalekit

Secure your agent's access. Connectors ship in minutes

01.

Shared tokens break per-user analytics

A shared Render access token looks fine in a demo. In production every deploy looks like one service account, and you cannot tell which user triggered it. Scalekit resolves the credential of the actual user who triggered the agent, never a shared bot.

// shared key
audit → bot_service_account

// scalekit
audit → user_abc ✓

02.

Authentication is not authorization

03.

Multi-tenancy is architectural

04.

Render today. Ten connectors tomorrow.

“Our agents act across Salesforce, Gong, Google Drive, and more, on behalf of every customer. Scalekit behind the scenes meant we can keep adding tools without ever rebuilding how credentials or tool calling work.”

Venu Madhav Kattagoni

Head of Engineering / Von

FAQs

Frequently Asked Questions

Does the agent access Render as the user or as a shared key?

As the user. Each user connects their own Render access token once, and Scalekit sends it with every call. Audit logs attribute every action to that user, not a shared service account.

Where is the Render access token stored?

In Scalekit's managed AES-256 token vault, namespaced per tenant. To rotate it, the user reconnects with a new access token. Revocation is a single dashboard action. Credentials never appear in prompts, logs, or LLM context.

Can I limit what the agent does in Render?

Yes. Filter by tool name in listScopedTools to expose only what you want, for example the list and get tools for services, deploys, logs, and metrics, without delete or suspend. Scalekit also enforces scope checks before every API call.

What happens when a user revokes Render access?

The connection is invalidated on the next tool call. Subsequent requests for that user fail closed with a clear error. Other users in the tenant remain unaffected. The event is logged for audit.

What can the agent do in Render?

205 tools across services, deploys, cron jobs, one-off jobs, logs, metrics, Postgres, Key Value and Redis instances, disks, environment groups, custom domains, webhooks, projects, and workspace members. Of those, 100 read data, 72 write, and 33 delete or remove resources.

On this page

Tool and actions Framework Compatibility Starter Prompt Auth Lifecycle Try Other Agents Why Scalekit