After our recent introduction of Now + Github, we have been hard at work on making key improvements, such as deployment from forks and workflow improvements.
Today, we are happy to unveil the most important additions for this integration yet:
  • Every push is built and deployed, not just pull requests.
  • The master branches can now be auto-aliased to custom domain(s) or subdomain(s).
  • PR Reverts result in instant rollbacks, due to Now's immutable architecture.

Submitting and merging a pull request with changes that are automatically deployed and aliased.

Every push on Now

Once our GitHub App is installed, any repository with a now.json file (even if empty) will be automatically built and deployed in the cloud.
Until today, this would only happen when submitting a pull request. We are happy to announce that effective immediately, all your pushes will be honored.

Every push is deployed automatically.

If Now needs to give you feedback about an error, such as an invalid now.json configuration, we will provide feedback inline with the commit:

Any obstruction to deployment will be pointed out, helping to quickly get your changes live.

Master Aliasing

If your now.json contains an alias field:
  "alias": ["", ""]
When a deployment is built as a response of a push or merge to the master branch, we will alias automatically if successful.
Let's take a look at a simple example:

With an alias configured, every push to the master branch will result in automatic deployment and aliasing.

For teams and production-critical websites, pushing to master is not always regarded as the best practice. However, this same behavior also applies to merging pull requests to master.
Typically, the workflow for your team will be something like this:
  • A PR is submitted by an engineer.
  • Every push in the PR gets its own unique, immutable and forever-available deployment.
  • The rest of the team can access deployments by clicking on ✅ or the Checks UI.
  • Reviewers (such as your QA team) will take a look at the code and test the website or API.

Each pull request is automatically deployed with each push, allowing you and your teammates to review the live changes instantly.

Note that because we support Dockerfile as a way of building your static websites or serverless deployments, you can also run tests as part of this process.
This means that if a deployment fails to be built or tested, the aliases will not be applied.

Synchronization, Guaranteed

When we think about the problem of "deploying every push", we look at it from a slightly different angle: we think of it as synchronizing the state of your branch with the intended Now state.
Consider this example: at the same exact time, 5 different developers working on a GitHub repository connected to Now merge 3 pull requests and force-push to master twice.
This is how our system will handle this scenario:
  • The first push will start building.
  • All subsequent pushes, while the last one is building, will be queued behind it.
  • By the time the first one finishes building successfully, the alias will not be applied, since our system knows that it is not the final intended state.
  • The most recent deployment will be prioritized, built and, if successful, aliased to your desired domain(s).

Fault tolerance

Our GitHub integration depends on the same public APIs that we document and share with our customers.
In any distributed system such as ours, it is accepted that all kinds of transient failures can occur. For example, we might be able to build your project, but the API call to perform an alias might transitively fail.
In the spirit of synchronization, we provide you with strong guarantees that we will back off and retry the operation until the state between GitHub and your Now deployment and subsequent alias converges.
In other words, once GitHub notifies us and successfully queues the job with us, we ensure its successful (eventual) execution.

Instant rollbacks

One of the highlights of our system is that we consistently map all code and configuration to a unique URL.
In other words, if you do not make any changes to your code and run now, we will give you the URL for the deployment we already have.

Deployments with no difference in content to previous deployments will result in the same link to the first deployment, instantly.

This property happens to be critical when the need to quickly roll back a change arises.
Consider the following example:
  • Your master branch is perfectly in sync to Now.
  • A reviewer merges a PR with a change and forgets to thoroughly verify the changes.
  • When the deployment builds and is put online, you realize the application does not look good.
  • You, therefore, revert the PR and merge it. In this step, the code and configuration now perfectly matches a deployment URL Now previously had! Therefore, Now does not need to re-create nor re-build anything, and the alias is performed in a matter of milliseconds.

Reverting a change will result in an instant rollback.


While we are very proud of the engineering and design efforts that went into making this set of features possible, we really want to credit our amazing community for pushing us to get here.

Your feedback helps us make the best product and experience possible.

We think the best way to build the Cloud infrastructure we all want is as part of an open dialogue with our customers. Please join us and share your feedback and insight.