The CI/CD builds are always done in the us-east-ohio region, but they may be deployed elsewhere. You can configure it in the Vercel portal.

i can't agree with your "us-east-ohio" for build... (note sfo1 it is the same place as serverless is set for)

Oh then my functions are deploying to the wrong place as well 😡

I think the static part is cached in CDN which is distributed around the globe, while the dynamic part (which are serverless functions) follows the serverless function config

I am planning to contact them because that is contrary to their sales sheets and documentation

Changing your Serverless Function region
All Vercel accounts can change the default region of their Serverless Functions. Learn how to change the region in our documentation.

https://vercel.com/guides/choosing-deployment-regions

They mention static ips and multi-region function deployments for enterprise, but that is not what we are asking for. I will let you know if I do any better! All of my data is in us-west-2 !!!

I'm confused what the issue is... My build is the same as function location, is your different?

My build is ohio and my function location is supposed to be portland. If what you say is true, my functions are in the wrong place

I had assumed they just did builds in some default and pushed them to other regions

But yeah... idk i would need to test it now

I'll check my other ones and see if they are randomly assigned

It's follows the function location for me (even with project in Washington)

There is a chance they don't have a build there, so it has do to the closest one (idk USA geographicy)

@risky I think you are right. I will have to try to find another option for Nextjs project deployment. Enterprise plan is tooo expensive to use it for my purpose.

it is not random, it is just always saying the build is in Ohio

after a bit more investigation, I have concluded that my build and SSR take place in the clevland (us-east-2) AWS region. Using a route.ts like this:

export async function GET(request: NextRequest) {

  const message = await fetch("https://checkip.amazonaws.com/");
  let comment = await message.text();

  return new NextResponse(`${comment} ${process.env.AWS_REGION}`, {
    status: 200,
    headers: { "Content-Type": "text/plain" },
  });  
}

so, the thing it says at the top of logs isn't accurate?

When the page was output as "static" (ie. all data fetched at build) the IP was in this range, and the region variable was not set. This matches the build log message Running build in Cleveland, USA (East) – cle1 (FYI: cle1 is Vercel-talk for us-east-2)

    {
      "ip_prefix": "18.191.0.0/16",
      "region": "us-east-2",
      "service": "EC2",
      "network_border_group": "us-east-2"
    },

This is unfortunate, because at build time significant amounts of data might be fetched from a database which might be in a different region. Yuck.

and the issue of OP where it has to be in Europe 😭

On the plus side, by forcing the build to output a lambda instead of a static by export const dynamic = "force-dynamic"; I was able to find that the Lambda was in fact deployed to us-west-2 because the environment variable was set!

I mean, it matches my original thought that the lambdas actually were pushed to the right place

phew, they are aren't wrong with docs, just for built it is a little weird

but yeah, if Vercel is saying being GDPR data residency compliant requires anything "enterprise", that is kind of a joke

well ig to use vercel, you need to somehow build youself (in eu) and deploy to vercel without it needing to do any building

but npx vercel --production still uses their building system, so idk how to build by self - and if its worth using with the trickery

yeah idk, you can also argue that the database establishes residence, not where the front end is built

just as long as you aren't statically building in customer info

it is a little fuzzy though, I certainly would just host next somewhere else

https://vercel.com/docs/security#gdpr - so helpful...

netlify, cloudflare, even next start bascially anywhere

vercel build and vercel deploy --prebuilt

(but they don't have the same degree of pnp functions as vercek includes by default)

ahh that could be an option then 🙂 - i wasn't sure if there was a prebuilt option

You could still do CI/CD in GitHub actions pretty easily too, but the question begged is... why?

does Vercel not care about companies doing business in the EU?

and there isn't any downsides of this other than no vercel build cache?

yes, quota limits

you can cache locally as well

so its a viable option, while unfortunate

vercel build && vercel deploy --prebuilt is a popular way for people who can't use the git integration for reasons

the vercel deploy command allows orders of magnitde less deploys under 'fair use'

unless they walked that back

really? didn't know about this

in fact, i don't know of any limit in terms of the number of builds on vercel

it was a source of ENORMOUS contention a few years ago

[we process and use the build output from Vercel](https://github.com/cloudflare/next-on-pages/pull/289#issuecomment-1570953757)

cloudflare/next-on-pages uses vercel build think...

it was back when i never knew vercel existed so idk about this enormous thing then. but vercel CLI itself doesn't have any separate pricing model as far as i know of. you are limited to 100/3000 deployment per day (hobby/pro plan), regardless of whether you use CLI or native git integration. back when i didn't have vercel pro using the CLI was how i deployed my monorepo (> 3 projects) to vercel, it worked completely fine

it is much less austere than it use to be, but still quite less than 42000....

ok good to know, i didn't know about this. that said are you going to reach 2000 deployments in 7 days? if you had that many developers and projects to be able to reach 2000 deployments you might as well just buy enterprise or hire a devops team to ditch vercel entirely and self-build self-deploy

Haha, at one time I think it was like 200? They openly said it was to "encourage use of the git integration"

vercel is super awesome to use, but when they are frustrating about something...

oh... that was bad indeed

200 then it was a real limit to be concerned about

yeah, it was definitely something that could actually happen

i thought built time was the only limit...

same too, but that limit table in the docs is super hidden

they should just add one row to the pricing page saying 2000 2000 Custom

ahh ok 100 per day is decent

they are annoying because you can't just throw money at a lot of them

it is a little "enterprise cliff"

It actually shows the function region under the build in Deployment Details -> Deployment Summary -> Functions

waaaaay on the right

lol i didn't realize what its purpose was...

I actually try to answer questions here to learn stuff

same, now i know about this thing 🙂