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