Getting started with Wercker and Javascript

This guide is a step-by-step approach to developing, building and deploying a sample app with Wercker within minutes.

While this guide uses Javascript, the general concepts explained in this tutorial apply to every other programming language.


To be able to follow along with this guide, you will need the following things:

  • A Wercker account
  • The Wercker CLI

Setting up the app

Before we can start developing, we have to fork and clone the sample app into our local development environment. After you’ve done that, cd into the project directory:

$ cd getting-started-nodejs/

Next, assuming you have Node installed locally, you can simply launch the sample app:

$ node app.js

Now in your browser navigate to localhost:8080 and you should be presented with the following json:

{"cities":["Amsterdam","Berlin","New York","San Francisco","Tokyo"]}

Developing the app

Now that we’ve setup our app we can start developing. Our list of cities is a bit short, so why not add another one in there? Before we do that however, let’s first take a look at the wercker.yml file included in your project folder.


The wercker.yml is the only config file you need for using wercker. In it, you will define all your steps needed to successfully develop, build and deploy your application. To get started, we’re only interested in developing our app. Take a look at the top of the file:

# The container definition we want to use for developing our app
  id: node:latest
    - "8080"

The initial box section defines two things. The id property states which container image you want to use for your project; as we’re developing with NodeJS in this sample we’re using the node:latest image. These container images are retrieved from Docker Hub if no other registry is specified. You can read more about containers here. The ports property specifies the ports that you want your running container to open. This example only requires a single port but you can specify multiple ports here.

Now let’s look at the dev section:

# Defining the dev pipeline
    - npm-install
    - internal/watch:
        code: node app.js
        reload: true

In the dev pipeline clause we define what we want to happen in our development pipeline, which in this case consists of two steps: npm-install and internal/watch. The first of these, npm-install, is a wercker step that, unsurprisingly, runs npm-install. The internal/watch step watches your files for changes, and if reload is set to true it restarts your app so your changes are reflected immediately. This is especially useful for when you’re developing webapps, as we’re doing now. Both of these steps are pre-written bash scripts written by either wercker or the community. You can read more about steps here.

Let’s see these steps in action now and fire up our dev pipeline.

Wercker dev

In your project folder, run wercker dev –expose-ports. You should see something similar to the following output:

--> Executing pipeline
--> Running step: setup environment
Pulling from library/node: latest
Digest: sha256:a8918e06476bef51ab83991aea7c199bb50bfb131668c9739e6aa7984da1c1f6
Status: Image is up to date for node:latest
--> Copying source to container
--> Running step: wercker-init
--> Running step: npm-install
Using wercker cache
Creating $WERCKER_CACHE_DIR/wercker/npm
Configuring npm to use wercker cache
npm info it worked if it ends with ok
npm info using npm@5.3.0
npm info using node@v8.6.0
npm info config set "cache" "/pipeline/cache/wercker/npm"
npm info ok
Starting npm install, try: 1
npm info it worked if it ends with ok
npm info using npm@5.3.0
npm info using node@v8.6.0
npm info lifecycle getting-started-nodejs@0.0.1~preinstall: getting-started-nodejs@0.0.1
npm info linkStuff getting-started-nodejs@0.0.1
npm info lifecycle getting-started-nodejs@0.0.1~install: getting-started-nodejs@0.0.1
npm info lifecycle getting-started-nodejs@0.0.1~postinstall: getting-started-nodejs@0.0.1
npm info lifecycle getting-started-nodejs@0.0.1~prepublish: getting-started-nodejs@0.0.1
npm info lifecycle getting-started-nodejs@0.0.1~prepare: getting-started-nodejs@0.0.1
npm info lifecycle undefined~preshrinkwrap: undefined
npm info lifecycle undefined~shrinkwrap: undefined
npm info lifecycle undefined~postshrinkwrap: undefined
npm WARN getting-started-nodejs@0.0.1 No repository field.
npm WARN getting-started-nodejs@0.0.1 No license field.

up to date in 5.425s
npm info ok
Finished npm install
--> Running step: watch
--> Reloading on file changes
--> Reloading

Wercker first checks out your code and then sets up the container environment. This means that the container will be pulled from Docker Hub and subsequently started with access to your checked out code. It will then start executing all the steps that are defined in the wercker.yml.

If you navigate once again to localhost:8080 you should see the same output as before. That’s not very exciting, so let’s see our live reloading in action. In app.js:3 add a new city to the array:

var cities = {"cities":["Amsterdam","Berlin","New York","San Francisco","Tokyo","London"]};

Once you save your changes, the app should automatically reload. If you refresh your page, our new city should be there! Hurrah!

There are many more steps to use for developing your app. Take a look around, and if you can’t find the step you’re looking for, you can always make your own.

Now that we’re done developing, we want to push our changes and let wercker build and deploy our app for us.

Building your app

First, let’s revisit our wercker.yml again.

 id: node:latest
   - "8080"

    - npm-install
    - internal/watch:
        code: node app.js
        reload: true

# Build definition
  # The steps that will be executed on build
    - script:
        code: export NODE_ENV='testing'
    # A step that executes `npm install` command
    - npm-install
    # A step that executes `npm test` command
    - npm-test

    # A custom script step, name value is used in the UI
    # and the code value contains the command that get executed
    - script:
        name: echo nodejs information
        code: |
          echo "node version $(node -v) running"
          echo "npm version $(npm -v) running"

