Enforce your style guide: voice and terminology fixes in Flash docs

api-reference-v2/migrate-from-v1.mdx

@@ -1,12 +1,12 @@
 ---
 title: "Migrate from API v1"
 sidebarTitle: "Migrate from v1"
 description: "Move your integrations from the Runpod REST API v1 to the v2 base URL, endpoints, and request and response shapes."
 ---
 
 The Runpod REST API v2 reorganizes resource paths, consolidates Pod lifecycle actions, and standardizes request and response shapes. This guide maps the v1 surface you know to its v2 equivalent so you can update your integrations with confidence.
 
 Read this guide if you have an existing integration built against the v1 API. REST API v1 is deprecated and will be retired on December 1, 2026. Migrate your integrations to v2 before that date.
 
 ## What changed at a glance
 
@@ -14,7 +14,7 @@
 
 - The OpenAPI schema also moves accordingly, from `https://rest.runpod.io/v1/openapi.json` to `https://api.runpod.io/v2/openapi.json`. Regenerate any client or tooling against the v2 schema.
 
 - Authentication is unchanged. Continue to pass your [Runpod API key](/get-started/api-keys) as an HTTP Bearer token in the `Authorization: Bearer RUNPOD_API_KEY` header. You don't need to change key management or scopes to call v2.
 
 ## Endpoint mapping
 
@@ -35,10 +35,10 @@
 v2 generalizes path parameters: where v1 used resource-specific names such as `{podId}`, `{endpointId}`, `{networkVolumeId}`, `{templateId}`, and `{containerRegistryAuthId}`, v2 uses a single generic `{id}` parameter across resources.
 
 <Warning>
-  Billing paths don't map by name. In v1, `/billing/endpoints` returns Serverless billing history; in v2, Serverless billing moves to `/v2/billing/serverless`. The v2 path `/v2/billing/endpoints` is a different, new resource — Public Endpoint billing history — so update your Serverless billing calls to the new path rather than assuming the old one carries over.
+  Billing paths don't map by name. In v1, `/billing/endpoints` returns Serverless billing history; in v2, Serverless billing moves to `/v2/billing/serverless`. The v2 path `/v2/billing/endpoints` is a different, new resource: Public Endpoint billing history. Update your Serverless billing calls to the new path rather than assuming the old one carries over.
 </Warning>
 
 ## Consolidated Pod lifecycle
 
 In v1, each Pod state change had its own endpoint: `POST /pods/{podId}/start`, `/stop`, `/reset`, and `/restart`. In v2, these collapse into a single [Pod state transition endpoint](/api-reference-v2/pods/trigger-a-pod-state-transition), `POST /v2/pods/{id}/action`, whose request body carries the desired action as `{"action":"start|stop|restart|terminate"}`. Deletion still uses [`DELETE /v2/pods/{id}`](/api-reference-v2/pods/terminate-a-pod).
 
@@ -46,7 +46,7 @@
   The v1 `reset` operation has no v2 action equivalent. The v2 action enum is limited to `start`, `stop`, `restart`, and `terminate`.
 </Note>
 
 For in-place changes to a Pod, v2 replaces v1's `POST /pods/{podId}/update` with a standard [PATCH request](/api-reference-v2/pods/update-a-pod) to `PATCH /v2/pods/{id}`. Serverless follows the same pattern: v2 drops v1's `POST /endpoints/{id}/update` in-place variant in favor of `PATCH /v2/serverless/{id}`.
 
 The following example shows how stopping a Pod changes between versions.
 
@@ -72,17 +72,17 @@
 
 ## Request and response shape changes
 
 The v2 request and response formats differ from v1. The most impactful changes are nested create bodies, wrapped list responses, and standardized error objects. Full field-by-field mapping is out of scope for this guide; see the linked reference pages for complete schemas.
 
 ### Nested create bodies
 
 - In v1, create bodies are flat, with top-level fields such as `gpuCount`, `gpuTypeIds`, `imageName`, `containerDiskInGb`, `volumeInGb`, `env`, and `ports`. The v2 `CreatePodRequest` is nested: `name` and `image` are required, GPU settings live under `gpu: {id, count}`, CPU settings under `cpu`, and storage under `mounts`. The `cloud` field defaults to `SECURE`, and you must set exactly one of `gpu` or `cpu`. See [Create a Pod](/api-reference-v2/pods/create-a-pod) for the full request schema.
 
 - Serverless endpoint creation changes more than its path. In v1, `EndpointCreateInput` requires a `templateId`. v2's `CreateEndpointRequest` still supports `templateId`: you can create an endpoint from a template ID, or provide the container details directly with `name`, `image`, and `gpu`. When you create from a template, `image` is optional because the template supplies it. Worker and scaling settings nest under `workers` and `scaling`, replacing v1's flat `workersMin`, `workersMax`, `scalerType`, and `idleTimeout`. See [Create a Serverless endpoint](/api-reference-v2/serverless/create-a-serverless-endpoint) for the full schema.
 
 - Templates share the same container-field renames as Pods: v1's `imageName`, `containerDiskInGb`, `isPublic`, and `containerRegistryAuthId` become `image`, `disk`, `public`, and a nested `registry` in v2. See [Create a template](/api-reference-v2/templates/create-a-template).
 
 - Network volume creation renames `dataCenterId` to `dataCenter` and adds an optional `type` field for selecting the storage tier (`STANDARD` or `HIGH_PERFORMANCE`). See [Create a network volume](/api-reference-v2/network-volumes/create-a-network-volume).
 
 ### Wrapped list responses
 
@@ -110,11 +110,11 @@
 
 The v2 wrapper key matches the resource: `GET /v2/pods` returns `{"pods":[...]}`, Serverless returns `{"endpoints":[...]}`, templates return `{"templates":[...]}`, network volumes return `{"networkVolumes":[...]}`, and registries return `{"registries":[...]}`. See [List Pods](/api-reference-v2/pods/list-pods) for a complete example.
 
 ### RFC 9457 error objects
 
 In v1, errors return a simple `{"message":"..."}` object. In v2, errors follow the RFC 9457 problem format with required `title`, `status`, and `detail` fields, plus an optional `errors` array of validation strings.
 
