Skip to main content
Deployments in the Runpod SDK are organized in two levels: apps and environments.

Apps

An app is a named group of resources, declared in code with runpod.App:
Every resource you attach with @app.queue, @app.api, or @app.task belongs to that app. Resource names come from the function or class name unless you pass name=, and they must be unique within the app. The app is registered on Runpod the first time you deploy it. A project can define more than one app; rp flash deploy deploys every app it finds.

Environments

An environment is an isolated deployment of an app, such as dev, staging, or production. Each environment has its own endpoints and runs its own build, so deploying to staging doesn’t affect production. Every app has a default environment. To deploy somewhere else, pass --env:
You can also set an app’s default environment in code with runpod.App("inference", env="production").

Common patterns

  • Single environment: Deploy everything to default. Simple, with no separation between testing and production.
  • Multiple environments: Deploy to dev while you work, staging for review, and production for users.

Builds

Each deployment uploads a build: an artifact containing your code, its dependencies, and a manifest describing every resource. The environment then runs that build. Undeploying an environment removes its endpoints but keeps the app’s build history. See Deploy an app.

Manage apps

Add --yes to delete to skip the confirmation prompt.

Manage environments

These commands use the app defined in the current directory. If the directory has more than one app, or none, pass --app APP_NAME. To remove an environment’s endpoints:
undeploy deletes the environment’s endpoints and the environment itself. The app and its build history remain. If you leave out --env, it undeploys the default environment.
Deleting an app or environment can’t be undone. Volumes aren’t deleted and keep incurring storage charges. See Storage.

Next steps

Last modified on October 15, 2026