Which Indian city should your server actually be in?

Search for VPS hosting in almost any Indian city and you will find providers claiming a presence there. Kochi, Ranchi, Guwahati, Coimbatore — all covered, apparently. Most of the time this is a landing page with the city name substituted into a template, served from a machine several states away.

That is not automatically dishonest. Serving Kochi from Mumbai is a perfectly reasonable engineering decision. Implying there is a facility in Kochi is the dishonest part, and it matters because it is the difference between a buyer who can plan and a buyer who cannot.

What intercity latency actually costs you

Within India, the realistic range between well-connected metros is roughly 5 to 50 milliseconds of round trip. Pune to Mumbai is nearly free. Kolkata to Mumbai is the expensive end of the domestic map.

Now put that in context. A typical page request on a database-backed application spends somewhere between 80 and 400 milliseconds inside the application: routing, queries, template rendering, external API calls. Against that, 30 milliseconds of transit is noise. You will not see it, and neither will your users.

Where it stops being noise:

• Chatty protocols. If a page makes forty sequential round trips — an unoptimised RDP session, a poorly batched API, a frontend making waterfall requests — you pay the latency forty times. That is when 30 ms becomes 1.2 seconds.
• Real-time loops. A game server tick, a voice call, a trading path. Here the round trip is the product.
• Interactive desktops. RDP and VNC feel laggy well before a web page does. If your accountants live in a remote desktop all day, put the server near them.

For everything else — websites, APIs, ERP systems, business software, bots, automation — the node city is a second-order decision. Spend the attention on the application instead.

The three questions that actually decide it

Where are your users, not where are you?

This is the one people get backwards. If you run the business from Indore but your customers are in Mumbai and Pune, put the server in Mumbai. Your own SSH session being 20 ms slower costs you nothing.

Do you need to say where the data is?

Increasingly, Indian buyers do — for a client contract, a tender requirement, or an internal policy. “Somewhere in India” is a weaker answer than “Noida, in this facility, on this network.” If you will be asked, choose a provider that will name it.

Do you need a second location?

If the answer to “what happens if this node has a bad day” is “we are down,” then a second node matters more than which city the first one is in. Production in one city and a warm standby in another is a real failure boundary. Two machines in the same rack is not.

How to verify any provider's location claim

You do not have to take anyone's word for this, including ours.

1. Ask for a test IP address on the exact plan and node you are considering. A provider who will not give you one has told you something.
2. Look up the origin autonomous system for that IP on a public BGP tool. Confirm it matches the network the provider says carries the service.
3. Run traceroutes to it from the ISPs your users actually use — Jio, Airtel, BSNL, a local broadband provider — not just from your office line.
4. Look at where the path enters the provider's network. A route that reaches Mumbai and stops is telling you where the machine is, regardless of what the landing page says.
5. Run it at 10am and again at 9pm. Evening congestion is where Indian routing gets interesting.

Where we stand

VPSWala runs three nodes: Mumbai, Noida and Jaipur. We publish city pages for twelve cities, and the nine that are not node cities say so in the first paragraph, name the node that serves them, and give a typical round-trip range you can go and verify.

That is less exciting than claiming twenty-six cities. It is also the version you can plan against.