Lucknow Origin: DNS, Latency, and a CDN in Front

Netbay has one datacenter: Lucknow DC01. Every VPS you buy lives there. That is not a limitation you paper over with imaginary regions; it is the origin you design for. Indian users in Delhi, Mumbai, Bengaluru, and Lucknow itself see single-digit to low tens of milliseconds. Users in Singapore, Frankfurt, or Virginia see a transcontinental RTT on every uncached request. DNS points at Lucknow. A CDN, if you add one, is a cache and a TLS edge in front of that origin. The origin does not move.

DNS that tells the truth

The apex or the www name should resolve to the VPS public IP. An A record is enough. If you have IPv6 on the instance, add AAAA. Do not CNAME the apex unless your DNS host supports that exception. Set a TTL you can live with during a cut: 300 seconds while you are migrating, 3600 once the IP is stable. The CDN, when present, becomes the name clients resolve; the origin hostname (origin.example.in) stays a quiet A record that only the CDN and you know.

# origin.example.in -> Lucknow VPS, low TTL during changes
# example.in        -> CDN anycast (when a CDN is in front)

dig +short A origin.example.in
dig +short AAAA origin.example.in
dig +short NS example.in
dig +ttl A example.in

# from the VPS itself, confirm what the world should hit
curl -fsS --max-time 5 https://ifconfig.io/ip

Keep the origin name on a certificate the CDN can verify. Pointing a CDN at an IP with a stale certificate is a weekend. Let's Encrypt on nginx at the origin remains required even with a CDN, because the CDN-to-origin hop should be HTTPS. HTTP-only origin is a shortcut that leaks cookies on that hop.

Measure latency before you add a CDN

A CDN helps cacheable GETs. It does not shrink the RTT of a POST to /login or a WebSocket. Measure origin RTT from where your users actually are, using the origin name, not a speed-test brand.

# from a laptop in another city, against the origin
curl -o /dev/null -sS -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n"   https://origin.example.in/healthz

# same request through the CDN name
curl -o /dev/null -sS -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n"   https://example.in/static/app.js

Expect the healthz call to show a TCP and TLS cost that tracks geography. Expect the cached JS file, after the first miss, to show a tiny TTFB from a nearby CDN edge. If the JS file is always a miss, your Cache-Control is wrong or you are bypassing cache with cookies. Fix headers before you buy a larger plan to "make Lucknow faster." Lucknow is already as close as the origin will get.

Cache what is public, bypass what is private

nginx at the origin must send headers the CDN can obey. Static assets under /static/ get long max-age and an immutable flag when the filename is hashed. HTML that includes a logged-in user gets private, no-store. API GET that depends on a cookie should not be cached at the edge. API GET that is public (a marketing page, a pricing JSON) can be cached for a short TTL.

# origin nginx — headers the CDN will honor
location /static/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    try_files $uri =404;
}
location /healthz {
    add_header Cache-Control "no-store";
    proxy_pass http://127.0.0.1:3000/healthz;
}
location / {
    add_header Cache-Control "private, no-store";
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Restrict the origin firewall so only the CDN anycast ranges and your admin IP can hit 443, once you are sure you will not lock yourself out. Until then, keep 443 public and rely on TLS plus application auth. L3/L4 DDoS filtering on the VPS still matters for origin-direct attacks; a CDN reduces how often those packets arrive, it does not replace origin hygiene.

A CDN is not a second Netbay region and it is not object storage. It is a cache in front of a Lucknow origin. If your product is India-first, you may not need it on day one: a 4 GB Ubuntu VPS on Intel Xeon Platinum with High-Speed SSD already serves Delhi and Mumbai well. Add the CDN when you have measured that static weight or overseas TTFB is the thing users feel, and keep every write path pointed at DC01.

Deploy the origin on Netbay in Lucknow in under 60 seconds, publish an A record, then add a CDN only after the curl timings say you need one — netbayhosts.in.