Upgrade to 2.0

The Now Platform 2.0 simplifies and streamlines the deployment of static and serverless workloads.

Compared to 1.0:

• There are no deployment types. A single deployment can have multiple static and dynamic entrypoints, even written in multiple different languages.
• Your app's source code can be structured as a monorepo. No need to think in terms of microservices, multiple repositories, composition via YAML files, services meshes, etc.
• Multiple parallel builds can be specified to compile source into static files or serverless Lambdas. These builds are written as Builders in JS and can be easily used and shared.

Migrating your projects to 2.0 will result in:

• Massively improved reliability and scalability.
• Much lower prices.
• Simpler codebases thanks to Builders.
• Faster build times due to build parallelization and build deduplication analysis.
• Faster cold boot times due to increased granularity.

Changes Overview

Platform Versioning

We have introduced a strict notion of platform version. All existing users are locked to 1 to ensure there is no negative disruption to existing workflows.

Go to your user and team settings to upgrade your account or team to Latest. After you do so, all new deployments will always use the most recent version (2). This is also the default for all new teams and accounts.

If you want to retain certain projects on v1, or pin your platform version, we recommend updating your now.json accordingly before you make the switch:

{
  "version": 1
}

For a smooth deployment experience in the future, we recommend all upgraded projects to explicitly set the version field (e.g.: to 2). Our clients and GitHub bots will remind you as well. If Now upgrades to a version 3 in the future, all your existing projects will work correctly even if your team or account setting is Latest.

Free Tier

The free tier was previously named OSS. It's now known as Free and it doesn't imply a public visibility of source code nor logs. That feature needs to be manually triggered via the --public flag.

Free seats

• The owner of a team no longer pays for a seat
• Teams with up to 5 members don't pay for a seat
• Team seat price has been adjusted

Reduced prices

The following prices were drastically reduced:

• Cost of compute.
• Cost of DNS and CDN zones.
• Cost of logging (no more storage costs, charged per-line and strictly ephemeral).

Fully on-demand

Plans are no longer available for selection. Users on the legacy plans will continue to be on those plans until they are phased out.

The only two subscription types available now are Free and Unlimited. If you upgrade to the unlimited plan and are still running v1 deployments, they will be billed according to the prior on-demand plan.

No Types

There is no notion of types of deployments anymore. Previously, deployments could be of types:

• STATIC
• NPM
• DOCKER

From now on, the deployment type is no longer used and not exposed via the relevant GET API endpoint.

We can still accomplish the dynamism of the NPM and DOCKER deployment types but associating source files with Builders that can output individual Lambdas.

This in turn enables:

• Monorepo support
• Multiple programming languages and frameworks to co-exist
• Faster cold boot-up times due to refined entrypoint granularity
• Faster build times by greater parallelization and deduplication

No Daemons

Running a process persistently as a daemon requires a lot of operational overhead, such as setting up readiness checks, health checks and close monitoring.

While v2 will not support this as a primitive, we still plan to address the following use-cases directly that our customers typically use processes for:

• Control and sync loops. A series of tasks that execute sequentially to verify or synchronize some remote state.
• Scheduled jobs. E.g.: a task that needs to run every 50 minutes.
• Jobs consumed from a queue.

We believe that these use-cases can be modeled and executed on much more effectively by taking full advantage of the serverless paradigm.

To help our customers in the transition, we won't announce a deprecation date for v1 until these additional features are generally available.

No Instances

With Now v2 we're removing the notion of a deployment instance. There's no need to keep track of them and they just add overhead to the UI and database.

While it's still very useful to think about what happens when an instance of a container is running or not as it pertains to hot vs cold invocation of Lambdas, attempts to count or enumerate instances in a UI are impractical and not very beneficial to the developer experience.

No Config Mutability

Static assets and caches are served from our Global CDN automatically. When it comes to code invocation with Lambdas, it makes sense to think about whether the code is executed in a single region or multiple.

We support the regions parameter in now.json to this end. When you make a deployment and Lambdas are produced in the build steps, we deploy them to the specified regions.

However, in the past we allowed for mutating these settings without re-deploying:

The now scale command is no longer supported.

Due to our deduplication system which prevents re-building and re-uploading unnecessarily at any given step, re-deploying code to different regions is now fast and practical.

Mutation is therefore going away, in favor of just changing now.json (locally or with a Pull Request) and creating a new deployment instantly.

No Singleton Builds

Previously, one could define a global build step or set of steps that run serially upon deployment. This could be done for example with a build step in package.json.

While effective, this meant constraining a project to serial execution. Serverless, however, allows for massive parallelization.

With Now 2.0, your build steps are specified as a list of builds inside now.json.

