
Flash, now the Nix way: run the Flash CLI straight from GitHub
Flash now ships a first-class Nix flake. Run the CLI with nix run github:runpod/flash, get a pinned dev shell, and send GPU work to Runpod Serverless.
Blog
Less of the work around your compute is yours to maintain this quarter, from one API for the whole platform to one account for your whole company. Plus the deadlines for v1 and GraphQL users.

Most of what we shipped since July takes work off you as you scale past your first endpoint: batch inference replaces a client-side queue, storage no longer pins your workload to one datacenter, training clusters grow without a rebuild and one organization covers a whole company's compute spend. Scaling up no longer means rebuilding how you run it.
Every release below covers what shipped and the situation it's built for, so go straight to the ones that fit your workload.
What shipped: Batch Jobs are in public beta. You create a batch against a Serverless endpoint, add up to 5,000 requests, finalize it to start processing and poll per-request counts for progress. During the beta, each endpoint runs up to 10 active batches with 50,000 requests queued; contact support for higher limits, up to 1 million requests a day.
Use it when: you’re scoring a dataset or running other offline inference overnight and you’re managing thousands of requests to an endpoint in your own code. Now you submit them as a batch and poll one status instead of maintaining a client-side queue.
What shipped: Worker affinity is now available for Serverless load balancer endpoints. Send back the X-Runpod-Worker-Id response header and choose a mode: soft prefers the same worker, strict waits for it, and strict-resume wakes it if it scaled down.
Use it when: your inference server keeps a KV cache in GPU memory, and a follow-up request that lands on a different worker has to reprocess the whole prompt.
What shipped: The Serverless endpoint creation flow now offers six paths: Hello World, Hugging Face LLM, Docker, GitHub, Flash and Hub, which replaces Ready-to-Deploy Repos.
Use it when: you’re creating an endpoint and want to start from the source you already have, whether that’s a Docker image, a GitHub repo, a Hugging Face model or a Hub listing.
What shipped: Nano Banana 2 Edit replaces the Nano Banana Edit public endpoint, which retired September 28 after Google discontinued the model.
Use it when: your code still calls Nano Banana Edit. Those requests no longer run, so point them at Nano Banana 2 Edit.
What shipped: Global Volumes are in public beta and open to everyone. Now you can create a volume without choosing a datacenter, then attach it when you deploy a Pod or Serverless endpoint.
Use it when: your files sit on a network volume in one datacenter, but the GPUs you need are elsewhere. Global Volumes work best for files you read often and write rarely, like model weights, LoRAs, tokenizers and configs, since they're backed by object storage. Keep low-latency jobs, concurrent writers and anything that needs full POSIX semantics on high-performance network volumes. Storage and file system requests are billed separately, and one file operation can issue several requests, so test at small scale before pointing a busy workload at one. See how billing works, when to choose a Global Volume, or watch the two-minute walkthrough.
What shipped: Private AWS ECR support is now available for Pods and Serverless endpoints. Connect a repository once with cross-account IAM delegation, and Runpod handles the token exchange and rotation.
Use it when: your image lives in a private ECR repository. ECR tokens expire every 12 hours, so the options used to be mirroring the image to another registry, making it public or refreshing credentials twice a day. Now you grant pull-only access with a repository policy and deploy, and the image stays in the registry your security team already approved. Reference the image by tag, because untagged URIs don’t pull. For Serverless endpoints created through REST API v2, the template’s ECR delegation isn't applied, so create those endpoints in the console for now.
What shipped: Cluster Expansion is now available. You add Pods to a running cluster, and they join its private network and match its GPU type, Pod template and network volume, with NCCL variables and hostname resolution set for you. You see the new GPU count, VRAM and hourly cost before you confirm.
Use it when: a training run needs more compute than you planned for, which used to mean rebuilding the cluster, reconnecting storage and moving the workload. Clusters on reserved or contracted hardware can't self-serve expansion yet, so ask your account manager to add capacity. How many Pods you can add depends on available inventory. Most frameworks read topology at startup, so plan to resubmit your job with the new world size.
What shipped: REST API v2 is now available. It covers Pods, Serverless, Clusters, templates, network volumes, registry credentials, the hardware catalog and billing under one base URL, with a published OpenAPI spec. It also adds Pod runtime metrics without SSH and worker-level visibility into Serverless health checks.
Use it when: you script anything against Runpod. If those scripts call REST API v1, migrate them before November 15, when v1 will stop serving requests. v2 isn't a drop-in replacement: it uses a new base URL, new paths and new response shapes. After the cutoff, calls to v1 return a response pointing to the v2 path and the migration guide, which maps both v1 and GraphQL calls to v2. GraphQL rate limits begin October 27, and GraphQL stops serving requests in January 2027. Running Pods and endpoints aren't affected, only the scripts and integrations that call v1 or GraphQL. To avoid service disruption, generate a typed client from the OpenAPI spec, or hand the spec to a coding agent with Runpod's agent skills and MCP server.
What shipped: Runpod Enterprise added Organizations on September 24, on top of the reserved capacity, contractual SLAs and dedicated support enterprise customers already get under one agreement Organizations are company-owned accounts that centralize Pods, endpoints and volumes under a single payer, with SSO/SAML for your identity provider, built-in roles, resource tagging, group management, audit logs and invoices grouped by cost center. Runpod also earned ISO/IEC 27001:2022 certification, announced alongside the launch, which joins its SOC 2 Type II report.
Use it when: a production workload can't wait on capacity, or your growing team needs to manage access and spend together. Move personal accounts into one organization, map access to your identity provider's groups and tag spend by cost center so finance gets one invoice with costs already grouped by team. SSO setup is done with Runpod support.
To see each release as it ships, follow the Runpod release notes.
Still on REST API v1 or GraphQL? Start with the migration guide.
Rolling Runpod out to a team? Learn what Runpod Enterprise adds.
First-time user? Deploy your first endpoint.
Blog Posts