An Indian AI team with a product launch this year cannot plan around a data centre expected in 2028. CoreWeave's new India announcement is worth tracking, but it belongs in a future-options column, not today's deployment schedule. The distinction matters before anyone promises capacity to a customer. On 6 October 2026, CoreWeave announced a planned 240 MW deployment with AdaniConneX at Taloja in Navi Mumbai, across three 80 MW buildings. The plan includes NVIDIA Vera Rubin systems, liquid cooling and a local presence. The first phase is expected in mid-2028. An option for additional capacity is not a confirmed second deployment, and the release does not provide India customer pricing.
Announced capacity is not bookable compute
For an Indian AI team, the practical question is not how many megawatts appear in a press release. It is what can be contracted, measured, and relied on for a production date. Those are different things, and the gap between them is where planning goes wrong.
Announced capacity is a statement of intent about buildings, power, and hardware. Bookable compute is a signed agreement with a delivery date, a price, a service level, and a remedy if the provider misses. The CoreWeave India announcement sits firmly in the first category. The official CoreWeave announcement sets out the Taloja plan and the mid-2028 first phase, and it is the right document to cite internally. It is not a quotation, a reservation, or a guarantee.
A useful discipline is to keep two separate columns in any internal note: what has been announced, and what has been contracted. Mixing them creates false confidence in board decks and engineering roadmaps.
What the 2028 timeline means for planning
Mid-2028 is a planning horizon for the announced first phase, not a confirmed start date for your own workload. Over that period, your model, usage pattern and budget may change. Keep the commercial decision open until you can compare an actual service offer against your requirements.
Consider a hypothetical Indian fintech building a document-review assistant. If the team assumes Navi Mumbai capacity in mid-2028 and designs its data pipeline around that assumption, it takes on schedule risk it does not control. A safer approach is to design for portability now and treat the new campus as an option to exercise later, once commercial terms exist.
The later phases and the unconfirmed additional 240 MW option should be treated as upside, not baseline. Planning against unconfirmed capacity is a common source of missed commitments.
A procurement worksheet for Indian AI teams
The worksheet below is a method, not a recommendation of any vendor. It is designed to be filled in before any commitment, and it works whether the provider is a new India campus or an existing region.
| Item | Question to answer | Evidence to collect |
|---|---|---|
| Workload | Training, fine-tuning, or inference? What latency is acceptable? | Internal benchmark on your own data |
| GPU-hours | How many hours per month at peak and at baseline? | Usage logs from current environment |
| Egress | How much data leaves the region, and at what rate? | Contract egress schedule |
| Support | What response time is promised, and in which time zone? | Written service level terms |
| Portability | How hard is it to move this workload elsewhere? | Documented migration test |
| Fallback | What runs the workload if the new capacity slips? | Named available-now provider |
Two rows deserve emphasis. Portability is the row teams skip, and it is the one that protects them. Fallback is the row that keeps a launch date intact when a first phase moves.
Cost controls belong before the commitment
New capacity often arrives with new pricing structures, and pricing structures are where budgets break. The habits that protect a team are the same ones that protect it on any cloud: budgets with alerts, owner tags on every service, environment rules that shut down idle test resources, and retention limits on logs and storage.
Indian teams preparing for AI experiments and product launches can start with the practical checklist in this cloud-cost controls before scaling guide. The value is not the checklist itself but the review cadence. A quarterly comparison of cloud spend against product usage and revenue signals catches drift before it becomes a budget conversation.
Apply the same discipline to a future India region. Decide in advance which workloads may move, which must stay, and who signs off on the move.
Questions to ask before signing anything
- Is the capacity contracted with a delivery date, or announced with a target?
- What is the committed price, and what triggers a change?
- What happens if the first phase is delayed?
- Can the workload be migrated out, and at what cost?
- Which data residency commitments are contractual rather than descriptive?
- Who inside your team owns the fallback plan?
If a provider cannot answer these in writing, the correct planning assumption is that the capacity is not yet available for your workload.
How to read this announcement responsibly
Read the announcement as a direction of travel, not a ready-to-order service. The campus plan may eventually widen procurement choices for Indian teams. The release alone cannot establish availability, customer prices, support terms or performance on your application.
For an Indian AI team, the sensible posture is interested but uncommitted. Track the announcement, keep your architecture portable, keep your cost controls current, and revisit when commercial terms exist. Do not build a launch date on unconfirmed capacity, and do not treat an option for additional megawatts as a second deployment.
Conclusion
Keep the planned campus on your procurement watchlist without making it a dependency for a current launch. Establish a working baseline, a portable deployment and a funded fallback first. Revisit the new option when commercial terms and usable capacity can be verified.
Image: Brett Sayles via Pexels. Illustrative data-centre photograph, not the planned Taloja campus.
