, 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:
static deployments are
, which means you can easily develop locally with no changes at deployment time.
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
This property can contain any of these
new configuration options: (Set a sub directory to be served)
.html extension stripped from paths)
(Rewrite paths to different paths)
(Forward paths to different paths or external URLs)
(Set custom headers for specific paths)
(Disable directory listing or restrict it to certain paths)
(Exclude paths from the directory listing)
(Remove or add trailing slashes to all paths)
(If a directory only contains one file, render it)
Here is an example with
As you can see, no special configuration comes into play.
However, all of these defaults can be overwritten easily:
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.
Now that static deployments are fully powered by
, they are behaving just like our command line interface
when run locally:
, you will then see a message like this one:
INFO: Accepting connections at http://localhost:3000
http://localhost:3000 in your browser, you will notice that
serve behaves exactly like you configured your static deployment in
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.
Because deployments are immutable, the implementation of the new core for static deployments also allowed us to properly cache all assets served by
in all our
As you can see, the request was already once handled by
serve-handler and is now cached.
(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.
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:
are fully open source and available on
This means that you can now – for the first time in the history of their existance – 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
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