Problems with multiline environment variable

I was wondering if anyone had any tips regarding multiline environment variables.

Specifically, I’ve got a PEM formatted private key for accessing a Google service. I’m currently reading it in via an environment variable but I keep getting the error Error: error:0906D06C:PEM routines:PEM_read_bio:no start line. I’m fairly sure that’s because the newlines aren’t being preserved and the parser can’t find the start line.

Here’s a screenshot of the results of me pasting the environment variable in as a service variable:

Making all of this worse: this was working yesterday. In between one deploy and the next this stopped working. So if this issue sounds familiar or someone else has a workaround or any ideas, please let me know.

1 Like

Hey, when was the last deploy where this worked? And have you tried using newline escape sequences?

Last time it worked was yesterday, not sure about the time. Late afternoon for me (I’m in CDT).

I’m not sure I escaped them enough. :slightly_smiling_face: I wrote \n (the first time I tried to get this to work) and was getting the same error. I haven’t tried it today. Maybe I should’ve written \\n? Any opinions before I go find-and-replacing when I get a chance?

Thanks for the info – just trying to discern whether it having stopped working might relate to our multi-container rollout. If it has worked the entire time before, and doesn’t now, this could be a bug, we’ll check.

1 Like

Can you tell us how long ago you set this multiline value first? Was that weeks ago, or did you update it in the past couple of days?

Past couple of days. I think I even opened my account yesterday.

I’m having the same problem; if I paste in multi-line strings then the newlines appear to be turned into spaces. Did you find a workaround / was this resolved?


We can confirm that this is an issue with the Dashboard, we have already filed an issue and will update the thread when the fix reaches production.

Thanks for reporting!

In many of my Google integrations I configure the base64 part of the secret, and manage the new lines from within the code. Not a fix, but a workaround, and in my case also leaves the configuration values cleaner.

@drhayes @WillFG We’ve released an update to the dashboard that fixes this issue. Line breaks in environment variable values are now preserved correctly.

Hmm, not working for me.

I input my yaml file and the newline characters are gone in my environment variable

Hey @cnr can you give me an example file and what you expect to see on the printenv | grep MY_FILE side of things?

For most file type env vars I always transform them to base64 and then transform them back on the device side, that way I know they are always correct. But lets see if we can figure out what is going on for you.

Hey @cnr , I just looked a bit deeper into this and it looks like the “fix” for this was rolled back because it was affecting older OS devices that couldn’t interpret the newlines that fix introduced. So for now the currently recommended way to do files in env vars is to use base64 encoded env vars.

@shaunmulligan Thank you for looking into this! That would explain why it’s not working.

I can certainly base64 encode, but then the utility of the dashboard env var setting tool is a little bit decreased because I can no longer edit the variables in the dashboard, there is now a prior step.

For context:
We use a single env var with our entire config file in it. Originally this was intended as YAML, but now we are using json so we can still edit the cleartext values in the dashboard.

Is there any way you could distinguish between the compatible and incompatible devices when newlines are concerned? Maybe it could just auto-convert to base64, or auto-strip newlines in the older devices but leave the newer devices untouched?

No problem @cnr and thanks for the context. We have a plan to add “env files” to the UI, which would suit this use case and others where you would want to put say a CA cert or something a long those lines.

I will chat to our team and see if there is an easy way around this, but can’t guarantee we will get it fixed very quickly, so for now the current recommendation is to use the base64 method unfortunately.

1 Like

Sounds good, that’s not too much of an inconvenience. I can work with that.