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.
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 , 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.
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!
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?