Now 2.0 enables syncing your source code and building it in the cloud, instantly, in parallel.
The outputs of these builds can be static files, served directly via the Now CDN, and serverless functions (lambdas), invoked on-demand as requests come in.
By default, we impose limits on how big your generated functions can be. Today, we are introducing the option to override them (maxLambdaSize).
First, let's dive into why limits exist.

The Lambda Execution Model

The main advantage of the serverless paradigm is that your code doesn't need to run all the time.
When requests come in, your code boots up to serve them. If many requests come in, many instances of your code spin up. If traffic winds down, so do your functions.

This animation illustrates that booting up fast is essential to dealing with concurrent requests

As a consequence of this:
  • You don't pay for code running all day long, even when no traffic comes in.
  • You don't have to worry about long-lived processes becoming unresponsive and needing to get restarted by hand.
  • You don't have to set up health checks or readiness checks of any sort, because there's no process instance to worry about.
  • You have a very predictable way of understanding how your application scales. For each request, there is a new separate and discrete function invocation (also known as the 1:1 model).
Crucially, each lambda "instance" can only be busy with only one request at a time, which means that your function will be booting up (and later shutting down) constantly. A fresh function instantiation is known as a cold boot.
After the function responds, it'll stay hot so that it can be re-used again, in the event that a new request comes in shortly after that.

Limits as Forcing Functions

With this reality in mind, Now attempts to help you in a few key ways:
  • Builders like @now/node compile and compress your source code and its dependencies (e.g., require or import statements) so that you avoid unnecessary overhead. This is symmetrical to how frontend developers bundle and compress their code before sending it out for production web pages.
  • As a side effect, using builders that only ship the code that gets used reduces the surface of error, encourages better security and gets rid of nasty surprises.
  • The monorepo strategy encourages setting up discrete entrypoints for different parts of your application. This ensures that a cold instantiation for, for example, route /a doesn't have to pay the penalty of initializing the code of /b, which could be less accessible or even an old deprecated version.
Limits can sometimes be discouraging, but they can also be a forcing function to prevent unintended consequences, such as slow response times or increased cloud bills.

Code Size and its Impact on Performance

To understand the hidden cost of shipping a lot of code, one needs to look no further than the web platform.
A web browser is not too dissimilar to the serverless environment. The process or container (the browser tab) is instantiated, code is downloaded, parsed and interpreted. If you refresh (twice on Chrome), you can think of the "function" as being hot, due to caching strategies in browsers.
We can also draw from the web platform's attention to the code size problem to understand that there's a cost to parsing and evaluating:

Source — While servers will be much faster at processing through code, these same principles all apply.

Some languages and frameworks are particularly more susceptible to booting up more slowly as a result of increased code size. JavaScript is one of them.

Lifting the limits

We want Now 2.0 to help you, not to inhibit you. In some cases, you might have figured out that an increased function size is not hurting your use-cases.
Or perhaps, to simplify the upgrade path to Now 2.0, you want to deploy a legacy codebase using @now/node-server, and you need a bit more room.
To that end, we're introducing the capability to lift the function size limits to up to 50mb.

An updated table of soft and hard limits for the official now builders.

To increase the limit, starting today, you can pass maxLambdaSize to any builder's config property.
For example, if you have a project as follows:
You can now configure your now.json like this:
  "version": 2,
  "builds": [{
    "src": "graphql/server.js",
    "use": "@now/node-server",
    "config": { "maxLambdaSize": "50mb" }

The maxLambdaSize accepts a value in bytes as a number or a human-readable string.


Limits are an essential part of practical engineering. Serverless functions can be used for a variety of useful purposes, but Now focuses on making them effective for web services.
The soft limits we provide are meant to serve as a guide with these use-cases in mind. Now we give you the full power to override them.
When you hit them, you might want to consider whether:
  • You might be accidentally shipping more code than you intend. As an example, the entire apollo + express + graphql foundation fits in 947kb of code.
  • You can take advantage of multiple serverless entrypoints for your APIs. Not every user action needs to boot up an entire application.
When in doubt, measure.