Upcoming Account Impact: New Environment Variables API endpoints

Starting February 21st, 2023, Netlify will begin migrating remaining sites from the classic environment variables experience to the new and improved experience. You can learn more about the updated experience and migration on the blog.

If your team uses Site API endpoints to manage environment variables, you will need to update your logic to call Environment Variables endpoints instead.

Sites already on the new experience

If your site is using the new experience, site environment variables are located under Site settings > Environment variables.

Currently, if you use Site endpoints to manage variables on these sites, nothing much will happen. Starting ETA February 21st, 2023, these API calls will begin failing. You will need to remove the env key from your request body for calls to these endpoints to succeed. Variables can be managed using Environment Variables endpoints.

Sites that are not yet on the new experience

If your site is using the classic experience, site environment variables are located under Site settings > Build & deploy > Environment > Environment variables.

Environment variable management for these sites will likewise need to move to the new Environment Variables endpoints.

Although we cannot provide an exact date for when your sites will be migrated:

  • We will start moving over sites beginning February 21st.
  • Enterprise sites can expect a migration in early March.
  • Your team’s audit log will show a message when your account has been migrated.

If you’d like to opt a site into the new experience sooner, you can do so now.

We hope this helps and that you enjoy the new scopes and contexts functionality for environment variables!

Unfortunately we’ve faced an issue with the new env setup as follows:

{“code”:422,“msg”:“Environment variable value is too long. Must be 5000 characters or less.”,“error_id”:“{:request_id=\u003e"01GRX8CZXW8M9MN2MBP4EADR6J”}"}

Is there a need for this restriction which was not there on the earlier?

Thanks for the feedback, @zehawki! This is an anti-abuse protection we felt should’ve already been in place. May I ask roughly how long your variable is? Potentially we can fine tune this a bit to strike the right balance.

Hi @zehawki! One approach you could take to circumvent this limit is to encrypt your sensitive value, commit that encrypted value to your repo, and then store the encryption secret as an environment variable. You’d then decrypt the value in your app at runtime. This would work around a limit that AWS Lambda imposes of 4KB of total environment variables in the Functions scope too.

Here’s a StackOverflow post on how to use openssl to encrypt a value with a secret.

Another option is to dynamically pull the value in from a secure location (e.g. a vault like 1Password).

We store a base64 encoded image in one of the variables, so the length could be quite long. Its end customer controlled. For one of the sites its ~10000 chars :sweat:, for others its 2500, 4000 etc. This is not sensitive info at all, but it is variable per site and cannot be a link to a graphic asset, since its supposed to display as a loader on 1st load.(A loader which waits for an asset to be fetched over the network, in order to show loading is a bit of a catch22).

If you have a workaround or a better way to handle, I’m very happy to do accordingly.

Why is this topic closing on the day the migration take effect?

It’s just an automatic period. I’ve extended that out to next month. That said, it’s always welcome to bring feedback to the forums at any time, even if the original announcement has closed!

1 Like

Did the PUBLIC_URL get lost in the mix?
Had a react site that used that, and now it’s deploying as ‘.’

Was I just lucky before this, and things worked :wink:

Hey @valentinedwv,

PUBLIC_URL has never been a built-in variable: Build environment variables | Netlify Docs

Could you confirm what it was doing?

Hey @zehawki,

Could you clarify your use case a little further? Where exactly are you using the image? During your site’s build or functions? If it’s the former, I believe you can write a build plugin or use some other tooling during site’s build to convert the image to Base64. If it’s in Functions, you can use included_files parameter in netlify.toml to bundle that with the Functions. In either of these cases, I don’t see a good reason to store it as an environment variable. Am I missing something?

Rather than being empty, it was now ‘.’
so paths that would have referred to root, aka /somescript
became page/somescript

Nothing has changed with that. We still do not set any PUBLIC_URL variable by default.

This topic was automatically closed after 41 days. New replies are no longer allowed.