When you make a deployment with ZEIT Now, the first step is the build step. ZEIT Now recognizes a custom build script, with that build script outputting your app into the public directory.

ZEIT Now also supports optimized frameworks that only need to be created and then they are ready to deploy with Now CLI from the terminal.

You are also able to use environment variables (including secrets) in your builds if you do not want to hardcode values for the build.

Note: If you are looking exclusively for an API only workflow, please take a look at our section on Serverless Functions.

Optimized Frameworks

A variety of frameworks have been optimized for ZEIT Now. The following list contains those frameworks that have been optimized and what has been done to aid their performance only on ZEIT Now. Any getting started method will immediately be ready to deploy with Now CLI's now command from the terminal, or to be deployed with a Git integration:

Note: If you are using an optimized framework, you must use the default output directory provided by the framework.

Get Started Command
npm init next-app my-next-project
Create React App
npm init react-app my-cra-project
npx @vue/cli create my-vue-project
npx gatsby-cli new my-gatsby-project
npx ember-cli new my-ember-project
npx degit sveltejs/template my-svelte-project
npm init stencil
npx preact-cli create default my-preact-project
npx @angular/cli new my-angular-project
npx polymer-cli init polymer-3-starter-kit
npx @gridsome/cli create my-gridsome-project
npm init umi my-umi-project
npx docusaurus-init
npm init site my-saber-project
npx degit 11ty/eleventy-base-blog my-11ty-project
npx hexo-cli init my-hexo-project

Defining a Build Script

To build your project, ZEIT Now looks for a build script inside of a package.json file. By providing a build script, ZEIT Now will build your project from fresh on every deployment.

For example, to build Next.js fresh, each time you deploy, the following build script should be placed in the package.json:

  "scripts": {
    "build": "next build"

An example package.json file with a build script that builds Next.js on each deploy.

If you wish to use a script specific to ZEIT Now, you can override this behavior by providing a now-build script.

When ZEIT Now encounters a package.json file with both build and now-build scripts, only now-build will be used.

Using Environment Variables and Secrets

When building your project, it may be necessary to use environment variables.

Adding environment variables requires two steps, defining the environment variable, then making it available to your projects' build step.

Note: This section covers how to make environment variables available at Build Time, if you would like to make them available during Run Time, please see the Serverless Functions documentation.

Adding Secrets

To define an environment variable, you should use Now Secrets. By using Now Secrets, the data will be encrypted and stored securely, no longer directly accessible by anyone, and only exposed to deployments as environment variables.

Adding Now Secrets can be done with Now CLI, providing three options to work with them.

Note: When adding Now Secrets with Now CLI, the secret name is automatically lowercased before being stored.

To define a Now Secret, use the following command:

now secrets add <secret-name> <secret-value>

Defining a Now Secret using Now CLI.

To remove a Now Secret, use the following command:

now secrets rm <secret-name>

Removing a Now Secret using Now CLI.

To rename a Now Secret, use the following command:

now secrets rename <secret-name> <new-name>

Renaming a Now Secret using Now CLI.

Providing Environment Variables

To provide your project with environment variables during the Build Step, you should create a now.json file like the one below:

  "build": {
    "env": {
      "VARIABLE_NAME": "@secret-name"

An example now.json file that provides an application's build step with a defined environment variable.

When providing environment variables to your application, the value should always be prefixed with @, followed by the name of the Now Secret or environment variable name if using a .env.build file during local development.

To use the environment variable from inside the application you would need to reference it using the correct syntax for the language being used. For example, using Node.js, the syntax would be:


Accessing a defined environment variable from within a Node.js application.

Now, whenever the process.env.VARIABLE_NAME key is used, it will provide the application's build step with the value declared by the referenced Now Secret.

During Local Development

When using now dev to develop your application locally if you require the use of Serverless Functions, Now Secrets are not available. This is a security measure, to prevent accidental use of production secrets during development.

To use environment variables during local development, create a .env.build file at the root of your project directory, for example:


An example .env.build file that provides the Build Step with a defined environment variable.

Warning: Usage of a .env.build file is only possible during local development and will not be made available when deploying for security reasons.

Updating Environment Variables

Environment variables are made available to the build step, meaning that they do not update in the application unless it is redeployed.

If you change the value of a Now Secret or environment variable and want your application to be aware of this, you should create a new deployment.

Reserved Variables

The ZEIT Now platform reserves the usage of some environment variable names by default. You can find a list of these names in the limits documentation.

Ignored Files and Folders

By default, ZEIT Now ignores certain files and folders for security and performance reasons, preventing them from being uploaded during the deployment process.


A complete list of files and folders ignored by ZEIT Now during the deployment process.

Note: You do not need to add any of the above files and folders to your .nowignore file.

Technical Details

Maximum Build Duration

A build can last for a maximum of 30 minutes. If the build exceeds this time, the deployment will error.


Each build step will cache files used to build the project, or files used in subsequent deployments, such as node_modules, yarn.lock, package-lock.json, which are cached by default.

The caching mechanism for builds ensures that the next deployment will happen quicker by skipping downloading files that have already been used in a previous deployment.

The maximum stored cache for builds is 3Gb.

If a deployment fails, a cache may still be established for successfully built files, but failed builds will not be cached.

Private npm Modules for Static Builds

To install private npm modules, define NPM_TOKEN as a build environment variable in a now.json file.

Alternatively, define NPM_RC as a build environment variable with the contents of ~/.npmrc.

Prevent Cache Usage

If you need to ignore the cache for a deployment, you can do so by using the -f flag for Now CLI. This prevents the cache from being used in the deployment and ensures a fresh install for all dependencies.

Framework Versioning

In some cases, currently only for Hugo and Zola, you can choose which version of a framework to install for your deployments.

By including a build.env configuration property in a now.json file at your project's root, you can define your framework's version with the following keys:

Variable Key

For example, defining the Hugo version in a now.json file would look like the following snippet:

  "build": {
    "env": {
      "HUGO_VERSION": "0.61.0"

An example of defining a version for Hugo with a now.json configuration.


For more information on what to do next, we recommend the following articles: