The ZEIT Now Platform 2.0 simplifies and streamlines the deployment of static and serverless workloads. In this guide we will walk you through the key differences between Now 1.0 and 2.0, and the improvements this brings.
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 Functions
Migrating your projects to 2.0 will result in:
- Massively improved reliability and scalability
- Much lower prices
- 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 1.0, 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.
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 by adding the following code to your now.json
file:
{ "public": true }
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 1.0 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.
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 2.0 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 1.0 until these additional features are generally available.
No Instances
With Now 2.0 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 Serverless Functions, attempts to count or enumerate instances in a UI are impractical and not very beneficial to the developer experience.
No Config Mutability
All static assets and caches are served from our Global CDN by default. When it comes to code invocation with Serverless Functions, 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 Serverless Functions are produced in the build steps, we deploy them to the specified regions.
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 Serverless Functions:
{ "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 Serverless Functions.
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.:
now file.jpg
We have 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 Serverless Functions:
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:
- 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
.
README.md
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 withroutes
to define routes and rewritesbuilds
to define parallel build tasks
Removals:
is no longer applicable due to the focus on statelessness. The current behavior is also aligned with the previous default affinity modesessionAffinity
is no longer necessary since there are no types or modes going forwardtype
is no longer applicable (belonged to theengines
NPM
deployment type)is no longer applicable (belonged to theregistryAuthToken
NPM
deployment type)is removed in favor of thefiles
.nowignore
fileis removed in favor of defining them directly inside the deployment configurationdotenv
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
is no longer assigned. Please use NOW_REGION variable as a confirmation method insteadNOW
is no longer assigned. Please use theNOW_URL
x-now-deployment-url
HTTP Request Header instead
CLI
Removals:
is no longer supported when deploying. The feature had very niche use-cases and was limited in effectiveness--links
is no longer necessary for 2.0 and deprecated. If you wish to change the regions your Serverless Functions get deployed to, use thenow scale
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
Take a look at examples from Now version 2.0
Get started with moving your applications to Serverless.
Upgrade Tips
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.