For example, say you want to build 2 sub-projects statically and 2 APIs wrapped as Lambdas:

{
  "builds": [
    { "src": "gatsby-site/package.json", "use": "@now/static-build" },
    { "src": "react-static/package.json", "use": "@now/static-build" },
    { "src": "*.go", "use": "@now/go" },
    { "src": "*.js", "use": "@now/node" }
  ]
}

The build process will happen in parallel and the deployment shows all the resulting output files and Lambdas: deployment url

Index behavior changes

Previously, if a single file was deployed (with any name, like file.jpg), our indexer would make it accessible as both / and /file.jpg.

While this is desirable for the purpose of quickly sharing a static file, e.g.:

We've decided to make this logic happen on the client side, instead of the server side. Now CLI will define an item in routes that also maps / as a special case.

Furthermore, we have redesigned the directory listing style and added a new icon to represent Lambdas:

The new Lambda icon shows in the source view of deployments to show which files are Lambdas.

Universal Now, in the Cloud

The client-side features for multi-cloud access on Now CLI are effectively deprecated, in order to move them to the server side.

During early testing of that feature, we found serious user experience and security challenges.

Instead, we will address this user need by:

• Focusing on providing open-source Builders that allow for your code to be free from proprietary APIs
• Allowing for fine-grained access into the resources we provision with the cloud infrastructure providers
• Important features for interoperability such as VPC support
• Transparent and clear documentation about regions and providers

.nowignore

Previously, the CLI had to implement complicated logic to determine whether to use .npmignore, .dockerignore or fall back to .gitignore if present, according to deployment type when uploading your source files.

Because deployment types are gone, we have simplified the logic to narrow down to: if there's a .nowignore file, it will be used to determine what files to include or exclude.

The .nowignore spec is the exact same as .gitignore. We recommend using it as a whitelist rather than a blacklist to avoid surprises.

*
!index.htm
!api/**

This example first ignores every file and then whitelists which ones to include.

The files property in now.json is similarly deprecated, as to retain a singular source of truth for what files to include or exclude.

Configuration (now.json)

Additions:

• version to specify the platform version the deployment is known to work with.
• routes to define routes and rewrites.
• builds to define parallel build tasks.

Removals:

• sessionAffinity is no longer applicable due to the focus on statelessness. The current behavior is also aligned with the previous default affinity mode.
• type is no longer necessary since there are no types or modes going forward.
• engines is no longer applicable (belonged to the NPM deployment type).
• registryAuthToken is no longer applicable (belonged to the NPM deployment type).
• files is removed in favor of the .nowignore file.
• dotenv is removed in favor of defining them directly inside the deployment configuration. The package now-env can be used to load environment variables from deployment configurations to be used in development.

Additionally, some environment variables keys are now reserved. You can see a full list of these variables in the Environment Variables document.

Environment Variables

Removals

• NOW is no longer assigned. Please use NOW_REGION variable as a confirmation method instead.
• NOW_URL is no longer assigned. Please use the x-now-deployment-url HTTP Request Header instead.

CLI

Removals:

• --links is no longer supported when deploying. The feature had very niche use-cases and was limited in effectiveness.
• now scale is no longer necessary for v2 and deprecated. If you wish to change the regions your Lambdas get deployed to, use the regions config and re-deploy.
• Custom providers are removed, as we shift the strategy to executing the cross-provider logic from our backend instead.

Migration Examples

Upgrade Tips

Don't rush to upgrade

The v1 platform is fully supported and maintained. v2 is superior in nearly every way, but some new features are necessary to completely map some legacy use cases. Most notably, APIs to support loops and jobs.

Ask for help

Our support team and community are ready to answer and welcome all your questions. Feel free to inquire about anything from general architecture to design, implementation, billing and future plans.

Serverless is better without Servers

It might be tempting to use the now/node-server Builder, as seen in the example above, to quickly deploy your app as a Lambda without any code changes.

Keep in mind, however, that one of the benefits of the serverless model, as the name implies, is not only not to manage servers, but also not to think in terms of the server abstraction.

In other words, if you are writing new Server() (in whatever language you prefer), you might be missing out on the granularity benefits of serverless.

For example, many people have throughout the years provided examples on how to deploy express, a Node.js framework, to AWS Lambda:

app.get('/', myFunction)
app.get('/2nd-route', myOtherFunction)
app.get('/third-route', myThirdFunction)

With Now, you can split this into three discrete underlying Lambdas instead, which allows for:

• Reduced surface of error
• Faster cold boot times thanks to smaller bundle sizes ("code splitting" for the backend)
• Per-route scalability
• Faster build and, therefore, total deployment times

As seen above, the code changes required to leave servers behind altogether are very minimal, while the benefits very significant.