-As in v1, Runpod returns a `403` when a valid API key lacks access to the requested resource—but in v2 that response now uses the problem format shown here.
+As in v1, Runpod returns a `403` when a valid API key lacks access to the requested resource. In v2, that response now uses the problem format shown here.
 
 <CodeGroup>
 
@@ -136,7 +136,7 @@
 
 ## New in v2
 
-- The v2 API adds capabilities that have no v1 equivalent.
+The v2 API adds capabilities that have no v1 equivalent.
 
 - Catalog endpoints let you browse available compute without provisioning it: `GET /v2/catalog/gpus` and `/gpus/{id}`, `/cpus` and `/cpus/{id}`, and `/datacenters` and `/datacenters/{id}`. See [List GPU types](/api-reference-v2/catalog/list-gpu-types).
 
@@ -144,7 +144,7 @@
 
 - Serverless observability adds worker and release visibility through `GET /v2/serverless/{id}/workers`, `/workers/{workerId}/logs`, and `/releases`. See [List Serverless endpoint workers](/api-reference-v2/serverless/list-serverless-endpoint-workers), [Stream Serverless worker logs](/api-reference-v2/serverless/stream-serverless-worker-logs), and [List Serverless endpoint releases](/api-reference-v2/serverless/list-serverless-endpoint-releases).
 
 - Registry ECR delegations manage delegated registry access with `GET` and `POST /v2/registries/delegations` and `DELETE /v2/registries/delegations/{id}`. These endpoints aren't yet covered by a dedicated reference page during beta; consult the [v2 OpenAPI schema](/api-reference-v2/overview) for their request and response formats.
 
 - Expanded billing adds an aggregated history at `GET /v2/billing` alongside Serverless, Public Endpoint, and Instant Clusters histories, going beyond v1's Pods, endpoints, and network volume breakdowns. See [Get aggregated billing history](/api-reference-v2/billing/get-aggregated-billing-history).
 

flash/apps/build-app.mdx

@@ -1,10 +1,10 @@
 ---
 title: "Build a Flash app"
 sidebarTitle: "Build a Flash app"
 description: "Create a Flash app, test it locally, and deploy it to production. Review setup, configuration, deployment, and usage guidance for Runpod Flash."
 ---
 
 Flash apps let you build APIs to serve AI/ML workloads on Runpod Serverless. This guide walks you through the process of building a Flash app from scratch, from project initialization and local testing to production deployment.
 
 <Tip>
 If you haven't already, we recommend starting with the [Quickstart](/flash/quickstart) guide to get a feel for how Flash `@Endpoint` functions work.
@@ -31,7 +31,7 @@
 uv pip install runpod-flash
 ```
 
 Use the `flash init` command to generate a structured project template with a preconfigured application entry point:
 
 ```bash
 uv run flash init .
