Nscale is acquiring Anyscale for approximately $1.65 billion, a deal the two companies announced on July 30, 2026 (TechCrunch). If you run production workloads on Ray or Anyscale's managed platform, the news itself isn't the part that should change your Monday. The part that should is a quieter fact buried in the announcement: only Anyscale's hosted control plane is changing owners. Ray, the open-source framework underneath it, was donated to the PyTorch Foundation in October 2025 and isn't for sale in this deal at all (Beri).
That distinction is worth sitting with before you read the rest of this. The framework you depend on and the commercial product you pay for are two different things with two different risk profiles now, and only one of them just changed hands.
Nscale Acquires Anyscale: What Actually Changes for Ray Users
Nscale is buying a company, not a codebase. Anyscale's roughly 200 engineers, its enterprise sales motion, and its hosted platform move to a new parent. Ray's governance doesn't.
The Deal in Plain Terms: $1.65B, a Mid-2026 Close, and a 200-Person Team
Neither company disclosed the price officially, but it's widely reported at $1.65 billion (TechCrunch), a step up from Anyscale's $1.38 billion valuation in its 2022 Series C. Anyscale had been growing fast heading into the deal, reporting 70% sequential revenue growth in its most recent quarter before the announcement (TechCrunch). Anyscale's full team of approximately 200 people, spread across the US, Europe, and India, joins Nscale as part of the deal (Anyscale press release). The transaction is expected to close in the second half of 2026, subject to standard closing conditions and regulatory approval (Anyscale press release).
Nscale isn't a small buyer. It closed a $2 billion Series C in March 2026 at a $14.6 billion valuation (TechCrunch), and it's carrying a debt-heavy financing structure typical of a company building data centers at speed: a $790 million Norwegian facility, a $1.4 billion delayed-draw term loan, and a $900 million revolving credit facility that closed in July 2026, alongside a $2.5 billion UK data center commitment, according to one detailed independent analysis of the deal (Beri). That last figure is one outlet's tally rather than a number either company has disclosed itself, worth flagging since it's the kind of detail that's easy to overstate as official.
Why Nscale Wants Anyscale: The Full-Stack AI Hyperscaler Pitch
The stated logic is straightforward: own more of the stack a customer touches, not just the GPUs underneath it. "Anyscale extends that offering with managed services that AI teams use to scale any workload, completing a truly vertically integrated AI cloud platform," said Josh Payne, CEO and Founder of Nscale (Anyscale press release). Anyscale's CEO framed it the same way from the other side: "By combining Anyscale's platform, built on Ray, the open standard for scaling AI, with Nscale's data centres, compute and AI cloud services, we're creating the first full-stack AI hyperscaler," said Keerti Melkote, CEO of Anyscale (Anyscale press release).
Nscale is joining the PyTorch Foundation, reportedly as a platinum member, which puts real financial backing behind Ray's neutral governance instead of pulling it back toward one commercial owner (Beri). That's a meaningfully different move than simply buying the company and inheriting the community's trust for free.
What Stays the Same on Day One
Anyscale keeps its own brand and its existing customer relationships. Customers keep the freedom to choose their own infrastructure, and gain the option, not the requirement, to run Anyscale's software on Nscale's platform over time (Anyscale press release). Nothing about your current cluster, contract, or console changes the day the deal closes. What changes is who's on the other end of that contract going forward, and that's the part worth planning around rather than reacting to.
Is Ray Still Open Source After the Acquisition?
Yes, and this isn't a soft yes with an asterisk. Ray was donated to the PyTorch Foundation in October 2025, nine months before Nscale's deal was even announced, and it remains open source and community-governed under that foundation regardless of who owns Anyscale (Beri). Ray already runs on AWS, Google Cloud, Azure, or any GPU cluster you point it at today, and nothing in this deal changes that.
Ray's 2025 Donation to the PyTorch Foundation
The donation is why this deal reads differently than a typical "startup gets acquired, community holds its breath" story. Ray's license, its governance body, and its roadmap process all sit with the PyTorch Foundation, not with Anyscale's corporate parent, whoever that parent happens to be. Nick Patience, VP and Practice Lead for AI Platforms at The Futurum Group, put the limits of Nscale's leverage plainly: "the acquisition, on its own, does not hand Nscale a defensible moat." Ray "is open source, was donated to the PyTorch Foundation in 2025, and runs perfectly well on AWS, Google Cloud, Azure, or any GPU cluster a customer chooses" (Futurum Group).
The Real Risk Isn't the Framework, It's the Hosted Control Plane
Where the actual vendor risk lives is more specific than "is Ray open source." Anyscale's architecture splits cleanly into a vendor-hosted control plane, the console, scheduling APIs, job management, and cluster lifecycle tooling, and a customer-owned data plane, your Kubernetes cluster, your Ray instances, your storage. Only the control plane changes hands in this deal. One analysis of the acquisition put the vendor-risk framing bluntly: "Open source protects the code. It does not protect the service. The framework you can fork; the console you cannot" (Beri). The same piece makes the point that a change of ownership doesn't require anything dramatic to happen for a customer to end up with fewer options than they started with: "When a company that sells compute buys the software that decides where your compute runs, nothing bad has to happen for you to end up with fewer options than you had."
There's a reasonably close precedent for how this can play out fine. CoreWeave acquired Weights & Biases in March 2025 with similar continuity commitments, and more than a year later, W&B still runs on infrastructure from CoreWeave's competitors without any forced migration (Beri). That's the encouraging read. The more measured one is that pricing and roadmap drift over a three-year horizon is a real risk that a one-year track record doesn't rule out.
Managed Anyscale vs Running Open-Source Ray Yourself (Anyscale Alternatives)
The acquisition doesn't force anyone off Anyscale. But it's a reasonable prompt to actually run the comparison you probably haven't run since you first signed up: what does the managed platform buy you today, and what does it cost to run the same open-source stack yourself. We wrote the full version of this comparison, with pricing across ten providers and step-by-step migration instructions, in our Anyscale alternatives guide. This section is the short version.
What Managed Anyscale Still Gives You
Anyscale's value has never really been Ray access, since Ray itself is free. It's the operational layer on top: automated cluster lifecycle management (auto-scaling, node replacement, head-node failover), a hosted dashboard with job history, pre-built environment images for common ML frameworks, and a managed Ray Serve deployment path for production inference. For teams that don't want to own that operational surface, that's a legitimate reason to stay, acquisition or not.
What Self-Hosted Ray and KubeRay Give Up, and What They Don't
Running Ray yourself means you own cluster lifecycle management, environment builds, and dashboard access instead of getting them managed for you. What it doesn't cost you is anything on the Ray API surface itself: ray.init(), job submission, actors, and Ray Serve all behave identically whether you're on Anyscale or on a self-managed cluster, because it's the same open-source framework either way. KubeRay closes a meaningful chunk of the operational gap for teams on Kubernetes. KubeRay v1.5 natively integrates NVIDIA's open-source KAI Scheduler, adding gang scheduling for coordinated multi-node startup, GPU-aware autoscaling, and workload prioritization so high-priority inference jobs can preempt lower-priority training runs (Anyscale engineering blog). That's real infrastructure maturity that didn't exist a couple of years ago, and it narrows the gap between "managed" and "self-hosted" more than most teams evaluating Anyscale alternatives assume.
For teams already running or evaluating Ray Serve specifically, our Ray Serve on GPU cloud production guide covers the full deployment path, from single-node setup through multi-node autoscaling.
The Cost and Lock-In Math After a Change of Ownership
Anyscale's managed Ray clusters typically run 1.5-2x over bare-metal GPU rates for equivalent hardware, based on our own pricing comparison across ten Ray providers. That premium was worth paying for a lot of teams when Anyscale was an independent company with a clear, singular incentive to keep Ray users happy. It's a fair question to re-ask now that the platform sits inside a GPU infrastructure company that also sells compute in competition with whatever cloud you're currently running on. Live Spheron on-demand pricing has H100 SXM5 at $5.07/hr and H100 PCIe at $2.64/hr per GPU as of this post (Spheron GPU pricing API); run that through Anyscale's typical markup and the gap between managed and self-hosted on the same hardware is easy money left on the table if you weren't already factoring it in. For a broader cross-provider view of where that markup sits against the rest of the market, see our GPU cloud pricing comparison.
Pricing fluctuates based on GPU availability. The prices above are based on 15 Aug 2026 and may have changed. Check current GPU pricing → for live rates.
How to Move a Ray Cluster to Rented GPUs Without Anyscale
You don't need a crisis to make this move, and you shouldn't wait for one either. The practical case for testing a self-hosted path now is that it's a lot easier to run this exercise on your own timeline than under pressure six months into new ownership.
Audit Your Contract Before Close
Before the deal closes in the second half of 2026, pull your Anyscale contract and check three things: whether it has a change-of-control clause that lets either side exit or renegotiate on acquisition, whether your current pricing is locked for a fixed term or subject to renewal at Nscale's discretion, and what your data export rights actually say, specifically whether you can pull job history, environment configs, and cluster specs out in a usable format. None of this requires assuming bad faith. It's the same due diligence you'd run on any vendor whose ownership just changed.
Test KubeRay on Rented GPUs in a Non-Production Environment First
Don't migrate a production workload as your first test. Stand up a small KubeRay cluster on rented GPU instances, run a representative training or serving job through it, and compare behavior against your current Anyscale setup before you commit to anything. This is a low-cost way to find out whether the operational gap between managed and self-hosted is actually as large as you assume, or whether KubeRay's current maturity closes most of it for your specific workload.
Migration Steps, at a Glance
The mechanics, at a high level, look like this:
- Export your environment. Capture your pip dependencies, base Docker image, and Ray version from your current Anyscale cluster config.
- Provision GPU instances. Match the GPU type and count from your Anyscale cluster on a bare-metal GPU cloud, with a private network between nodes.
- Install Ray and the KubeRay operator. Match your existing Ray version exactly across all nodes to avoid cluster join failures.
- Apply a RayCluster manifest that mirrors your Anyscale cluster's head and worker node specs.
- Submit a test job and confirm
ray statusshows all workers registered before pointing production traffic at it.
Your training and serving scripts don't change in this process. Ray's client API and job submission commands are identical between Anyscale and self-hosted KubeRay, because it's the same underlying framework. For the full command-by-command version of this migration, including Helm setup and RayCluster YAML examples, our Anyscale alternatives guide walks through every step.
What This Signals for the Neocloud Market
This deal isn't a one-off. Futurum Group's analysis points to CoreWeave's own expansion into managed inference and fine-tuning, including its 2025 acquisition of Weights & Biases, as the closest precedent for what Nscale just did, with NVIDIA's investment in Nebius cited as a similar directional bet on owning more of the AI development lifecycle. The same analysis leaves it an open question, not a confirmed pattern, whether CoreWeave, Nebius, or Lambda go on to pursue their own software acquisitions to round out a full-stack AI cloud claim (Futurum Group). Firms that used to compete mostly on chip availability are now racing to control larger pieces of that lifecycle. As raw GPU supply becomes less of a differentiator, the software layer sitting on top of it is where these providers are trying to build the moat that GPUs alone don't give them anymore.
Patience's read on the underlying question is the one worth carrying forward: "once you have built or leased enough GPUs, what do you actually sell next?" (Futurum Group). For buyers, that question cuts both ways. A full-stack provider can genuinely simplify your infrastructure decisions. It also means more of your workload's fate sits with one company's roadmap and pricing decisions than it did when compute and orchestration software came from separate vendors. For a wider view of who else is playing this consolidation game and how, see our 2026 AI infrastructure companies landscape; for a head-to-head look at how one of Nscale's full-stack peers stacks up on price and flexibility, our Spheron vs Lambda Labs comparison is a useful second data point.
Ray isn't for sale, and it never was part of this deal. What's actually changing hands is a hosted console and the company that decides what happens to it next. Knowing you can run the same open-source stack yourself, on whatever GPU cloud you choose, is the hedge that makes the rest of this news a lot less urgent to react to.
If you're weighing a move off managed Ray, Spheron gives you bare-metal GPUs with KubeRay support and per-minute billing, no platform markup and no change-of-control clause to track.
Frequently Asked Questions
Yes. Ray was donated to the PyTorch Foundation in October 2025, before this deal was announced, and it stays under that foundation's neutral, community governance regardless of who owns Anyscale. Nscale has said it plans to join the PyTorch Foundation as a platinum member, which puts financial backing behind Ray's governance rather than pulling Ray back under one vendor. The acquisition changes who owns Anyscale's hosted commercial platform built on top of Ray. It does not change Ray's license or its governance.
On day one, close to nothing. Anyscale keeps operating under its own brand, its roughly 200-person team across the US, Europe, and India moves to Nscale, and existing customers keep their current contracts and infrastructure choices. The deal is expected to close in the second half of 2026, subject to regulatory approval. What changes is ownership of the corporate parent behind the hosted console, not the product a customer logs into that week.
Anyscale's architecture splits into a vendor-hosted control plane (the console, scheduling APIs, and cluster lifecycle management) and a customer-owned data plane (your Kubernetes cluster, your Ray instances, your storage). Only the control plane changes hands in this acquisition. That distinction matters because the actual vendor risk in a deal like this lives in the hosted layer you don't control, not in the open-source framework, which you can already run yourself without Anyscale at all.
At a high level: audit your Anyscale contract for change-of-control and data-export clauses before the deal closes, provision GPU instances on a bare-metal cloud, install the KubeRay operator via Helm on a Kubernetes cluster, and apply a RayCluster manifest that mirrors your Anyscale environment's head and worker node specs. Ray's client API and job submission commands are identical between Anyscale and self-hosted KubeRay, so your training and serving scripts don't need to change. Test the migration in a non-production environment first.





