Today we are proud to present Now 2.0 to the world. Our new platform simplifies the organization of your codebase, while dramatically improving the reliability and scalability of your deployments.
From the outside, the ease of use of now remains unchanged. Just write code in your favorite language or framework and push.
Behind the scenes, Now 2.0 works like an extensible build system and compiler, capable of transforming your sources into static files and serverless functions (lambdas) for production.
The Now 2.0 platform features include:
  • A unified deployment type: All deployments are one type, regardless of static or dynamic parts
  • Massive build parallelization: Each deployment can kick off many concurrent serverless builds.
  • Monorepo support: Define API endpoints in Go, PHP, Node.js, Next.js, and such, in just one repository.
  • Zero-instruction builds: Our open-source builders take the build and cache config burden away.
  • Universal Cloud: Our platform leverages the best cloud infrastructure, with no lock-in or config.
With the following pricing improvements:
  • Fully on-demand pricing: Pay exactly for what you use, starting at \$0.
  • Per-100ms pricing for compute: Pay by the cycle of compute for dynamic workloads.
  • Free seats for small teams. Up to 5 included at no cost for paid customers.
Including a better free-tier for our community:
  • Private and secure sources at all times. No public vs private config.
  • No concurrency limits. 1,000 free lambda invocations per day.
  • Built in free Now CDN, with new locations being added regularly.

A Walkthrough

Let's start with a simple folder or GitHub repository with a simple contact form that gets received by a script and sent to Airtable:

Our sample project with some source files. One we intend to serve directly, one to invoke on-demand.

Let's deploy it by running the now command. We get our URL back here:

Our new CLI shows the generated outputs from a build. In this case, just our source files.

Let's navigate to /contact.php:

Our source code to handle the form submission being served statically, as plain text.

As you can see, we are leaking all our source code and it doesn't seem to work.
The reason, however, is that we deployed our source files without any build steps that can transform them into other static files or lambdas. Let's fix that.
  "builds": [
    { "src": "*.php", "use": "@now/php" },
    { "src": "*.html", "use": "@now/static" }

Our now.json now defines two builds. One to create .php functions and one to carry over static files.

Let's try deploying again: Submit the form. It works!

The deployment outputs a static file (index.php) and a lambda (contact.php)

As we can see in the updated Now CLI visual feedback, adding @now/php resulting in the processing of a build that outputted a lambda, identified with λ.
The @now/php identifier refers to an npm package whose purpose is to execute the build logic. We call it a Builder.
Builders operate on an abstract open-source API that gives us future-proofing, prevents lock-in and maximizes interoperability across all cloud infrastructure providers.
The best part? While we maintain official builders that make your life easier for popular languages and frameworks, you are free to write your own.
In the spirit of a true monorepo, let's now add a Node.js endpoint as /date.js:

From `@now/php` to `@now/node`

The reason we started with PHP as our example is not coincidental. While it's true that PHP is the technology behind tremendous successes like Facebook, Box, Yahoo, Wikipedia, Flipkart, WordPress, and many other giants, it's not as popular of a choice as it once was.
In many respects, PHP has represented a unique and scalable marriage between programming language and execution model. The way it helped scale those companies is by imposing a fully serverless architecture:
  1. No servers to manage (infrastructure)
  2. No servers as an abstraction (code)
In line with the second point, the @now/node builder, therefore, presents you the following API:
module.exports = (req, res) => {
  res.end('The time is: ' + new Date())

We retain the fully standard Node.js API, but reduce its surface.

By adding just one item to our builds config we can make our /date.js entrypoint come to life:
{ "src": "*.js", "use": "@now/node" }
Then we deploy the full project again and go to

Now de-duplicates your outputs, only re-deploying the ones that have changed.

Taking it to the Next Level

For a more exciting demonstration, let's take our favorite framework for server-rendering websites and applications: Next.js.
Next.js rose to popularity by distinguishing itself from SPA frameworks:
  • Not one entrypoint (e.g., index.html), but many.
  • Request and filesystem affinity (by default), yet flexible.
  • Zero-configuration (or minimal).
The main idea is that you create a pages directory, define files inside which become routes, each of which exports a React component.

My React Project Folder

Crucially, each entrypoint becomes a kind of sub-application. The compiler automatically code-splits to make sure that you don't ship extra code to users who are entering through only a certain part of your application.
This has a dramatic effect on scalability, both at the code and team levels. A page can accumulate complexity that doesn't impact other sections. This means teams being able to fearlessly evolve their own codebases without being encumbered.
This is what makes Next.js the natural option for Walmart's, Marvel, Nike, and so many others.
Just like in our previous PHP example, Now allows you to build your Next.js application very easily:
  "builds": [
    { "src": "next.config.js", "use": "@now/next" }

The entrypoint for @now/next can be next.config.js or package.json.

Let's take a look at what happens when we deploy this:

Compiling an existing Next.js app, previously deployed as a container, to serverless functions. Zero code changes.

Notice the output: unlike our other builds, @now/next is yielding static files as well as multiple lambdas. This translates into:
  • Reduced cold bootup times
  • Per-route scaling and resource allocations
  • Increased security due to reduced surface
With zero changes whatsoever in how you were writing your application until today.
Now 2.0 brings symmetry to the cloud, by also code-splitting your backend

The Majestic Monorepo

Instead of having one large build process and one large process per project, you instead get user-definable parallel builds.
A build is a piece of code that takes an entrypoint sourcefile (like contact.php) and transforms it in some way. In the case of our example, @now/php is the build that turns contact.php into a cloud function that executes on demand.
Builds can also transform static files into other static files, or yield new ones. They are written in Node.js (LTS versions only), published to npm and open-sourced on GitHub.
As an example, we can optimize PNGs with a massive degree of parallelism by using the @now/optipng builder.

A basic static site, whose sources get transformed to become ready for production.

Most interestingly, Now 2.0 enables what we will call The Majestic Monorepo, inspired by a similarly named essay by DHH, creator of Ruby on Rails (The Majestic Monolith).
We don't agree that you should be orchestrating a big server abstraction (a monolith), but we believe you should be able to collocate your APIs and your business logic in a single place, with a cohesive deployment story.
It looks, feels and deploys like a monolith, with none of its downsides
As an example, Now Lambdas now enable the following:

An example of how you can organize your source code. Any structure works.

With a now.json file that looks like this:
  "builds": [
    { "src": "api/*/index.js", "use": "@now/node" },
    { "src": "api/*/index.php", "use": "@now/php" },
    { "src": "api/*/", "use": "@now/python" },
    { "src": "api/*/index.go", "use": "@now/go" },
    { "src": "index.html", "use": "@now/static" }

Code Snippet

Just with this, we get a fully static website (index.html) deployed to our CDN, with dynamic /api/ routes defined in 4 different programming languages. No servers to be seen.

Serverless Static Builds

Since handlers can turn a set of static files into other static files, they are a great fit for performing static builds, even more easily than it was possible before.
As an example, consider the mdx-deck project. You define your slide deck as a markdown file (with the .mdx extension), but the build process outputs index.html and main.js.
To make things interesting in this example, we will define not one but four decks.