RENDER_EXTERNAL_HOSTNAME empty on free web service

Hi all,

I’m having a weird issue as of recently: RENDER_EXTERNAL_HOSTNAME is empty on a free web service but gets populated as expected on preview environments of the same web service.

I can track this because of a side effect: I’m using this env variable to get the URL of the backend by using something like this:

// .env file
// Required by NextJS

// backendUrl.ts file

export const backendUrl = process.env.NODE_ENV === 'production'
  ? `https://${process.env.NEXT_PUBLIC_RENDER_EXTERNAL_HOSTNAME}/api`
  : 'http://localhost:300/api/'

In my app, all requests to the backend resolve to this Request URL: https://api/user/profile
But on pull requests on the same web service, using the exact same code of the above snippet, URLs resolve correctly.

Did something change recently? Is this an expected behavior?

The work around is pretty simple (detect if it’s a pull request via IS_PULL_REQUEST env variable, and if not use the hardcoded URL of the service.

I’m just curious if this is just a bug, because it used to work as expected until very recently.


Hi Alex,

Thanks for reaching out.

I’m not currently seeing RENDER_EXTERNAL_HOSTNAME as empty on my own free plan Web Services.

I’m also not 100% sure .env files are parsed dynamically for existing variables as shown in your example, I’d need to try that out.

In the meantime, you could do a quick check to confirm if the RENDER_EXTERNAL_HOSTNAME is set on your service’s running instance by prepending some like…


… before your existing Start Command, and check the logs for the output, when the service starts up again. If it outputs the domain, then there’s likely an issue in how you’re assigning that var to NEXT_PUBLIC_RENDER_EXTERNAL_HOSTNAME.

If you do see that var as empty when doing that quick check above, please share the logs & service name/ID so we can take a closer look.



Hi Alan!

Thanks a lot for your reply, it pointed me in the right direction. Indeed Render works as expected; it was a PEBCAK after all. I had a wrong condition in place that used to work due to a shared env variable between staging and production web services.

After a env group update that changed the aforementioned variable in staging, it was not working as expected on staging but working on pull requests due to an early exit if process.env.IS_PULL_REQUEST existed.

Sorry for the false alarm.

For what is worth, the dynamic env variable assignment works, at least in terms of what we expect to happen in NextJS - the value is transferred as expected to NEXT_PUBLIC_ variable, and then it’s replaced by webpack in build time.

Hi Alex,

Very glad to hear you were able to resolve your issue.

Thanks for using Render!


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.