Hub publishing guide
Publish your repositories to the RunPod Hub.
The RunPod Hub is currently in beta. We’re actively developing features and gathering user feedback to improve the experience. Please join our discord if you’d like to provide feedback.
Learn how to publish your repositories to the RunPod Hub, including how to configure your repository with the required hub.json
and tests.json
files.
How to publish your repo
Follow these steps to add your repository to the Hub:
- Navigate to the Hub page in the RunPod console.
- Under Add your repo click Get Started.
- Enter your GitHub repo URL.
- Follow the UI steps to add your repo to the Hub.
The Hub UI will walk you through how to:
- Create your
hub.json
andtests.json
files. - Ensure your repository contains a
handler.py
,Dockerfile
, andREADME.md
file (in either the.runpod
or root directory). - Create a new GitHub release (the Hub indexes releases, not commits).
- (Optional) Add a RunPod Hub badge into your GitHub
README.md
file, so that users can instantly deploy your repo from GitHub.
After all the necessary files are in place and a release has been created, your repo will be marked “Pending” during building/testing. After testing is complete, the RunPod team will manually review the repo for publication.
Update a repo
To update your repo on the Hub, just create a new GitHub release, and the Hub listing will be automatically indexed and built (usually within an hour).
Required files
Aside from a working Serverless implementation, every Hub repo requires two additional configuration files:
hub.json
- Defines metadata and deployment settings for your repo.tests.json
- Specifies how to test your repo.
These files should be placed in the .runpod
directory at the root of your repository. This directory takes precedence over the root directory, allowing you to override common files like Dockerfile
and README.md
specifically for the Hub.
hub.json reference
The hub.json
file defines how your listing appears and functions in the Hub.
You can build your hub.json
from scratch, or use this template as a starting point.
General metadata
Field | Description | Required | Values |
---|---|---|---|
title | Name of your tool | Yes | String |
description | Brief explanation of functionality | Yes | String |
type | Deployment type | Yes | "serverless" |
category | Tool category | Yes | "audio" , "embedding" , "language" , "video" , or "image" |
iconUrl | URL to tool icon | No | Valid URL |
config | RunPod configuration | Yes | Object (see below) |
RunPod configuration
Field | Description | Required | Values |
---|---|---|---|
runsOn | Machine type | Yes | "GPU" or "CPU" |
containerDiskInGb | Container disk space allocation | Yes | Integer (GB) |
cpuFlavor | CPU configuration | Only if runsOn is "CPU" | Valid CPU flavor string. For a complete list of available CPU flavors, see CPU types |
gpuCount | Number of GPUs | Only if runsOn is "GPU" | Integer |
gpuIds | GPU pool specification | Only if runsOn is "GPU" | Comma-separated pool IDs (e.g., "ADA_24" ) with optional GPU ID negations (e.g., "-NVIDIA RTX 4090" ). For a list of GPU pools and IDs, see GPU types. |
allowedCudaVersions | Supported CUDA versions | No | Array of version strings |
env | Environment variable definitions | No | Object (see below) |
presets | Default environment variable values | No | Object (see below) |
Environment variables
Environment variables can be defined in several ways:
-
Static variables: Direct value assignment. For example:
-
String inputs: User-entered text fields. For example:
-
Hugging Face inputs: Fields for model selection from Hugging Face Hub. For example:
-
Option inputs: User selected option fields. For example:
-
Number Inputs: User-entered numeric fields. For example:
-
Boolean Inputs: User-toggled boolean fields. For example:
Advanced options will be hidden by default. Hide an option by setting: "advanced": true
.
Presets
Presets allow you to define groups of default environment variable values. When a user deploys your repo, they’ll be offered a dropdown menu with any preset options you’ve defined.
Here are some example presets:
hub.json template
Here’s an example hub.json
file that you can use as a starting point:
tests.json reference
The tests.json
file defines test cases to validate your tool’s functionality. Tests are executed during the build step after a release has been created. A test is considered valid by the Hub if the endpoint returns a 200 response.
You can build your tests.json
from scratch, or use this template as a starting point.
Test cases
Each test case should include:
Field | Description | Required | Values |
---|---|---|---|
name | Test identifier | Yes | String |
input | Raw job input payload | Yes | Object |
timeout | Max execution time | No | Integer (milliseconds) |
Test environment configuration
Field | Description | Required | Values |
---|---|---|---|
gpuTypeId | GPU type for testing | Only for GPU tests | Valid GPU ID (see GPU types) |
gpuCount | Number of GPUs | Only for GPU tests | Integer |
cpuFlavor | CPU configuration for testing | Only for CPU tests | Valid CPU flavor string (see CPU types) |
env | Test environment variables | No | Array of key-value pairs |
allowedCudaVersions | Supported CUDA versions | No | Array of version strings |
tests.json template
Here’s an example tests.json
file that you can use as a starting point: