Using environment variables in the Dockerfile


Can you please share info on how to use the environment variables defined on in the Dockerfile? I was able to use them successfully in my nodejs app. That said, I tried all combinations ${variable}, $variable … but haven’t been able to see how I can call the environment variable this way. Any input would be much appreciated.


Hey @RobinReumers,

If I understand your question correctly, you are asking how to set environment variables in your build process and allowing them to persist to devices runtime? If so, you’d be able to make use of ENV Docker directives. So in your Dockerfile you’d run:


The variable will then be accessible on your device as per usual.

echo $FOO this prints bar


Hi Craig, no I’d like to use the environment variables that I’ve set up on (for the device). So not redefine new ones. Can I not access those?

Best wishes,



Hey Robin,

Sorry about the miss reading, I understand now. Currently, you can’t read variables from API in the build process. However, we are planning on adding build vars which would be definable from the dashboard. Though it’s good to note is that builds are done on a per-app basis, so build-steps specific to individual devices should still be done on the device at run-time.

If you are able to give more information on your use case, I’m sure we could come up with a good work around.



Hi Craig, my current case is the following:
I have a few Raspberry Pi B+s, which each have Arduino’s connected to them via USB. So I’d like to create a variable which defines the “usb port name” and “arduino file name”.
In that way, I can upload for example “/src/arduino-mega2560.ina” to “/dev/AMA0” on one RPI and “/src/arduino-uno.ina” to “/dev/AMA0” on another RPI, depending on what is connected to it. Of course I could split it up in different applications, but I have quite a few different combinations, with much of the same code.

Does this make sense?


Yip we actually recently did an example with this same setup. If you haven’t seen it, you can read the post here.

It uses a handy Makefile which smartly guesses which port the Arduino is loaded to. Let me know if that helps!



Hi Craig, I did read this, thanks. But that means I can only define the variables:
ENV BOARD leonardo

in the actual Dockerfile and it is thereby defined per application. So it’s not possible to set up these variables per device?


Yea you won’t be able to do it per device on the builder. But If you just remove the Make step from the Dockerfile and set a per-device BOARD environment variable for the corresponding Arduino board.

It will then build the Arduino image on the device, which isn’t ideal but should work fine. Also you shouldn’t have to change any code in the demo app as the Make upload command builds the image if needed.

Hope that makes sense?


Right, I see. I indeed use CMD [“bash”,"/src/"] instead now. And the access all the variables in the file. This does seem to give me access to all “per-device” variables, so it allows me to do what I had in mind.




Hello @craig-mulligan,

Do you have any update related to build vars, definable from the dashboard?

In my current case, I’m compiling a .cpp file, and need to read env variables to define how to compile the code



Hey, no, there are no build time variables currently.

What sort of env vars do you need to define for your compilation? Would like to understand better your particular use case.


As an example, build variables might be nice for Sentry integration (perhaps the user would be able to specify the sentry auth token as a “build environment variable”):


Hi @exposedwiring,

In the case of Sentry, if the sentry auth token can be defined during runtime, then you could use the existing environment and service variable infrastructure, documented here:

Build time secrets and variables are not supported yet, but it’s a feature we have in our plans, as you can see in our public roadmap -


@lekkas, looking forward to it. If you were to consider Sentry integration as a use-case, here is the other information necessary in the build-time context per the documentation which would be nice to have accessible:

    "refs": [{