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:

Note: v1 is fully maintained and supported. We will only announce a deprecation date once we have ensured all our customers workloads are migrated and the tooling is in place for a smooth transition.

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.

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.

  • 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

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 stricly ephemeral).

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.

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:

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.

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.

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:

now scale sfo my-deployment.now.sh

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.

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

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.:

now file.jpg

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.

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

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.

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.

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.
Tip: if you are unsure about how to migrate you can ask on our community support forums

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.

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.

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.