Migrate from Flash to the Runpod SDK

​

What changed at a glance

• One package. Install runpod instead of runpod-flash. The app SDK, the endpoint client, the Serverless worker SDK, and the API wrapper all ship together.
• One CLI. Flash commands now run as rp flash COMMAND. Account commands such as rp login live at the root of the same CLI. The CLI is also available as runpod, so runpod flash deploy works too.
• One login. rp login saves credentials to ~/.runpod/config.toml, which the whole SDK reads. RUNPOD_API_KEY is the only environment variable for authentication.
• An app-based API. Instead of decorating functions with @Endpoint, you create a runpod.App and attach resources to it with @app.queue, @app.api, or the new @app.task.
• A separate runtime. The code that runs on workers now ships in its own package, runpod-sdk-runtime, so it can be released independently of the SDK. See Runtime.
• A new major version. The unified SDK is runpod 2.0. Version 2.0 includes breaking changes, such as the removal of the old runpod config, runpod project, and runpod exec CLI commands. Until the stable release, you can test it with pip install runpod==2.0.0rc1.

​

What stays the same

• runpod.Endpoint("ENDPOINT_ID") and its run, run_sync, status, and output methods work exactly as before.
• runpod.serverless.start and the rest of the Serverless worker SDK are unchanged.
• API wrapper functions such as runpod.create_pod and runpod.get_pods still work.
• Your credentials file and RUNPOD_API_KEY carry over, so you don’t need to create a new API key.

​

Do you need to migrate?

• @app.task for running one ephemeral Pod per call, such as training or fine-tuning jobs.
• runpod.Secret for reading environment values from Runpod secrets.
• runpod.Model for platform-cached model weights.
• .spawn() and .stream() for background jobs and streamed results.
• rp logs for following a Pod’s logs from your terminal.

​

Requirements

• An existing Flash project.
• Python 3.10 to 3.14.
• The runpod package, version 2.0 or later.
• A Runpod account with a verified email address.

​

Step 1: Install the SDK and log in

pip uninstall runpod-flash
pip install runpod

# If using uv:
uv remove runpod-flash
uv add runpod

rp login

​

Step 2: Update your CLI commands

​

Step 3: Update your code

​

Imports and the app

​

Queue-based endpoints

import asyncio
from runpod_flash import Endpoint, GpuType

@Endpoint(
    name="hello-gpu",
    gpu=GpuType.NVIDIA_GEFORCE_RTX_4090,
    dependencies=["torch"],
)
async def hello():
    import torch
    return {"gpu": torch.cuda.get_device_name(0)}

print(asyncio.run(hello()))

import runpod

app = runpod.App("hello-gpu")

@app.queue(gpu="4090", dependencies=["torch"])
def hello():
    import torch
    return {"gpu": torch.cuda.get_device_name(0)}

@runpod.local_entrypoint
def main():
    print(hello.remote())

​

Load-balanced endpoints

from runpod_flash import Endpoint

api = Endpoint(name="my-api", cpu="cpu3c-1-2", workers=(1, 3))

@api.get("/health")
async def health():
    return {"status": "ok"}

@api.post("/compute")
async def compute(data: dict) -> dict:
    return {"result": data}

import runpod

app = runpod.App("my-api")

@app.api(cpu="cpu3c-1-2", workers=(1, 3))
class MyApi:
    @runpod.init
    def setup(self):
        # Runs once per worker before it takes traffic
        self.ready = True

    @runpod.get("/health")
    async def health(self):
        return {"status": "ok"}

    @runpod.post("/compute")
    async def compute(self, body: dict):
        return {"result": body}

​

Calling functions

​

Hardware

​

Storage

​

Other settings

​

Environment variables and secrets

​

Existing endpoints and custom images

​

Step 4: Check behavior that changed

• Default worker range. Resources now default to workers=(0, 3) instead of (0, 1), so a busy endpoint can scale to three workers. Set workers explicitly if you need a different limit.
• No local server in dev sessions. flash dev ran a local server on localhost:8888 with an API explorer at /docs. rp flash dev main.py runs your @runpod.local_entrypoint function instead and streams worker logs to your terminal. Update any local testing that sent curl requests to localhost:8888.
• Custom images work differently. You no longer need an image that implements a Serverless handler. The SDK runs your function on any image that has Python 3.
• One volume per endpoint. Lists of volumes across datacenters aren’t supported.
• Volumes keep billing. Undeploying an app doesn’t delete the network volumes it created. Delete them separately when you no longer need them.
• New ignore file. .flashignore is replaced by .runpodignore, and deployments also follow your project’s .gitignore files. .env files, keys, and credential files are always left out. See Ignore rules.
• Python version must match in dev sessions. Dev sessions and tasks send your function from your local Python, so your local interpreter must be 3.10 to 3.14. See Dev sessions.

​

Step 5: Test, then deploy

1. Run your migrated app once in a dev session and check the output:
   rp flash dev main.py --once
   
2. Fix any errors, then deploy:
   rp flash deploy
   
3. Confirm your endpoints on the Serverless page in the console.
4. When the new deployment works, remove the endpoints you deployed with Flash:
   flash undeploy --all
   

​

Known differences

• Projects split across multiple local files.
• Classes used as remote resources, other than @app.api classes.
• Path and query parameters on HTTP routes.
• Resources that reference an existing template or endpoint with template= or id=.

​

Flash deprecation timeline

​

Deprecation notice

• The flash CLI prints it to stderr on every command, including flash --help. Output on stdout, such as from flash --version, is unchanged.
• The Python package raises a FutureWarning the first time your code uses the Flash API, such as from runpod_flash import Endpoint.
• Deployed Flash workers don’t show the notice, so it doesn’t appear in your endpoint logs.

export RUNPOD_FLASH_SILENCE_DEPRECATION=1

​

Next steps

• Read the SDK overview to learn about apps, resource types, and storage.
• Configure resources with the full parameter reference.
• Build an app step by step.
• Review the CLI reference.
• Learn about the runtime that runs your code on workers.
• Browse the examples in the runpod-python repository.