For a ZEIT Now deployment to be created, our API requires the client to include a description of the project directory structure and content, expressed as a series of checksums.

If our system finds a sourcefile checksum to be missing in our database, it will request the client to upload it and retry.

Next, our system decides if a new deployment is necessary, based on the project config and sources. If they match an existing deployment, we return its Deployment URL.

It is worth pointing out that there is no notion of editing or modifying an existing deployment. When you make a source or config change, a new deployment is always created.

Motivation

Immutability enables many important properties for scalable deployments and large teams / repositories.

Historical overview and rollbacks

When you run now ls, visit the Deployments List on our web UI, or browse through pull request or pushes made via our GitHub integration, all the deployments will continue to work concurrently.

This allows you to examine the evolution of a project over time. In addition, if a bug is detected, you can instantly roll back by changing the alias of your production domain.

Instant Git Reverts

With ZEIT Now + Github, if a PR is merged that yields an undesirable outcome, it should be quickly reverted. Similarly, one can revert a commit in any branch of a vanilla git repository.

Due to the Now deduplication algorithm, if a deployment existed in the past that matches the new source code state.

Improved Collaboration

Immutability enables projects with many different developers to be effectively deployable without any sort of inhibition.

There is no situation where the changes pushed or deployed by a certain individual or team will step over or overwrite others' changes.

Deduplication Algorithm

The URL structure of each deployment contains in the subdomain, the name of the application and a random UID.

We decide to generate a new UID (and therefore a new deployment), by combining the following information into an internal digest that we look up in our database:

  • The entire deployment configuration from now.json
  • The owner ID (either the user ID or team ID, if deploying within a team)
  • The description of the filesystem. This includes symlinks, modes, pathnames and the checksum of each file's contents

We ensure the digest is computed deterministically by sorting and ordering all the inputs involved in the algorithm.

Our lookup excludes deployments that are in an ERROR state. If a previous deployment matches the digest but failed to build correctly.

Skipping deduplication

There are two ways to force a new deployment to be created when our system would otherwise deduplicate.

  • Make any change to any of the parameters considered by the algorithm above. For example, even changing one character in a comment of a source file yields a new deployment.
  • Force a new deployment by instructing your client to do so.