At ZEIT, one of our guiding principles is the adherence and support of protocols and standards that the industry and community have built up over time.
Today, we are proud to introduce our native support for Dockerfile as a mechanism for building and pre-rendering static deployments.
Take a look at the "hello world" of Dockerfile derived static deployments.
Our Dockerfile looks like this:
FROM busybox
RUN mkdir /public && echo "<h1>The time is $(date)</h1>" > /public/index.html
Then we set { "type": "static" } in now.json and run now:

We write our Dockerfile to output to /public and then run now with type=static

That's it. The only requirement is that you place the result of your build step in a /public directory.
You can extend your now.json with a static configuration object to support all the new static deployment options.
There are 3 key ways in which Dockerfile improves upon other build systems:
  • Reproducibility by allowing you to run docker build -t my-site . on your developers' machines and get the same exact result you get in the cloud
  • Security by putting you in complete control of the base image, containing the runtime and its dependencies. No surprises about what versions of each program are running.
  • Freedom from lock-in by leveraging Dockerfile, the de-facto standard for specifying builds, for which open-source tooling is widely available.
In addition, we find that understanding and finding the way around a project becomes much easier for newcomers when a generic way of building it is made available.
In light of the announcement of our GitHub integration, all it takes to get your team up and running is to create a Dockerfile, a one-line now.json file, and then send a pull request:

This pull request shows you automatic static deployments built with Dockerfile in action

Let's say you want to use Node.js 10 and Yarn together with a project you generated with create-react-app, a React app generator.

Our live CRA app created from this repository

Your build process would be powered by a Dockerfile that looks like this:
FROM mhart/alpine-node:10
WORKDIR /usr/src
COPY yarn.lock package.json ./
RUN yarn
COPY . .
RUN yarn build && mv build /public
Adding a .dockerignore working as a whitelist prevents uploading unnecessary files onto our build (e.g.: node_modules) and speeds things up:
To get started using this feature, we created a convenient repository you can clone:
git clone
You can modify the pages directory and re-deploy at will.
If you fork it within your organization and configure our GitHub app, you will then be able to automatically deploy each pull request.
Over the last couple weeks, we have introduced some key advancements that make static deployments on Now a breeze:
  • A versatile configuration spec for static deployments with several new features to customize how your pages are served
  • The Now + GitHub app, which allows you to source-control now.json and Dockerfile and makes deployments automatically for every push
  • The Now CDN, which serves your static and dynamic deployments in 150+ locations throughout the world, combined with best-in-class DDOS protection
We are excited about continuing to improve your workflow, reduce latency and make your business as a whole more efficient.
Please let us know how you put these features to use!