Choosing a Vercel Function Region: iad1, sin1, and the CDN for Indonesian Visitors

Your new Vercel project is "in Washington"

Open the settings of a freshly created Vercel project and you will find the function region set to iad1, Washington, D.C., USA. From Indonesia, most people's first reflex is the same: "why is my server that far away?" The official answer is simple — it is the default for all new projects, chosen because many external data sources (databases, third-party APIs) live in the US East Coast. This behavior is stated plainly in the function region configuration docs.

But the conclusion "far server = slow site" jumps the gun. This article breaks down which parts of Vercel's architecture actually feel that distance, which don't, and how I picked the region for this very blog — including how to change it from the dashboard or vercel.json.

Near vs far: the CDN first, functions later

Vercel is not one server in one city. The infrastructure has two layers, explained on the global network and regions page: over 126 CDN Points of Presence (PoPs) spread around the world, and 20 compute regions where your code actually executes. A reader's request enters through the nearest PoP — for Indonesia, usually Singapore — over a private network with millisecond latency.

The consequence, for a content site like a Next.js blog with ISR:

• Served from Singapore (near): prerendered static pages, cached ISR pages, images, CSS, JS. This is the majority of traffic — and it does not care where your function region is.
• Processed in the function region (potentially far): full Server-Side Rendering, ISR revalidation on stale cache, API routes, and every fetch to a data source from inside a server component.

So before panicking over iad1, check first: what share of your pages genuinely needs server execution per request? For a blog, the answer is small.

The region rule: get close to your data, not your readers

This is the most misunderstood part. Vercel's documentation is explicit that functions should execute "in the same region as your database, or as close to it as possible" — not as close as possible to your readers. The reason: readers are already served by the nearest PoP, while a function far from its data pays a cross-continent round trip on every fetch.

This blog's real case: frontend on Vercel, API on a VPS at 165.22.105.83. An IP lookup shows that VPS is a DigitalOcean box in Singapore. The right function region is therefore sin1 (ap-southeast-1, Singapore) — every SSR pass and ISR revalidation pulls data from an API milliseconds away, instead of crossing the Pacific to Washington and back. If instead your database lives in AWS us-east-1 or your third-party services are US-based, moving the function to Asia would make latency worse.

Three ways to change the region

Vercel offers three equivalent configuration paths:

1. Dashboard — Project Settings → Functions → open the Function Regions accordion, pick a region, save. The change applies to subsequent deployments.
2. vercel.json — add a regions key at the project root:

{
  "regions": ["sin1"]
}

I prefer the file route for this blog: the configuration is version-controlled in git, deploys through the same branch flow as the code, and is readable by anyone opening the repo — instead of hiding in dashboard settings. For a monorepo, place it at the root that serves as your Vercel project's Root Directory.

3. CLI — vercel --regions sin1 at deploy time.

Plan limits: Hobby gets one region

How many regions you may use depends on your plan, per the limits table in the region documentation:

Plan	Function regions
Hobby	1 region
Pro	5 regions
Enterprise	All (20)

For personal use, a single region is not a real limitation — it forces the correct decision: pick the one region closest to your data. Cross-region redundancy is automatic only on Enterprise via functionFailoverRegions; within a single region, Vercel Functions already have availability-zone redundancy by default. One interesting exception: Routing Middleware is still deployed to all regions on every plan, regardless of your function region settings.

The Asia region map

Of Vercel's 20 compute regions, the ones relevant to readers and infrastructure in Southeast Asia:

Code	Location
sin1	Singapore (ap-southeast-1)
hkg1	Hong Kong (ap-east-1)
icn1	Seoul (ap-northeast-2)
bom1	Mumbai (ap-south-1)
hnd1 / kix1	Tokyo / Osaka

For Indonesia, sin1 is almost always the right answer: direct submarine cable routes to Singapore, and most VPS/cloud providers Indonesian developers use have a presence there.

Checklist before switching regions

• Check your architecture first: CDN-cached pages don't care about region — switching only fixes the SSR/fetch path.
• Locate your data source (IP lookup for the VPS, or the database's region) — not your readers' location.
• Set the region via vercel.json so it is version-controlled: {"regions": ["sin1"]}.
• After deploying, confirm in the dashboard (Settings → Functions) that the active region matches.
• Remember the plan limit: Hobby is one region; requesting more than allowed fails the build.

A function region is a decision about the distance between your functions and your data. For readers, distance is already solved by 126 CDN PoPs — including the one in Singapore, a few milliseconds from Jakarta.