The Cloud Built for AI - GPU cloud computing platform for AI and machine learning workloads
The Cloud Built for AI - GPU cloud computing platform for AI and machine learning workloads On Nagent, RunPod is exposed as a fully-configurable developer tools integration that any agent can call — 13 actions, and API key authentication. No code is required to wire RunPod into your workflow — connect it once via the External Integrations panel and reuse it across every agent you build.
Agent builders use RunPod to automate the kinds of tasks developer tools teams previously handled manually. Concrete examples — each one is a single agent step in Nagent — include:
Every action and trigger is paired with a structured input/output schema (visible in the sections below), so when you wire RunPod into Helix — our agentic agent builder — the editor knows exactly what each step expects and produces. Configure once, deploy anywhere across your Nagent agents.
Every operation an agent can call against RunPod, with input parameters and output schema. Drop these into any step of an agent built in Helix.
RUNPOD_CREATE_CLUSTERTool to create a new GPU cluster for multi-node distributed computing workloads on RunPod. Use when you need to deploy multiple pods with shared configuration for parallel processing, ML training, or HPC workloads.
Input parameters
Optional list of environment variables to set in the container. Each entry should be a dict with 'key' and 'value' fields.
Type of cluster to create: APPLICATION for general-purpose workloads, TRAINING for ML training jobs, or SLURM for high-performance computing with SLURM scheduler.
Optional comma-separated list of ports to expose on the pods.
Integer specifying the number of pods in the cluster. Must be at least 1.
Optional flag to enable SSH access on each pod. Default is false.
Optional Docker image name to use for the pods. If not specified, the template's default image is used.
Optional network throughput specification for the volume in MB/s.
Optional encryption key for the volume.
Optional maximum deployment cost threshold. If specified, deployment will fail if the estimated cost exceeds this value.
Optional Docker run arguments to pass when starting the container.
String identifier for the GPU type to use in the cluster (e.g., 'NVIDIA GeForce RTX 3070', 'NVIDIA A100 80GB PCIe').
Optional template ID to use for pod configuration. References a pre-configured pod template with specific Docker image and settings.
Optional name to identify the cluster. If not provided, a default name will be generated.
Optional size in GB for the persistent volume to attach to each pod.
Optional flag to automatically start JupyterLab on each pod. Default is false.
Optional data center ID to specify the geographical location for cluster deployment.
Optional minimum CUDA version required for the cluster.
Integer specifying the number of GPUs per pod. Must be at least 1.
Optional network volume ID to attach to all pods in the cluster for shared storage.
Optional path where the volume should be mounted inside the container.
Optional size in GB for the container disk. This is ephemeral storage that is reset when the pod restarts.
Optional list of allowed CUDA versions for the cluster.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_CREATE_SECRETTool to create a new secure secret in RunPod for credential management. Use when you need to store sensitive values like API keys, passwords, or tokens that will be accessible in pods and endpoints via environment variables (RUNPOD_SECRET_<name>).
Input parameters
Unique identifier name for the secret. This name will be used to reference the secret in pods and endpoints (accessible via environment variable RUNPOD_SECRET_<name>). Must be unique within your account.
The secret value to store securely. This will be encrypted and stored securely by RunPod.
Optional human-readable description of what this secret is used for. Helps with secret management and documentation.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_DELETE_REGISTRY_AUTHTool to delete container registry authentication from RunPod. Use when you need to remove stored registry credentials.
Input parameters
The ID of the container registry authentication to delete. This is the unique identifier returned when the registry authentication was created.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_DELETE_TEMPLATETool to remove a RunPod template via GraphQL mutation. Use when you need to delete a template that is no longer needed. The template must not be in use by any pods or assigned to any serverless endpoints, otherwise the operation will fail.
Input parameters
The name of the template to delete. The template must not be in use by any pods or assigned to any serverless endpoints.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_GET_GPU_TYPESTool to retrieve available GPU types and their specifications, pricing, and availability from RunPod. Use when you need to find GPU options for deployment.
Input parameters
Filter options for querying GPU types.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_GET_MYSELFRetrieve basic information about the authenticated user including ID, email, and security settings. Use this to get the current user's ID, email address, terms of service status, and MFA settings. Note: Access to financial fields (balance, spending, etc.) requires elevated API key permissions.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_GET_PODRetrieve details of a specific RunPod pod by its unique pod ID. Returns pod configuration including GPU count, memory, cost, and status. Use when you need to check the current state or configuration of an existing pod.
Input parameters
The unique identifier of the pod to retrieve. This is the pod ID assigned by RunPod when the pod was created.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_LIST_CPU_TYPESTool to retrieve available CPU types and their specifications from RunPod. Use when you need to view CPU options for provisioning pods or selecting hardware configurations.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_SAVE_ENDPOINTTool to create or update a RunPod serverless endpoint with GPU configuration and scaling settings. Use when configuring new GPU-accelerated serverless endpoints or modifying existing endpoint parameters. Include 'id' parameter to update an existing endpoint, omit it to create a new one.
Input parameters
Endpoint ID to update an existing endpoint. If provided, the mutation will update the existing endpoint instead of creating a new one. Omit this field to create a new endpoint.
Name of the endpoint (required for creation). Must be a descriptive identifier for the serverless endpoint.
GPU type identifier for the endpoint (required for creation). Examples: 'NVIDIA RTX A4000', 'NVIDIA A40', 'NVIDIA RTX A5000'. Specify the exact GPU model string from RunPod's available GPU types.
Comma-separated list of data center locations where the endpoint should run. Example: 'US-CA-1,US-OR-1'. If not specified, RunPod will choose automatically.
Type of autoscaling algorithm to use. Options: 'QUEUE_DELAY' (scale based on queue wait time), 'REQUEST_COUNT' (scale based on number of requests). QUEUE_DELAY is recommended for most use cases.
Template ID for the endpoint configuration (required for creation). This is the ID of a pre-configured template in your RunPod account.
Maximum number of workers (GPU instances) to scale up to. This is the upper limit for autoscaling. Must be >= workers_min.
Minimum number of workers (GPU instances) to keep running. Set to 0 to allow scaling down to zero when idle. Set to 1 or higher to maintain always-on capacity.
Idle timeout in seconds before workers are scaled down. Workers will be terminated after being idle for this duration. Common values: 5, 10, 30, 60.
Target value for the scaler. For QUEUE_DELAY: target delay in seconds before scaling up. For REQUEST_COUNT: target number of requests per worker. Common values: 1-10 for QUEUE_DELAY, 1-100 for REQUEST_COUNT.
Network volume ID to attach to the endpoint for persistent storage. If specified, this network volume will be mounted to all workers.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_SAVE_REGISTRY_AUTHTool to save container registry authentication credentials for accessing private Docker images in RunPod. Use when you need to store credentials for a private container registry.
Input parameters
A user-defined name for the container registry authentication credential. This name must be unique across all registry authentications in your account.
The password for authenticating with the container registry.
The username for authenticating with the container registry.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_SAVE_TEMPLATETool to create a new RunPod template or update an existing one with container configuration. Use when you need to define reusable pod/serverless configurations with specific images, environment variables, and resource allocations. For serverless templates, always set volumeInGb to 0.
Input parameters
List of environment variables to set in the container. Each entry must have 'key' and 'value' fields. Pass empty array if no env vars needed.
Unique name for the template. Must be unique across your account. Used to identify the template for pod or serverless deployment.
Comma-separated list of ports to expose from the container. Format: 'port/protocol' or just 'port'. Example: '8080/http,8888/http'
Markdown-formatted readme documentation for the template. Use this to document usage instructions, requirements, and configuration details.
Docker image to use for the template. Can be from Docker Hub or a private registry. Include the full image path with tag.
Additional Docker arguments to pass when starting the container. Use this for advanced Docker configuration. Leave empty if not needed.
ID of an existing template to update. Leave empty to create a new template. Provide the template ID to modify an existing template.
Network volume size in gigabytes for persistent storage. Set to 0 if no persistent volume is needed. For serverless templates, always use 0.
Whether this template is for serverless endpoints (true) or standard pods (false). Serverless templates must have volumeInGb set to 0.
Mount path for the network volume inside the container. Only applicable if volumeInGb > 0. Example: /workspace or /data
Container disk size in gigabytes. This is ephemeral storage that gets reset on pod restart. Minimum 10 GB recommended. Used for temporary files and cache.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_UPDATE_REGISTRY_AUTHTool to update existing container registry authentication credentials in RunPod. Use when you need to modify the username or password for an existing registry authentication.
Input parameters
The authentication credential identifier to update
The new password for registry authentication
The new username for registry authentication
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
RUNPOD_UPDATE_USER_SETTINGSTool to update current user settings (e.g., SSH public key) in RunPod. Use when you need to configure SSH access to pods by setting the user's SSH public key.
Input parameters
SSH public key to associate with the user account. This key will be used for SSH access to pods. Must be a valid SSH public key in OpenSSH format (e.g., 'ssh-rsa AAAAB3...' or 'ssh-ed25519 AAAAC3...').
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
No publicly available marketplace agent is found using this tool yet. There are 52 agents privately built on Nagent that already use RunPod.
Build on Nagent
Connect RunPod to any Nagent agent in minutes — no API key management, no boilerplate. Just configure and deploy.
The five questions agent builders ask before adopting a new integration.
Open the External Integrations panel inside Nagent (app.nagent.ai/externalIntegration), find RunPod, and click "Connect Now." You'll authenticate with an API key — Nagent handles credential storage and refresh automatically. Once connected, RunPod is available to any agent in your workspace.
No. Nagent provides no-code integration for every tool. Once RunPod is connected, you configure its 13 actions directly in the agent builder UI — no API calls, no boilerplate, no schema management.
Helix — Nagent's agentic agent builder — lets you drop RunPod steps into any workflow visually. Pick an action (e.g., one of those listed above), fill in the inputs (Helix knows the required vs. optional schema for each parameter), and connect it to upstream/downstream steps. Triggers run as the entry point of an agent, so when a RunPod event fires, the agent kicks off automatically.
Every RunPod action and trigger ships with a fully-typed schema — input parameters with name, type, required flag, and description, plus the output payload shape. The schemas are documented in the sections above. Helix uses these schemas to validate your configuration at build time and to type-check the data flowing between steps.
Yes. While RunPod ships with 13 pre-built developer tools actions, you can layer custom logic around them inside Helix — pre/post-processing steps, conditional branches, retries, or stitching RunPod together with other connected tools. For deeper customization, talk to our team about Nagent's Agentic AI Lab — forward-deployed engineers who build RunPod-based workflows tailored to your business.