Now – Global Serverless Deployments

 ~/my-app $ 


$ my-app/ ls
Dockerfile server.go
$ my-app/ now


$ my-api/ ls
package.json index.js
$ my-api/ now

Static Websites

$ my-site/ ls
index.html logo.png
$ my-site/ now

What's Now?

now allows you to take your JavaScript (Node.js) or Docker powered websites, applications and services to the cloud with ease, speed and reliability. In practical terms, any directory that contains a package.json or Dockerfile can be transported to the cloud with one command: now.

Every time you deploy a project, now will provide you with a new, unique URL (even before the upload has finished). These URLs will look like this (my-app is your automatically determined application name):

When it's time to take your deployment to production, you simply pick an appropriate alias (a custom domain).

Get Started

Let's demonstrate how easy deploying a project with now actually is!

Step 1
Download Now Desktop and log in
Step 2
Create a new directory and switch to it:
$ mkdir my-project
$ cd my-project
Step 3
Write the app configuration into a package.json file...
  "scripts": {
    "start": "micro"
  "dependencies": {
    "micro": "latest"

...and add a index.js file that contains the code you'd like to render:

module.exports = () => 'Ahoy, world!'
Step 4
Run now to deploy. Every time you run now, you get a new deployment!
$ now

The first time you run now, it'll ask for your email address in order to identify you. Simply click on the email you've received, and you'll be logged in automatically.

If you need to switch the account or re-authenticate, run:

$ now login

Once the deployment has started, you'll get a link (copied to your clipboard) that you can share immediately with your peers, even before the upload and startup completes!



now doesn't require you to install certain applications in order to get started.

  • No need to install git or source control
  • No need to setup keys/tokens
  • No complicated cloud provider setup or registration


Every time you run now, you get a fresh URL that represents the current state of your application.

  • No need to remove old ones
  • No setup of applications or projects
  • URLs stay around forever


As soon as you type now, we give you a URL that you can open by yourself or share with co-workers and collaborators.

This URL will show the progress of your deployment. You might see files uploading, and then we show you the progress of the commands executed for deploying your application.

As a matter of fact, now is so fast that you might not even get to see this in many cases!


now exposes servers that speak the HTTP protocol. We don't impose any new proprietary Cloud APIs. You can run your apps - with or without now - with OSS software.

In addition:

  • All your traffic is served over HTTP/2.
  • Traffic is only served over secure connections.

"View Source" in the Cloud

If you add /_src to any now URL, you'll see the code behind it. You and your team will be able to quickly understand what's behind your production systems. This can also be disabled, of course!

But that's not even all...



 "name": "reallybigone",
 "version": "0.0.1",
  "devDependencies": {
 "gulp": "3.9.0",
    "gulp-autoprefixer": "2.3.1",
    "gulp-sourcemaps": "1.5.2",
    "serve": "1.4.0"
    "node-sass": "3.4.2"
  "scripts": {
    "start": "serve -p 3000 ."

Assuming that you've opened up the /_src of your deployment, you can easily hyperlink every single character and line of your code on the server and share it with other people.

This makes collaborative issue triaging and debugging a breeze!

Frequently Asked Questions

Does This Scale?

now's approach to scalability is unique. Here's what makes it special:


We don't under-allocate or over-allocate resources. You don't have to ever adjust any knobs, configure instances or set up processes.


We don't depend on a single specific cloud provider, but abstract them instead. This means that we can always find the best combination of cost, performance, reliability and resistance to failure or censorship.

Why not AWS Lambda / Azure Functions / Google Cloud Functions?

Exposing Just a Function Is Not Enough

In real-world applications the metadata of the request is of particular importance.

The response might vary, for example, according to the capabilities of the client. If the User-Agent is so, or the Accept header is such. These won't be automatically present in your payloads, so you'll have to manually supply them in each function call.

The other missing feature is the response code. Instead of returning 404 when something is not found, 403 when the permissions are not met or 500 when something goes wrong, you'll end up creating a new ad-hoc codec for errors that only your own system understands.

It Leads to Lock-In

The way most cloud providers address the problems described above is by introducing a context object that has access to information from the environment.

The problem is that this context object varies ever so slightly from provider to provider. Were this to be standarized, it would look like HTTP.

We Serve All Your Apps Over HTTP/2

HTTP/2 has two critical features that make your requests effectively as lean as "micro functions", from a bandwidth and efficiency perspective:

  • Multiplexing. HTTP/2 exhibits great latency characteristics and bandwidth use by re-utilizing the same TCP connection for all communications. This provides a great advantage for mobile users specially.
  • Header compression. Headers that are the same over the lifetime of a connection are not sent multiple times.

Which Version of Node.js Do You Run?

We're running the latest version of Node.js by default. In order to customize which version of Node should be run within your deployment, you can specify the enginesfield in package.json.

Let's say you wanted to run the latest version of Node 4, your package.json would look like this:

  "name": "my-project",
  "version": "0.1.0",
  "engines": {
    "node": "4.x.x"

Assuming that you'd like to specify a engines configuration that only applies to your deployment, you can do so by specifying now.engines in your project's package.json file instead:

  "name": "my-project",
  "version": "0.1.0",
  "engines": {
    "node": "4.x.x"
  "now": {
    "engines": {
      "node": "4.x.x"

How Do I Run My Build Process?

To define a script that has to be run everytime after install, specify a build script in package.json:

  "name": "my-project",
  "version": "0.1.0",
  "dependencies": {
    "gulp": "3.9.1"
  "scripts": {
    "build": "gulp",
    "start": "node index"

How Does My App Detect now?

If you want to define a specific task for now that overrides build, you can define a task called now-build. If now-build is set, build is ignored.

If you want to have a specific task for startup, you can specify now-start, and the regular start task will be ignored.

In addition, the NOW env variable is exposed to the tasks and scripts for detecting the environment. We also expose NOW_URL with the URL generated for the deployment.

Can I Host Static Websites?


Who's behind now?

The team that built now has experience deploying and running the largest Node.JS deployments.

Our first Node.JS version in production was 0.1.100, and since then we've built some of the most popular and enduring open-source modules and frameworks, such as:

  • the most popular realtime framework (35M downloads)
  • mongoose the most popular MongoDB JavaScript ODM (7M downloads)

Read more about who's behind our products here.