Build Pipeline

We’re now interested in what’s happening the build pipeline, where we’ve added a new kind of step: a script step. This script step is a piece of inline bash code which we’re using to run our tests. You can create and share these kind of steps with the community by submitting a step to our repository.

Wercker build

Now that we have a better understanding of our wercker.yml let’s go ahead and let wercker build our project. In your project folder, first run rm -r node_modules, and then wercker build:

$ wercker build
--> Executing pipeline
--> Running step: setup environment
Pulling repository nodesource/trusty
Pulling image (latest) from nodesource/trusty: 1a464bde82b1
Pulling image (latest) from nodesource/trusty, endpoint: 1a464bde82b1
Pulling dependent layers: 1a464bde82b1
Download complete: 428b411c28f0
Download complete: bfe5eacf5a79
Download complete: 1a464bde82b1
Download complete: 1a464bde82b1
Status: Image is up to date for nodesource/trusty:latest
--> Running step: wercker-init
--> Running step: script
--> Running step: npm-install
Starting npm install, try: 1
npm WARN package.json getting-started-nodejs@0.0.1 No repository field.
supertest@0.4.0 node_modules/supertest
├── methods@0.0.1
└── superagent@0.9.5 (cookiejar@1.3.0, emitter-component@0.0.5, qs@0.4.2, mime@1.2.5, formidable@1.0.9)

mocha@1.6.0 node_modules/mocha
├── growl@1.5.1
├── commander@0.6.1
├── diff@1.0.2
├── mkdirp@0.3.3
├── debug@2.2.0 (ms@0.7.1)
├── ms@0.3.0
└── jade@0.26.3 (mkdirp@0.3.0)

express@3.21.0 node_modules/express
├── escape-html@1.0.2
├── merge-descriptors@1.0.0
├── cookie@0.1.3
├── utils-merge@1.0.0
├── cookie-signature@1.0.6
├── methods@1.1.1
├── fresh@0.3.0
├── basic-auth@1.0.2
├── range-parser@1.0.2
├── content-type@1.0.1
├── etag@1.7.0
├── vary@1.0.0
├── parseurl@1.3.0
├── content-disposition@0.5.0
├── commander@2.6.0
├── depd@1.0.1
├── debug@2.2.0 (ms@0.7.1)
├── proxy-addr@1.0.8 (forwarded@0.1.0, ipaddr.js@1.0.1)
├── mkdirp@0.5.1 (minimist@0.0.8)
├── send@0.13.0 (destroy@1.0.3, ms@0.7.1, statuses@1.2.1, mime@1.3.4, http-errors@1.3.1, on-finished@2.3.0)
└── connect@2.30.0 (bytes@2.1.0, pause@0.0.1, vhost@3.0.0, on-headers@1.0.0, basic-auth-connect@1.0.0, response-time@2.3.1, method-override@2.3.3, cookie-parser@1.3.5, serve-static@1.10.0, http-errors@1.3.1, connect-timeout@1.6.2, qs@2.4.2, serve-favicon@2.3.0, morgan@1.6.0, finalhandler@0.4.0, multiparty@3.3.2, csurf@1.8.3, express-session@1.11.3, body-parser@1.13.1, errorhandler@1.4.0, serve-index@1.7.0, type-is@1.6.3, compression@1.5.0)

nodeunit@0.7.4 node_modules/nodeunit
└── tap@1.2.0 (opener@1.4.1, foreground-child@1.2.0, supports-color@1.3.1, buffer-equal@0.0.1, deep-equal@1.0.0, signal-exit@2.1.2, mkdirp@0.5.1, readable-stream@1.1.13, tap-mocha-reporter@0.0.14, tap-parser@1.1.6, glob@5.0.10, coveralls@2.11.2, nyc@2.3.0, js-yaml@3.3.1)
Finished npm install
--> Running step: echo nodejs information
node version v0.10.38 running
npm version 1.4.28 running
--> Steps passed
--> Pipeline finished

Building locally is very useful when you’re not sure your code will run because of some changes you made. As such you don’t want to push these changes to your Git provider just yet.

But since we’ve verified that our app is compiling and running correctly, it’s time to let wercker build & deploy your app in the cloud, which is what we’ll be doing in the next section.

Adding your app to Wercker

The next step is to create a new application on wercker. Head over to and select Add application from the top menu bar.

Select the Owner and Git Provider

First we have to choose who owns the app. For this tutorial, go ahead and select yourself. If you prefer, you can select an organization you created on wercker.

Now select GitHub as your Git provider (BitBucket and GitLab are also available), and then click Next.

Select the repository

You now see a list of your existing repositories. Select theNodeJS example you forked earlier from the list and click Next.

Configure Access

The next step is about configuring access, and the first option wercker will check out the code without using an SSH key is fine for the purpose of this tutorial, because it’s an open source and public application. So go ahead and click Next.

Review application details

Finally, once you’ve verified all the settings, click Create to complete setting up our app. Now you can trigger the first build!

Triggering your first build

The Nicely Done! screen gives you the option to generate a wercker.yml file. But as the repository already contains one, all you have to do is click trigger a build now .

The Runs page now shows a new build has been triggered! This build will do the exact same as the one you triggered locally but now everyone in your team can see and comment on the build.

Wrapping up

Congratulations! You’ve built your first app using Wercker.