@@ -43,7 +43,7 @@
 uv run flash login
 ```
 
 This opens your browser to authorize Flash. After you approve, your credentials are saved for all Flash CLI commands.
 
 ## Step 2: Explore the project template
 
@@ -110,16 +110,16 @@
 uv run flash dev --auto-provision
 ```
 
 This eliminates cold-start delays by provisioning all serverless endpoints upfront. Endpoints are cached and reused across server restarts, making subsequent runs faster. Resources are identified by name, so the same endpoint won't be re-deployed if the configuration hasn't changed.
 
 ## Step 5: Open the API explorer
 
 Besides starting the API server, `flash dev` also starts an interactive API explorer. Point your web browser at [http://localhost:8888/docs](http://localhost:8888/docs) to explore the API.
 
 To run endpoint functions in the explorer:
 
 1. Expand one of the functions under **GPU Workers** or **CPU Workers**.
-2. Click **Try it out** and then **Execute**.
+2. Select **Try it out**, then **Execute**.
 
 You'll get a response from your workers right in the explorer.
 
@@ -127,14 +127,14 @@
 
 To customize your endpoints:
 
 1. Edit the `@Endpoint` functions in your worker files (`lb_worker.py`, `gpu_worker.py`, `cpu_worker.py`).
 2. Add new worker files for new endpoints.
 3. Test individual workers by running them as scripts (e.g., `python gpu_worker.py`).
 4. Restart the development server to pick up changes.
 
 ### Example: Adding a custom GPU endpoint
 
 To add a new GPU endpoint for image generation, create a new worker file or modify an existing one. For deployed apps, each queue-based function needs its own unique endpoint configuration:
 
 ```python
 from runpod_flash import Endpoint, GpuType
@@ -165,9 +165,9 @@
     return {"image": img_str, "prompt": prompt}
 ```
 
 This creates a new Serverless endpoint specifically for image generation. When deployed, it will be available at its own endpoint URL with its own `/run` or `/runsync` routes.
 
 ## Step 7: Deploy to Runpod
 
 When you're ready to deploy your app to Runpod, use `flash deploy`:
 
@@ -177,7 +177,7 @@
 
 This command:
 
 1. Builds your application into a deployment artifact.
 2. Uploads it to Runpod's storage.
 3. Provisions independent Serverless endpoints for each endpoint configuration.
 4. Configures service discovery for inter-endpoint communication.

flash/cli/build.mdx

@@ -1,9 +1,9 @@
 ---
 title: "build"
 sidebarTitle: "build"
 ---
 
 Build a deployment-ready artifact for your Flash application without deploying. Use this for more control over the build process or to inspect the artifact before deploying.
 
 ```bash
 flash build [OPTIONS]
@@ -49,17 +49,17 @@
 
 ## What happens during build
 
 1. **Python version resolution**: Resolves the target Python version from CLI flag, resource configs, or your local interpreter.
 2. **Function discovery**: Finds all `@Endpoint` decorated functions.
 3. **Grouping**: Groups functions by their endpoint configuration.
 4. **Manifest generation**: Creates `.flash/flash_manifest.json` with endpoint definitions.
 5. **Source fingerprinting**: Computes a SHA-256 fingerprint of your source files to detect code changes between deployments.
 6. **Dependency installation**: Installs Python packages for Linux x86_64.
 7. **Packaging**: Bundles everything into `.flash/artifact.tar.gz`.
 
 ## Built-in ignore patterns
 
 Flash automatically excludes certain files and directories from deployment artifacts. These patterns cover common development files that shouldn't be deployed to production.
 
 | Category | Patterns |
 |----------|----------|
@@ -78,9 +78,9 @@
 
 ### Local modules and the ignore filter
 
 Local (non-pip) modules that your endpoints import are bundled automatically, provided they pass the ignore filter: your `.gitignore` plus the built-in patterns listed above. During the build, Flash resolves the transitive local-import closure of every shipped Python file and checks it against the files the ignore filter already selected.
 
-If shipped code imports a local module that an ignore rule excludes (for example, a `test_*.py` sibling or a file under `tests/`), the build fails with a `LocalModuleResolutionError` instead of silently overriding your ignore rules or shipping a broken artifact. Flash names each excluded file and the file that imports it:
+If shipped code imports a local module that an ignore rule excludes (for example, a `test_*.py` sibling or a file under `tests/`), the build fails with a `LocalModuleResolutionError`. Failing early is deliberate: Flash won't silently override your ignore rules or ship a broken artifact. The error names each excluded file and the file that imports it:
 
 ```
 Shipped code imports local modules that the build ignore rules (.gitignore or built-in defaults) exclude:
@@ -89,7 +89,7 @@
 Shipping them would silently override a deliberate exclusion, and omitting them would break the worker with ModuleNotFoundError. Remove the matching ignore pattern or stop importing these modules from shipped code.
 ```
 
-If an `@Endpoint` file has a local import Flash can't resolve at all (a broken relative import, or a file outside your project root), the build also fails with a clear error. A file that fails resolution but doesn't define an endpoint is skipped with a warning and the build continues. For details on how local imports are resolved and bundled, see [Import local modules](/flash/create-endpoints#import-local-modules).
+If an `@Endpoint` file has a local import Flash can't resolve at all (for example, a broken relative import or a file outside your project root), the build fails with a clear error. If a file that doesn't define an endpoint fails resolution, Flash skips it with a warning and continues the build. For details on how local imports are resolved and bundled, see [Import local modules](/flash/create-endpoints#import-local-modules).
 
 ## Build artifacts
 
@@ -99,22 +99,22 @@
 |----------------|-------------|
 | `.flash/artifact.tar.gz` | Deployment package ready for Runpod |
 | `.flash/flash_manifest.json` | Service discovery configuration |
 | `.flash/.build/` | Build directory (kept for inspection) |
 
 ## Cross-platform builds
 
 Flash automatically handles cross-platform builds:
 
 - **Automatic platform targeting**: Dependencies are installed for Linux x86_64, regardless of your build platform.
 - **Binary wheel enforcement**: Only pre-built wheels are used, preventing compilation issues.
 
 ### Python version in deployed workers
 
 Flash workers support Python 3.10, 3.11, 3.12, and 3.13. The target version is determined by:
 
 1. **CLI flag:** The `--python-version` flag takes precedence.
 2. **Resource config:** The `python_version` parameter on your endpoint configs.
 3. **Local interpreter:** Your local Python version (from `sys.version_info`) when neither is specified.
 
 All resources in a Flash app must use the same Python version because Flash ships a single tarball for the entire app. If resources declare conflicting versions, the build fails.
 
@@ -127,19 +127,19 @@
 | 3.12 | No overhead | PyTorch pre-installed in base image |
 | 3.13 | +~7 GB on GPU | Alternative Python install required |
 | 3.11 | +~7 GB on GPU | Alternative Python install required |
 | 3.10 | +~7 GB on GPU | EOL 2026-10-31; consider migrating to 3.11+ |
 
 If your local Python version is not supported (for example, 3.9 or 3.14), the build fails with an actionable error message listing the supported versions.
 
 Image tags follow the pattern `py{version}-{tag}` (for example, `runpod/flash:py3.12-latest`).
 
 ## Managing deployment size
 
 Runpod Serverless has a **1.5GB deployment limit**. Flash automatically excludes packages that are pre-installed in the base image:
 
 - `torch`, `torchvision`, `torchaudio`, `triton`
 
 These packages are excluded at archive time, so you don't need to specify them manually.
 
 ### Manual exclusions
 
@@ -179,7 +179,7 @@
 
 ### Archive is too large
 
 Some CUDA packages (`torch`, `torchvision`, `torchaudio`, `triton`) are auto-excluded. If the archive is still too large, use `--exclude` to skip additional packages or `--no-deps` to skip transitive dependencies:
 
 ```bash
 flash build --exclude scipy,pandas
@@ -189,12 +189,12 @@
 
 If a package doesn't have Linux x86_64 wheels:
 
 1. Ensure standard pip is installed: `python -m ensurepip --upgrade`
 2. Check PyPI for Linux wheel availability.
 
 ### Need to examine generated files
 
 The build directory is kept after building. Inspect it with:
 
 ```bash
 ls .flash/.build/
@@ -202,12 +202,12 @@
 
 ## Related commands
 
 - [`flash deploy`](/flash/cli/deploy) - Build and deploy in one step (includes `--preview` option for local testing)
 - [`flash dev`](/flash/cli/dev) - Start development server
 - [`flash env`](/flash/cli/env) - Manage environments
 
 <Note>
 
-Most users should use `flash deploy` instead, which runs build and deploy in one step. Use `flash build` when you need more control or want to inspect the artifact.
+In most cases, use `flash deploy` instead, which runs build and deploy in one step. Use `flash build` when you need more control or want to inspect the artifact.
 
 </Note>

flash/create-endpoints.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Create endpoints"
 sidebarTitle: "Create endpoints"
 description: "Learn how to create and configure hardware and scaling behavior with the Flash Endpoint class. Review configuration and usage details for Runpod Flash."
@@ -22,7 +22,7 @@
     return {"result": "processed"}
 ```
 
 When you call `run_model(data)`, Flash provisions a GPU <WorkerTooltip /> on Runpod (or reuses an existing one), sends your function code and input to the worker, executes it, and returns the result to your local environment.
 
 Each unique endpoint `name` creates one Serverless endpoint on Runpod with its own URL, scaling configuration, and hardware allocation. The endpoint manages workers that scale up and down based on demand.
 
@@ -81,13 +81,13 @@
 ```
 
 Load-balanced endpoints are ideal for:
 - REST APIs with multiple routes
 - Low-latency request/response patterns
 - Services requiring custom HTTP methods
 
 ### Custom Docker images
 
 Deploy pre-built Docker images (like vLLM or your own workers) and interact with them as a client:
 
 ```python
 from runpod_flash import Endpoint, GpuType
@@ -103,7 +103,7 @@
 models = await vllm.get("/v1/models")
 ```
 
 See [Custom Docker images](/flash/custom-docker-images) for complete documentation, including available images and configuration options.
 
 ### Existing endpoints
 
@@ -123,11 +123,11 @@
 result = await ep.post("/v1/completions", {"prompt": "hello"})
 ```
 
 ## GPU vs CPU
 
 Specify `gpu=` for GPU endpoints or `cpu=` for CPU endpoints. They are mutually exclusive.
 
 ### GPU endpoints
 
 ```python
 from runpod_flash import Endpoint, GpuType, GpuGroup
@@ -145,9 +145,9 @@
 async def process(data: dict) -> dict: ...
 ```
 
 If neither `gpu=` nor `cpu=` is specified, GPU defaults to `GpuGroup.ANY`.
 
 ### CPU endpoints
 
 ```python
 from runpod_flash import Endpoint, CpuInstanceType
@@ -206,7 +206,7 @@
 
 ### Import packages inside the function body
 
 You must import pip/installed packages **inside the decorated function body**, not at the top of your file. This ensures imports happen on the remote worker. This rule applies to installed packages only; local project modules can be imported at the top of the file because Flash ships their source (see [Import local modules](#import-local-modules)).
 
 **Correct:** imports inside the function.
 ```python
@@ -227,7 +227,7 @@
 
 ### System dependencies
 
 Use `system_dependencies` to install system-level packages (via apt):
 
 ```python
 @Endpoint(
@@ -244,21 +244,21 @@
 
 ## Import local modules
 
-Your endpoint can import local (non-pip) Python modules that live alongside it in your project, such as a sibling `utils.py` file or a `helpers/` package. Flash detects these imports, follows them transitively, and ships the module source to the worker for you, so an import like `import utils` or `from helpers import load` works remotely with no extra configuration.
+Your endpoint can import local (non-pip) Python modules that live alongside it in your project, such as a sibling `utils.py` file or a `helpers/` package. Flash detects these imports, follows them transitively, and ships the module source to the worker for you. Imports like `import utils` or `from helpers import load` work remotely with no extra configuration.
 
 Flash resolves local imports whether they appear at the top of the file or inside the function body, and it supports absolute imports (`import utils`), relative imports (`from . import helpers`), and dynamic imports with a literal name (`importlib.import_module("plugin")`). It also pulls in the `__init__.py` files for any packages you import. Flash can't resolve dynamic imports whose module name is computed at runtime, so it emits a warning, and you're responsible for making those modules available on the worker.
 
-Flash bundles only local project files. Standard library modules are already present in the worker image, and pip packages must still be declared through the `dependencies` parameter. This applies transitively: if a bundled local module imports a pip package at its top level, that package must still be declared in the `dependencies` of any endpoint that uses the module.
+Flash bundles only local project files. Standard library modules are already present in the worker image, and pip packages must still be declared through the `dependencies` parameter. This applies transitively. If a bundled local module imports a pip package at its top level, declare that package in the `dependencies` of any endpoint that uses the module.
 
-On `flash build` and `flash deploy`, local modules are bundled when they pass the ignore filter, and importing a local module that an ignore rule excludes (or one Flash can't resolve) fails the build. See [Local modules and the ignore filter](/flash/cli/build#local-modules-and-the-ignore-filter) for details.
+On `flash build` and `flash deploy`, Flash bundles local modules that pass the ignore filter. Importing a local module that an ignore rule excludes (or one Flash can't resolve) fails the build. See [Local modules and the ignore filter](/flash/cli/build#local-modules-and-the-ignore-filter) for details.
 
 ### Live execution size limit
 
 When you run an endpoint live (calling an `@Endpoint` function directly, or during `flash dev`), Flash ships the resolved module source inline with the request. The combined source is capped at 8 MiB. If your local dependencies exceed this limit, deploy the app with `flash deploy` instead, which bundles local modules into the build artifact rather than the request payload. See [Local module payload too large](/flash/troubleshooting#local-module-payload-too-large) for the corresponding error.
 
 ### Local modules in a parent directory
 
 On the live execution path, Flash treats a module imported by absolute name from a parent directory as external and doesn't ship it, which causes a `ModuleNotFoundError` on the worker. For example, this happens with `import shared` when `shared.py` sits above your endpoint file. To avoid it, place your endpoint at or above its local dependencies, or use `flash deploy`, which resolves imports against the whole project directory.
 
 ## Parallel execution
 
@@ -312,7 +312,7 @@
 
 ## Persistent storage
 
 Attach a network volume for persistent storage across workers. Each volume is tied to a specific datacenter. Flash uses the volume `name` to find an existing volume or create a new one:
 
 ```python
 from runpod_flash import Endpoint, GpuGroup, DataCenter, NetworkVolume
@@ -330,7 +330,7 @@
     ...
 ```
 
 For multi-datacenter deployments, pass a list of volumes (one per datacenter):
 
 ```python
 from runpod_flash import Endpoint, GpuGroup, DataCenter, NetworkVolume
@@ -356,7 +356,7 @@
 
 For a complete list of parameters available for the `Endpoint` class, see [Endpoint parameters](/flash/configuration/parameters).
 
 ## Working with jobs (client mode)
 
 When using `Endpoint(id=...)` or `Endpoint(image=...)`, you get an `EndpointJob` object for async operations:
 

flash/overview.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Overview"
 sidebarTitle: "Overview"
 description: "Build autoscaling AI/ML apps using local code with Runpod Flash. Review setup, configuration, deployment, and usage guidance for Runpod Flash."
@@ -47,10 +47,10 @@
 Flash requires a Runpod account with a verified email address.
 </Note>
 
 ### Install Flash
 
 <Note>
-Flash requires [Python 3.10, 3.11, 3.12, or 3.13](https://www.python.org/downloads/) and runs natively on macOS and Linux. Windows users can run Flash through [WSL2](/flash/windows-wsl2).
+Flash requires [Python 3.10, 3.11, 3.12, or 3.13](https://www.python.org/downloads/) and runs natively on macOS and Linux. On Windows, run Flash through [WSL2](/flash/windows-wsl2).
 </Note>
 
 Install Flash using `pip` or `uv`:
@@ -74,9 +74,9 @@
 uv run flash login
 ```
 
 This saves your API key securely and allows you to use the Flash CLI and run `@Endpoint` functions.
 
 ### Coding agent integration (optional)
 
 Install the Flash skill package for AI coding agents like Claude Code, Cline, and Cursor:
 
@@ -88,24 +88,24 @@
 
 ## Flash apps
 
 When you're ready to move beyond scripts and build a production-ready API, you can create a [Flash app](/flash/apps/overview) (a collection of interconnected endpoints with diverse hardware configurations) and deploy it to Runpod.
 
 [Follow this tutorial to build your first Flash app](/flash/apps/build-app).
 
 ## Flash CLI
 
 The Flash CLI provides a set of commands for managing your Flash apps and endpoints.
 
 ```bash
 flash --help
 ```
 
 [Learn more about the Flash CLI](/flash/cli/overview).
 
 ## Limitations
 
-- Flash runs natively on macOS and Linux. Windows users can run Flash through [WSL2](/flash/windows-wsl2).
+- Flash runs natively on macOS and Linux. On Windows, run Flash through [WSL2](/flash/windows-wsl2).
 - CPU endpoints are restricted to the `EU-RO-1` datacenter. GPU endpoints can deploy to [multiple datacenters](/flash/configuration/parameters#datacenter).
 - Flash can rapidly scale workers across multiple endpoints, and you may hit your maximum worker threshold quickly. Contact [Runpod support](https://www.runpod.io/contact) to increase your account's capacity if needed.
 
 ## Tutorials

flash/quickstart.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Get started with Flash"
 sidebarTitle: "Quickstart"
 description: "Run your first GPU workload with Flash in less than 5 minutes. Review setup, configuration, deployment, and usage guidance for Runpod Flash."
@@ -13,10 +13,10 @@
 - [Python 3.10, 3.11, 3.12, or 3.13](https://www.python.org/downloads/) installed.
 - [uv](https://docs.astral.sh/uv/) installed.
 
 ## Step 1: Install Flash
 
 <Note>
-Flash runs natively on macOS and Linux. Windows users can run Flash through [WSL2](/flash/windows-wsl2).
+Flash runs natively on macOS and Linux. On Windows, run Flash through [WSL2](/flash/windows-wsl2).
 </Note>
 
 Create a virtual environment and install Flash using [uv](https://docs.astral.sh/uv/):
@@ -43,7 +43,7 @@
 
 This enables your coding agent to provide more accurate Flash code suggestions and troubleshooting help.
 
 ## Step 2: Authenticate with Runpod
 
 Log in to your Runpod account:
 
@@ -54,7 +54,7 @@
 uv run flash login
 ```
 
 This opens your browser to authorize Flash. After you approve, your credentials are saved, allowing you to run Flash commands and scripts.
 
 <Tip>
 Alternatively, you can set the `RUNPOD_API_KEY` environment variable or add it to a `.env` file. See [`flash login`](/flash/cli/login) for details.
@@ -113,7 +113,7 @@
 Make sure you activate your virtual environment in the same directory where you created the `gpu_demo.py` file. If you open a new terminal, run `source .venv/bin/activate` before executing the script.
 </Warning>
 
 ## Step 4: Run it
 
 Execute the script:
 
@@ -137,7 +137,7 @@
 ✓ GPU used: NVIDIA RTX A5000
 ```
 
 The first run takes 30-60 seconds, while Runpod provisions the endpoint, installs dependencies, and starts a worker. Subsequent runs take 2-3 seconds (because the worker is already running).
 
 
 <Tip>
@@ -172,7 +172,7 @@
 
 ## Step 6: Understand what you just did
 
 Let's break down the code you just ran:
 
 ### Imports and setup
 
@@ -181,7 +181,7 @@
 from runpod_flash import Endpoint, GpuGroup
 ```
 
 - **`asyncio`**: Enables asynchronous execution (endpoint functions run async).
 - **`Endpoint`**: The class that marks functions for remote execution.
 - **`GpuGroup`**: Enum for selecting GPU types or groups of GPUs.
 
@@ -221,12 +221,12 @@
 The `@Endpoint` decorator configures everything in one place:
 
 - **`name`**: Identifies your endpoint in the [Runpod console](https://console.runpod.io/serverless).
 - **`gpu`**: Which GPU to use (`GpuGroup.ANY` accepts any available GPU for faster provisioning).
 - **`workers`**: Maximum parallel workers (allows 3 concurrent executions).
 - **`idle_timeout`**: Seconds a worker stays active after completing a request before scaling down. Setting this to 300 (5 minutes) gives you more time to iterate on your code while the worker remains warm.
 - **`dependencies`**: Python packages to install on the worker.
 - **Function body**: The matrix multiplication code runs on the remote GPU, not your local machine.
 - **Return value**: The result is returned to your local machine as a Python dictionary.
 
 See [GPU types](/flash/configuration/gpu-types) for available GPUs or [endpoint functions](/flash/create-endpoints) for all configuration options.
 
@@ -256,9 +256,9 @@
    - If no: It creates a new endpoint, initializes a worker, and installs your dependencies.
 2. Flash sends your code to the GPU worker
 3. The GPU worker executes the function with the provided inputs.
 4. The result is returned to your local machine as a Python dictionary, where it's printed in your terminal.
 
 Everything outside the `@Endpoint` function (all the `print` statements, etc.) runs **locally on your machine**. Only the decorated function runs remotely.
 
 ## Step 7: Run multiple operations in parallel
 
@@ -334,7 +334,7 @@
 
 ## Next steps
 
 You've successfully run GPU code on Runpod! Now you're ready to learn more about Flash:
 
 <CardGroup cols={2}>
   <Card title="Generate images with Flash" href="/tutorials/flash/image-generation-with-sdxl" icon="image" horizontal>
@@ -359,7 +359,7 @@
 Error: API key is not set
 ```
 
 **Solution**: Run `flash login` to authenticate with your Runpod account:
 
 ```bash
 flash login
@@ -380,7 +380,7 @@
 Error: endpoint template names must be unique
 ```
 
 **Solution**: Each endpoint needs a unique `name`. If you've deployed an endpoint before with the same name, either:
 - Use a different name for your new endpoint
 - Undeploy the existing endpoint with `flash undeploy <name> --force`
 
@@ -391,7 +391,7 @@
 [Stays in queue for >60 seconds]
 ```
 
 **Solution**: No GPUs available. Use `GpuGroup.ANY` to accept any available GPU:
 
 ```python
 @Endpoint(
@@ -427,7 +427,7 @@
 ModuleNotFoundError: No module named 'numpy'
 ```
 
 **Solution**: Move imports inside the `@Endpoint` function:
 
 ```python
 @Endpoint(name="compute", gpu=GpuGroup.ANY, dependencies=["numpy"])

flash/troubleshooting.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Troubleshooting"
 sidebarTitle: "Troubleshooting"
 description: "Monitor, debug, and troubleshoot Flash deployments. Review setup, configuration, deployment, and usage guidance for Runpod Flash."
@@ -10,7 +10,7 @@
 
 ### Viewing logs
 
 When running Flash functions, logs are displayed in your terminal:
 
 ```text
 2025-11-19 12:35:15,109 | INFO  | Created endpoint: rb50waqznmn2kg - flash-quickstart
@@ -35,7 +35,7 @@
 View detailed metrics and logs in the [Runpod console](https://console.runpod.io/serverless):
 
 1. Navigate to the **Serverless** section.
-2. Click on your endpoint to view:
+2. Select your endpoint to view:
    - Active workers and queue depth.
    - Request history and job status.
    - Worker logs and execution details.
@@ -48,9 +48,9 @@
 
 1. Go to the [Serverless console](https://console.runpod.io/serverless).
 2. Select your endpoint.
-3. Click on a worker to view its logs.
+3. Select a worker to view its logs.
 
 Logs include dependency installation output, function execution output (print statements, errors), and system-level messages.
 
 ### Add logging to functions
 
@@ -84,7 +84,7 @@
 Get a key: https://docs.runpod.io/get-started/api-keys
 ```
 
 **Cause:** Flash requires a valid Runpod API key to provision and manage endpoints.
 
 **Solution:**
 
@@ -92,18 +92,18 @@
 
 2. Authenticate using one of these methods:
 
    **Option 1: Use `flash login` (recommended)**
    ```bash
    flash login
    ```
    Opens your browser for authentication and saves your credentials.
 
    **Option 2: Environment variable**
    ```bash
    export RUNPOD_API_KEY="your_api_key"
    ```
 
    **Option 3: .env file for local CLI use**
    ```bash
    echo "RUNPOD_API_KEY=your_api_key" >> .env
    ```
@@ -112,7 +112,7 @@
    Values in your `.env` file are only available locally for CLI commands. They are not passed to deployed endpoints.
    </Note>
 
    **Option 4: Shell profile for persistent local access**
    ```bash
    echo 'export RUNPOD_API_KEY="your_api_key"' >> ~/.bashrc
    source ~/.bashrc
@@ -126,9 +126,9 @@
 Run 'flash login' to re-authenticate, or delete the file and retry.
 ```
 
 **Cause:** The credentials file at `~/.runpod/config.toml` contains invalid TOML and cannot be read. This can also appear as "No API key found" even after a successful `flash login`.
 
 **Solution:** Delete the credentials file and re-authenticate:
 
 ```bash
 rm ~/.runpod/config.toml
@@ -142,9 +142,9 @@
 Load-balanced endpoints require route decorators
 ```
 
 **Cause:** Load-balanced endpoints require HTTP method decorators for each route.
 
 **Solution:** Ensure all routes use the correct decorator pattern:
 
 ```python
 from runpod_flash import Endpoint
@@ -161,16 +161,16 @@
     return {"status": "healthy"}
 ```
 
 ### Invalid HTTP method
 
 **Error:**
 ```
 method must be one of {'GET', 'POST', 'PUT', 'DELETE', 'PATCH'}
 ```
 
 **Cause:** The HTTP method specified is not supported.
 
 **Solution:** Use one of the supported HTTP methods: `GET`, `POST`, `PUT`, `DELETE`, or `PATCH`.
 
 ### Invalid path format
 
@@ -179,9 +179,9 @@
 path must start with '/'
 ```
 
 **Cause:** HTTP paths must begin with a forward slash.
 
 **Solution:** Ensure paths start with `/`:
 
 ```python
 # Correct
@@ -198,13 +198,13 @@
 Duplicate route 'POST /process' in endpoint 'my-api'
 ```
 
 **Cause:** Two functions define the same HTTP method and path combination.
 
 **Solution:** Ensure each route is unique within an endpoint. Either change the path or method of one function.
 
 ## Build errors
 
 ### Unsupported Python version
 
 **Error:**
 ```
@@ -212,13 +212,13 @@
 Pass --python-version, declare python_version on a resource config, or run flash from a supported interpreter.
 ```
 
 **Cause:** Flash supports Python 3.10, 3.11, 3.12, and 3.13. Your local Python version is outside this range.
 
 **Solution:**
 
 You have three options:
 
 1. **Use the `--python-version` CLI flag** to override local detection:
    ```bash
    flash build --python-version 3.12
    flash deploy --python-version 3.12
@@ -244,7 +244,7 @@
 Python 3.12 is recommended for best performance with no cold-start overhead. Python 3.10, 3.11, and 3.13 incur additional cold-start overhead on GPU workers because an alternative Python interpreter must be installed.
 </Tip>
 
 ### Local module could not be resolved
 
 **Error:**
 ```
@@ -260,7 +260,7 @@
 Shipping them would silently override a deliberate exclusion, and omitting them would break the worker with ModuleNotFoundError. Remove the matching ignore pattern or stop importing these modules from shipped code.
 ```
 
 **Cause:** This `LocalModuleResolutionError` has two variants: an `@Endpoint` file imports a local module that Flash can't resolve, or shipped code imports a local module that an ignore pattern excludes.
 
 **Solution:**
 
@@ -283,11 +283,11 @@
 Tarball exceeds maximum size. File size: 1.6GB, Max: 1.5GB
 ```
 
 **Cause:** The deployment package exceeds the 1.5GB limit.
 
 **Solution:**
 
 1. Check for large files that shouldn't be included (datasets, model weights, logs).
 2. Add large files to `.gitignore` to exclude them from the build.
 3. Use [network volumes](/flash/configuration/storage) to store large models instead of bundling them.
 
@@ -298,25 +298,25 @@
 File is not a valid gzip file. Expected magic bytes (31, 139)
 ```
 
 **Cause:** The build artifact is corrupted or not a valid gzip file.
 
 **Solution:** Delete the `.flash` directory and rebuild:
 
 ```bash
 rm -rf .flash
 flash build
 ```
 
 ### SSL certificate verification failed
 
 **Error:**
 ```
 SSL certificate verification failed. This usually means Python cannot find your system's CA certificates.
 ```
 
 **Cause:** Python cannot locate the system's trusted CA certificates, preventing secure connections during deployment. This commonly occurs on fresh Python installations, especially on macOS.
 
 **Solution:** Try one of these fixes:
 
 1. **Install certifi and set the certificate bundle path:**
    ```bash
@@ -324,7 +324,7 @@
    export REQUESTS_CA_BUNDLE=$(python -c "import certifi; print(certifi.where())")
    ```
 
 2. **macOS only:** Run the certificate installer that comes with Python. Find it in your Python installation folder (typically `/Applications/Python 3.x/`) and run `Install Certificates.command`.
 
 3. **Add to shell profile for persistence:**
    ```bash
@@ -343,7 +343,7 @@
 Failed to provision resources: [error details]
 ```
 
 **Cause:** Flash couldn't create the Serverless endpoint on Runpod.
 
 **Solutions:**
 
@@ -365,7 +365,7 @@
 Endpoint URL not available - endpoint may not be deployed
 ```
 
 **Cause:** The endpoint function was called before the endpoint finished provisioning.
 
 **Solutions:**
 
@@ -382,7 +382,7 @@
 Execution timeout on [endpoint] after [N]s
 ```
 
 **Cause:** The endpoint function took longer than the configured timeout.
 
 **Solutions:**
 
@@ -397,7 +397,7 @@
 
 2. **Optimize function**: Profile your function to identify bottlenecks.
 
 3. **Use queue-based endpoints**: For long-running tasks, use the `@Endpoint` decorator pattern. Queue-based endpoints are designed for longer operations.
 
 ### Connection failed
 
@@ -406,7 +406,7 @@
 Failed to connect to endpoint [name] ([url])
 ```
 
 **Cause:** Network connectivity issue between your local environment and the Runpod endpoint.
 
 **Solutions:**
 
@@ -414,14 +414,14 @@
 2. **Retry**: Transient network issues often resolve on retry. Flash includes automatic retry logic.
 3. **Check endpoint status**: Verify the endpoint is running in the [Serverless console](https://console.runpod.io/serverless).
 
 ### HTTP errors from endpoint
 
 **Error:**
 ```
 HTTP error from endpoint [name]: 500 - Internal Server Error
 ```
 
 **Cause:** The endpoint function raised an exception during execution.
 
 **Solutions:**
 
@@ -447,7 +447,7 @@
 Failed to deserialize result: [error]
 ```
 
 **Cause:** The function's return value cannot be serialized/deserialized.
 
 **Solutions:**
 
@@ -471,11 +471,11 @@
 Payload size X MB exceeds limit of 10.0 MB
 ```
 
 **Cause:** The serialized argument exceeds the 10 MB limit. Flash uses base64 encoding, which expands data by approximately 33%, so roughly 7.5 MB of raw data becomes 10 MB when encoded.
 
 **Solutions:**
 
 1. **Use network volumes for large data**: Save large data to a network volume and pass the file path:
    ```python
    @Endpoint(name="processor", gpu=GpuGroup.ANY, volume="vol_abc123")
    async def process(file_path: str) -> dict:
@@ -484,7 +484,7 @@
        return {"result": process_data(data)}
    ```
 
 2. **Compress data before sending**: For data that must be passed directly, use compression:
    ```python
    import gzip
 
@@ -502,9 +502,9 @@
 Use `flash deploy` for endpoints with large local dependencies.
 ```
 
 **Cause:** On the live execution path (calling an `@Endpoint` function directly or during `flash dev`), Flash ships your local module source inline with the request, and the combined source exceeds the 8 MiB cap.
 
 **Solution:** Deploy the app with `flash deploy`, which bundles local modules into the build artifact instead of the request payload:
 
 ```bash
 flash deploy
@@ -513,7 +513,7 @@
 uv run flash deploy
 ```
 
 See [Live execution size limit](/flash/create-endpoints#live-execution-size-limit) for details on how local module source is shipped.
 
 ### Deserialization timeout
 
@@ -522,9 +522,9 @@
 Deserialization timed out after 30s
 ```
 
 **Cause:** The deserialization process took longer than 30 seconds. This usually indicates malformed or corrupted serialized data that causes the unpickle operation to hang.
 
 **Solution:** Verify your input data is properly serialized. If you're manually constructing payloads, ensure the data was serialized using `cloudpickle` and encoded with base64. The Flash SDK handles this automatically for programmatic calls.
 
 ### Circuit breaker open
 
@@ -533,23 +533,23 @@
 Circuit breaker is open. Retry in [N] seconds
 ```
 
 **Cause:** Too many consecutive failures to the endpoint triggered the circuit breaker protection.
 
 **Solutions:**
 
 1. **Wait and retry**: The circuit breaker will automatically attempt recovery after the timeout (typically 60 seconds).
 
 2. **Check endpoint health**: Multiple failures usually indicate an underlying issue. Check logs and endpoint status.
 
 3. **Fix the root cause**: Address whatever is causing the repeated failures before retrying.
 
 ## GPU availability issues
 
 ### Job stuck in queue
 
 **Symptom:** Job status shows `IN_QUEUE` for extended periods.
 
 **Cause:** The requested GPU types are not available.
 
 **Solutions:**
 
@@ -565,7 +565,7 @@
    )
    ```
 
 2. **Use GpuGroup.ANY**: For development, accept any available GPU:
    ```python
    gpu=GpuGroup.ANY
    ```
@@ -578,14 +578,14 @@
 
 ### Module not found
 
 **Error (in worker logs):**
 ```
 ModuleNotFoundError: No module named 'transformers'
 ```
 
 **Cause:** A required dependency was not specified in the `@Endpoint` decorator.
 
 **Solution:** Add all required packages to the `dependencies` parameter:
 
 ```python
 @Endpoint(
@@ -600,11 +600,11 @@
 
 ### Version conflicts
 
 **Symptom:** Function fails with import errors or unexpected behavior.
 
 **Cause:** Dependency version conflicts between packages.
 
 **Solution:** Pin specific versions:
 
 ```python
 @Endpoint(

release-notes.mdx

@@ -11,7 +11,7 @@ rss: true
 
 **August 18, 2026**
 
-<h4><Badge color="green">New Release</Badge> [REST API v2](/api-reference-v2/overview)</h4> REST API v2 is now generally available. v2 moves to a new base URL (`https://api.runpod.io/v2`), reorganizes resource paths, standardizes request and response shapes, and adds new capabilities including catalog endpoints, pod log streaming, and Serverless observability. See the [migration guide](/api-reference-v2/migrate-from-v1) to move your existing integrations.
+<h4><Badge color="green">New Release</Badge> [REST API v2](/api-reference-v2/overview)</h4> REST API v2 is now generally available. v2 moves to a new base URL (`https://api.runpod.io/v2`), reorganizes resource paths, and standardizes request and response shapes. It also adds new capabilities including catalog endpoints, Pod log streaming, and Serverless observability. See the [migration guide](/api-reference-v2/migrate-from-v1) to move your existing integrations.
 
 <h4><Badge color="red">Deprecation</Badge> REST API v1</h4> REST API v1 will be retired on **November 15, 2026**. Migrate your integrations to [REST API v2](/api-reference-v2/overview) before that date. See the [migration guide](/api-reference-v2/migrate-from-v1) to get started.
 

serverless/overview.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Overview"
 description: "Pay-as-you-go compute for AI models and compute-intensive workloads. Review configuration and operations guidance for Runpod Serverless."
 mode: "wide"
@@ -8,7 +8,7 @@
 
 <div className="overview-page-wrapper" />
 
 Runpod Serverless is a cloud computing platform that lets you serve AI models for <InferenceTooltip /> and run other compute-intensive workloads without managing servers. You only pay for the actual compute time you use, with no idle costs when your application isn't processing requests.
 
 ## Get started
 
@@ -28,15 +28,15 @@
 
 ### [Endpoints](/serverless/endpoints/overview)
 
 The access point for your Serverless application. Endpoints provide a URL where users or applications can send requests to run your code. Each endpoint can be configured with different compute resources, scaling settings, and other parameters to suit your specific needs.
 
 ### [Workers](/serverless/workers/overview)
 
 The container instances that execute your code when requests arrive at your endpoint. Each worker runs your custom Docker container with your application code and dependencies. Runpod automatically manages worker lifecycle, starting them when needed and stopping them when idle to optimize resource usage.
 
 ### [Handler functions](/serverless/workers/handler-functions)
 
 The core of your Serverless application. These functions define how a worker processes incoming requests and returns results. They follow a simple pattern:
 
 ```Python
 import runpod  # Required
@@ -64,10 +64,10 @@
 
 When a user/client sends a request to your endpoint:
 
 1. If no workers are active, Runpod automatically starts one (cold start).
 2. The request is queued until a worker is available.
 3. A worker processes the request using your handler function.
 4. The result is returned to the user/client after they call `/status` (or automatically if you used `/runsync`).
 5. Workers remain active for a period to handle additional requests.
 6. Idle workers eventually shut down if no new requests arrive.
 
@@ -109,17 +109,17 @@
 
  A "cold start" refers to the time between when an endpoint with no running workers receives a request, and when a worker is fully "warmed up" and ready to handle the request. This generally involves starting the container, loading models into GPU memory, and initializing runtime environments. Larger models take longer to load into memory, increasing cold start time, and request response time by extension. 
 
 Minimizing cold start times is key to creating a responsive and cost-effective endpoint. You can reduce cold starts by using [cached models](/serverless/endpoints/model-caching), enabling [FlashBoot](/serverless/endpoints/endpoint-configurations#flashboot), setting [active worker counts](/serverless/endpoints/endpoint-configurations#active-min-workers) above zero.
 
 ### [Load balancing endpoints](/serverless/load-balancing/overview)
 
 These endpoints route incoming traffic directly to available workers, distributing requests across the worker pool. Unlike <QueueBasedEndpointsTooltip />, they provide no queuing mechanism for request backlog.
 
 When using load balancing endpoints, you can define your own custom API endpoints without a handler function, using any HTTP framework of your choice (like FastAPI or Flask).
 
 ### Fitness checks and preflight checks
 
-Validate your worker's environment at startup before it takes traffic. Fitness checks, also known as preflight checks, run registered checks in order before a worker begins processing jobs, catching issues like missing GPUs, unloaded models, or bad configuration before any request reaches your worker.
+Validate your worker's environment at startup before it takes traffic. Fitness checks (also known as preflight checks) run registered checks in order before a worker begins processing jobs. This catches issues like missing GPUs, unloaded models, or bad configuration before any request reaches your worker.
 
 [Learn more about fitness checks and preflight checks](/serverless/development/fitness-checks)
 
@@ -130,8 +130,8 @@
 1. [Write a handler function](/serverless/workers/handler-functions) to process API requests.
 2. [Test it locally](/serverless/development/local-testing) using the Runpod SDK.
 3. [Create a Dockerfile](/serverless/workers/create-dockerfile) to package the handler function and all its dependencies.
 4. [Build and push](/serverless/workers/deploy) the worker image to Docker Hub (or another container registry).
     - ... or [deploy directly from a GitHub repository](/serverless/workers/github-integration).
 5. Deploy the worker image to a [Serverless endpoint](/serverless/endpoints/overview).
 6. [Monitor logs](/serverless/development/logs), debug running workers [with SSH](/serverless/development/ssh-into-workers).
 7. Adjust your [endpoint settings](/serverless/endpoints/endpoint-configurations) to [optimize performance and cost](/serverless/development/optimization).