Changes coming to Netlify site URLs

OOps confused march and april. Sorry :smiley:

1 Like

Why is not already added to the Public Suffix List? It’s important to add it as early as possible so browsers can have an updated list:

Not sure, I’ll ask our team! Thanks for mentioning it!

1 Like

I might have missed it, but how does this affect lambda functions, is this something that should be changed manually?

It would depend how you use the function as to whether it will be affected. We proxy internally from the /.netlify/functions/functionname path to AWS; that won’t change. So:

  • if you call your function as /.netlify/functions/functionanname with no hostname (or even if you proxy from /functionname to that path without a hostname - /functionname /.netlify/functions/functionname 200) - no effects/changes not needed.
  • if you call your function directly (something like a href=, we’ll simply 301 redirect that to, and run it.

The main thing you’d need to change is if you proxy to us and DO use a NETLIFY hostname - e.g. a redirect like this from “yoursite” to “othersite”:

/functionname 200

  • this wouldn’t work as it does today; we’d return the 301 redirect and depending on how you call it, the browser would either sit there witha 301 and no content, or be accessing the function directly from its hostname which is probably not ideal if you were using proxying to hide the details of your site layout (“ is REALLY served by netlify!”).

Anyhow, as of yesterday you can update any such redirects that mention to as it’s all configured (except the forced

Thank you, much appreciated!

I just got a reminder about this change via email… it is the first I heard about it. More warning would have been good. I appreciate the free hosting but it is a little painful since all my users will now loose everything they saved to local storage.


Will my current sites continue to work?

is only really true insofar as “my sites work” means “DNS resolves”. Anything that relies on domain whitelisting is going to break without user action. CORS, for instance. It’s unfortunate that the Easter holidays make up a sizeable portion of the notice window.

1 Like

I feel like the question has been answered already and I am sorry for asking but I want to be 100% sure not to misunderstand the coming changes
My current site has a custom domain from a third-party provider and has the following DNS configuration

A record for points to > nelify (
CNAME for is set to

From my understanding, all my configuration can stay as is and will be automatically redirected to Please verify if that is correct. Thank you.

Indeed, that is correct @oppenberger! You could adjust it to point to if you wanted to but it is NOT required in the foreseeable future.

1 Like

Hmm, we sent out notice on 13 Feb to give the month’s notice, as well - maybe you missed that one @spacem and @mkjeldsen ?

As the time draws near, a question for clarity. If we are using the API for deploys in a custom build script, does it need to be updated to the new …/ Also will the API base url remain the same?

Good question! Answer turns out to be it will work with either for today, but best practice will be to move to .app.

FYI folks - we had some issues with the rollout and we’ve postponed it for about 24 hours from now (will start around 1500 UTC tomorrow, Wednesday, the 15th)

Thanks for the update. I was just gearing up to start propagating my site changes. Now I can go re-read another Travis McGee novel instead.

You can use the names today, Greg. It’s just the automatic redirects that are rolling out tomorrow :slight_smile:

Travis and Meyer are going to have to wait then, I guess. Thanks.

I just ran a test with one of my less-important sites. was working for a few minutes, then it stopped when I tried to redirect .com to .app in my _redirects file. I might have introduced a loop, though. When I commented out the redirects, each version loads as expected.

There are no changes to the build_hooks urls ( correct?

Yes @awakash can confirm: API usage and hook addresses will not change