Starting and Growing a Career in Web Design
0%
Starting and Growing a Career in Web Design
0%
Starting and Growing a Career in Web Design
0%

From VXLAN to Geneve: What Changed in Our New India Availability Zone

We moved from VXLAN to Geneve, hit 1 Gbps uploads, and rebuilt our India infrastructure to handle what's coming next.

Published

Feb 9, 2026

Category

Engineering

Author

Om Gupta

huddle_maarut
huddle_maarut

In December last year, we launched the India region for Huddle01 Cloud. Within a month, adoption outpaced every internal projection we had. What we'd planned as a measured rollout turned into one of our fastest-growing regions.

That growth validated the demand. It also made clear that the next version of our India infrastructure needed to be built for a fundamentally different scale.


What We Built

BOM2 is our new availability zone in Mumbai, keeping future scalability in mind. Here's what's under the hood.

  1. Geneve based client separation. The original India region used VXLANs for tenant isolation, one of the most common approaches in the industry. It works well, until you hit a certain density of tenants on shared infrastructure. Geneve (Generic Network Virtualsation Encapsulation) solves this at the protocol level. It's extensible, handles metadata more efficiently, and offloads packets without the bottlenecks that VXLAN introduces at scale. For customers, this translates directly into lower latency and more consistent performance.


  2. Dramatically faster speeds. The new networking stack supports sustained upload speeds up to 1 Gbps and download speeds up to ~5 Gbps, with bursts up to 25 Gbps. In the previous region, upload speeds degraded to as low as 50 Mbps. That ceiling is gone.


  3. Lower latency. Faster packet offloading means less time spent on network overhead and more time spent on your actual workloads.


  4. Built to scale. BOM2 is architected with the assumption that our user base will grow by an order of magnitude. The networking layer is designed to handle that growth without requiring further re-architecture.


Why We're Deprecating the Old Region

With India One live, the original India region will be deprecated.

This isn't a decision we made lightly. The original region served us and our customers well during its initial phase. But the architectural changes between the two are significant enough that maintaining both in parallel doesn't make sense. The improvements in Geneve based separation, upload throughput, and latency are only available on BOM2, and we want every customer in India to benefit from them.

Rather than force disruptive in-place upgrades on existing infrastructure, we chose to build the right thing from scratch and give customers a clean migration path.


Migration: What to Expect and How It Works

Every existing customer on the old India region has a two-month window to migrate their infrastructure to India One. The old region will remain fully operational during this period, so there is no immediate disruption to your services.

Here's a step-by-step breakdown of how the migration works.

Virtual Machines. The recommended approach is to provision a new VM in the BOM2 region and use rsync to transfer your data and configurations from the existing instance. Once you've validated the new setup, you can decommission the old one. The original VM in the old region will continue running throughout the migration window, so there's no rush and no forced downtime.

Security Groups. Security groups can be migrated to BOM2 directly from the dashboard. However, the virtual machines and other resources that reference those security groups will need to be created manually in the new region. We recommend migrating your security groups first, then provisioning your new VMs under them.

Other Resources. For any additional infrastructure (load balancers, Kubernetes clusters, etc.), the process follows the same pattern: provision the new resource in BOM2, validate it, then wind down the old one.

Why we're not auto-migrating. We evaluated running automated migration scripts on our end. The problem is that every customer's setup is different, different configurations, different dependencies, different tolerance for downtime. An automated migration that works for one team could break another. We'd rather give you full control over the process and the timing than risk unplanned downtime on your behalf.


We're Here to Help

Our engineering team is available throughout the entire two-month migration window. If you need help planning your migration, run into issues mid-move, or just want someone to walk through the process with you, we're on it.

You can reach us through the in-app chatbot for quick questions, or email us directly at engineering@huddle01.com for more involved support. We'll work with your team to make sure the transition is as smooth as possible.

Liked the article? Share it on socials.