This enables you to to deploy with one
, preserving the security, reproducibility, and reliability of Docker containers — without any of the hassle.
Today we are glad to announce support for build-time environment variables
. This enables you to expose any secrets
or constants (like
) to your build process.
Build env works exactly like run-time env
, but inside the
namespace. Here's an example
In this case I'm exposing two env variables:
NPM_TOKEN which references the contents of a secret
NODE_ENV as a constant string for configuration
That's all it takes! Your
can then use the
and embed the supplied env variables.
We have upgraded now-cli
to add support for the
--build-env NODE_ENV=production \
This option works exactly like how
--env work for run-time environment.
In the example above, we used
for a good reason: many teams around the world make use of private npm modules
, which require a custom token.
How does it work? First, we need to populate the
secret in your account or team context. We recommend you generate a readonly npm token
specifically for this purpose:
npm token create --read-only
Once you have the value, create a
npm-token secret from it (which we referenced by using the
@ special character in our config):
now secret add npm-token MY_TOKEN_HERE
At this point, you can freely use it inside
FROM mhart/alpine-node:10 as base
RUN echo "//registry.npmjs.org/:_authToken=$NPM_TOKEN" > ~/.npmrc
COPY package.json yarn.lock /usr/src/
COPY . .
RUN yarn run build && yarn --production
COPY --from=base /usr/src .
CMD ["node", "start.js"]
- Makes use of Node.js 10 as a base image
- Makes use of multi-stage builds to make the resulting image as lean as possible (by excluding
npm from the run-time image, and therefore tightening security)
- Is able to install packages from private npm
- Is optimized for only re-installing dependencies if
npm would also work.
If so desired, one could substitute
, and then execute
in place of
. Another option is to use the newly introduced npm ci
This power and flexibility at build-time is why we think
Dockerfile is the perfect solution for your cloud builds.
We packaged the example above as a starter repository for a static deployment
and one for a microservice
. To make use of them, just follow the instructions on the README.
The techniques described above are applicable for any programming language or stack. You can expose any number of build env variables you require.
All the special Now env variables
are automatically exposed to the build step, such as
Some other ideas for how you can use build env include:
- Generating configuration files automatically
- Exposing information about what deployment is running in HTML comments of static deployments for debugging
- Dynamically generating content at build-time that gets pre-rendered statically
Customizing the build environment is an essential feature for sophisticated build processes, especially those that require special access and permissions to download dependencies or data.
We are very happy about how standardizing around
Dockerfile brings a broad range of benefits in terms of security and performance, but in particular we are excited about it opening up our platform to an even broader community of developers.