Integration

RunPod integration for variables and secrets

Connect Wodby apps to a RunPod Serverless endpoint that exposes an OpenAI-compatible API, such as a vLLM worker. Wodby supplies its base URL and API key as OPENAI_BASE_URL and OPENAI_API_KEY to connected services.

Variables

Use your RunPod inference endpoint

Create the model endpoint in RunPod, then connect its OpenAI-compatible base URL and a RunPod API key to your app on Wodby.

Configure compatible clients

Apps that read OPENAI_BASE_URL and OPENAI_API_KEY can use the endpoint configuration supplied by the integration.

Supported workflows

How RunPod fits into Wodby

Each supported integration kind maps RunPod into a specific part of the delivery workflow, whether that means pulling source code, running pipelines, relaying email, connecting managed services, or injecting provider configuration into workloads.

Variables

API

Connect apps to an existing RunPod Serverless OpenAI-compatible endpoint using its base URL and API key.

  • Create a RunPod Serverless endpoint with an OpenAI-compatible worker, such as vLLM.
  • Use https://api.runpod.ai/v2/ENDPOINT_ID/openai/v1 as the base URL and provide a RunPod API key.
  • Connected services receive OPENAI_BASE_URL and OPENAI_API_KEY for compatible client configuration.

Configuration surfaced to workloads

OPENAI_BASE_URLOPENAI_API_KEY
See integration workflows

Related features

Explore the surrounding workflow

This provider usually sits next to stack-based delivery, backup workflows, managed databases, or integration-backed configuration. These pages cover the product surfaces most relevant to RunPod.

See integration workflows

Store provider keys, tokens, and DSNs once, then reuse them across environments.

View page

Browse all integrations

Compare this provider with the rest of the integration catalog and other supported workflows.

View page

Stack fit

Stacks that commonly pair with RunPod

Wodby does not treat integrations as isolated setup screens. They become part of stack delivery, so the strongest matches are the stacks where this provider solves a repeated operational problem.

  • Python

    Stack

    Python application stack for custom web apps, APIs, workers, and automation services.

    Connect Python inference clients to your RunPod endpoint through runtime API settings.

    View stack

  • Next.js

    Stack

    Next.js application stack for frontend and full-stack projects that need a reusable deployment setup.

    Next.js apps can receive provider configuration through the services that need it instead of scattering values across the repository.

    View stack

  • Node.js

    Stack

    Node.js application stack for APIs, workers, and custom services with a repeatable runtime setup.

    Node.js services can receive provider settings as runtime variables instead of repo-local env files.

    View stack

  • Laravel

    Stack

    Laravel application stack for teams that want a reusable setup for web, worker, and queue-based PHP projects.

    Laravel is a strong fit when provider credentials and configuration should stay centralized at the stack layer.

    View stack

Compare providers or keep reading

Use the catalog to compare other providers with the same integration kind, or read the broader feature pages to understand how integrations fit into Wodby stacks, CI/CD, backups, and managed services.

Browse all integrationsIntegration feature overview