This post contains content about Now 1.0 – Learn about the latest version, Now 2.0.
Now 2.0 - Upgrade Available
With our latest update, static deployments running on Now became almost twice as fast. Today, we are announcing the biggest set of improvements yet.
This update brings 9 new features that allow you to customize every aspect of the static serving pipeline, from aesthetic URL changes to custom headers and redirections.
The best part: now static deployments are fully compatible with serve, which means you can easily develop locally with no changes at deployment time.

New Features

Since static deployments first got to see the light of day about 2 years ago, at lot has changed.
In order to adapt to the ever-changing needs of frontend developers, we are now offering you a completely open, free, and extremely flexible solution with our new static deployments.


As of today, you can customize how your static deployment behaves in production by creating a now.json file with a static property:
  "static": {
    "trailingSlash": false,
    "rewrites": [...],
This property can contain any of these new configuration options:
  • public (Set a sub directory to be served)
  • cleanUrls (Have the .html extension stripped from paths)
  • rewrites (Rewrite paths to different paths)
  • redirects (Forward paths to different paths or external URLs)
  • headers (Set custom headers for specific paths)
  • directoryListing (Disable directory listing or restrict it to certain paths)
  • unlisted (Exclude paths from the directory listing)
  • trailingSlash (Remove or add trailing slashes to all paths)
  • renderSingle (If a directory only contains one file, render it)

Better Defaults

Out of the above options, renderSingle, directoryListing, and cleanUrls are enabled by default. This ensures that the builds of most static site generators just work out of the box.
Here is an example with Jekyll:
 ~/my-app $ 

As you can see, no special configuration comes into play.

However, all of these defaults can be overwritten easily:
  "static": {
    "directoryListing": false,
Once you have added the now.json file to your project, it will automatically be uploaded to Now when you run now and taken into account every time a request is served.

Simulating Production

Now that static deployments are fully powered by serve-handler, they are behaving just like our command line interface serve when run locally:
As of version 7, you will then see a message like this one:
INFO: Accepting connections at http://localhost:3000
When opening http://localhost:3000 in your browser, you will notice that serve behaves exactly like you configured your static deployment in now.json.
That is because serve now reads your deployment configuration and adapts itself. This means you can simulate exactly how your project will behave when deployed to Now.

Cached in Every Region

Because deployments are immutable, the implementation of the new core for static deployments also allowed us to properly cache all assets served by serve-handler in all our regions:

As you can see, the request was already once handled by serve-handler and is now cached.

Currently, the regions bru (Brussels) and sfo (San Francisco) are enabled.
However, this is just the start. Soon, you will be able to have your static deployments cached in many more regions automatically.

Deploy Everything

With the new options available to you, every single static framework and site generator becomes deployable. No restrictions. No tradeoffs.
We went ahead and deployed some of our favorites:

Open Source

Both serve-handler and serve are fully open source and available on GitHub.
This means that you can now – for the first time in the history of their existence – contribute to how static deployments work.
We are happy to welcome any feedback, bug fixes, or other contributions.


With this release, we are opening up many new possibilities to developers. There is no longer a need to run serve, http-server, or any other static webserver within a Node.js deployment in order to get the maximum in terms of customization.
Instead, the default configuration is now already enough for serving the builds generated by most static site generators (like next export).
And for cases in which you do need to add custom redirects, rewrites, or any other form of custom behavior, our ever-growing list of options has you covered.