Official set of deploy tasks for Shipit.
Last updated 6 months ago by neoziro .
MIT · Repository · Original npm · Tarball · package.json
$ cnpm install shipit-deploy 
SYNC missed versions from official npm registry.


Build Status version MIT License

Set of deployment tasks for Shipit.


  • Deploy tag, branch or commit
  • Add additional behaviour using hooks
  • Build your project locally or remotely
  • Easy rollback


npm install shipit-deploy

If you are deploying from Windows, you may want to have a look at the wiki page about usage in Windows.


Example shipitfile.js

module.exports = shipit => {

    default: {
      workspace: '/tmp/myapp',
      deployTo: '/var/myapp',
      repositoryUrl: '',
      ignores: ['.git', 'node_modules'],
      keepReleases: 2,
      keepWorkspace: false, // should we remove workspace dir after deploy?
      deleteOnRollback: false,
      key: '/path/to/key',
      shallowClone: true,
      deploy: {
        remoteCopy: {
          copyAsDir: false, // Should we copy as the dir (true) or the content of the dir (false)
    staging: {
      servers: '',

To deploy on staging, you must use the following command :

shipit staging deploy

You can rollback to the previous releases with the command :

shipit staging rollback



Type: String

Define a path to a directory where Shipit builds it's syncing source.

Beware to not set this path to the root of your repository (unless you are set keepWorkspace: true) as shipit-deploy cleans the directory at the given path after successful deploy.

Here you have the following setup possibilities:

  • if you want to build and deploy from the directory with your repo:
    • set keepWorkspace: true so that your workspace dir won't be removed after deploy
    • optionally set rsyncFrom if you want to sync e.g. only ./build dir
    • set branch so that we can get correct revision hash
  • if you want every time to fetch a fresh repo copy and dun reploy on it:
    • set shallowClone: true — this will speed up repo fetch speed and create a temporary workspace. NOTE: if you decide not to use shallowClone, you should set workspace path manually. If you set shallowClone: true, then the temporary workspace directory will be removed after deploy (unless you set keepWorkspace: true)
    • set repositoryUrl and optionally branch and gitConfig


Type: Boolean

If true — we won't remove workspace dir after deploy.


Type: String Default: same as workspace

Define directory within the workspace which should be deployed.


Type: String

Define the remote path where the project will be deployed. A directory releases is automatically created. A symlink current is linked to the current release.


Type: String

Git URL of the project repository.

If empty Shipit will try to deploy without pulling the changes.

In edge cases like quick PoC projects without a repository or a living on the edge production patch applying this can be helpful.


Type: String

Tag, branch or commit to deploy.


Type: Array<String>

An array of paths that match ignored files. These paths are used in the rsync command.


Type: Boolean

Whether or not to delete the old release when rolling back to a previous release.


Type: String

Path to SSH key


Type: Number

Number of releases to keep on the remote server.


Type: Boolean

Perform a shallow clone. Default: false.


Type: Boolean

Update submodules. Default: false.


type: Object

Custom git configuration settings for the cloned repo.


Type: String

Log format to pass to git log. Used to display revision diffs in pending task. Default: %h: %s - %an.


Type: String Optional

When deploying from Windows, prepend the workspace path with the drive letter. For example /d/tmp/workspace if your workspace is located in d:\tmp\workspace. By default, it will run rsync from the workspace folder.


Type: String

Parameter to pass to cp to copy the previous release. Non NTFS filesystems support -r. Default: -a


Type: Boolean Optional

If true - We will copy the folder instead of the content of the folder. Default: false.


Several variables are attached during the deploy and the rollback process:


All options described in the config sections are available in the shipit.config object.


Attached during deploy:fetch task.

You can manipulate the repository using git command, the API is describe in gift.


Attached during deploy:update and rollback:init task.

The current release dirname of the project, the format used is "YYYYMMDDHHmmss" (moment format).


Attached during deploy:init, rollback:init, and pending:log tasks.

The remote releases path.


Attached during deploy:update and rollback:init task.

The complete release path : path.join(shipit.releasesPath, shipit.releaseDirname).


Attached during deploy:init, rollback:init, and pending:log tasks.

The current symlink path : path.join(shipit.config.deployTo, 'current').

Workflow tasks

  • deploy
    • deploy:init
      • Emit event "deploy".
    • deploy:fetch
      • Create workspace.
      • Initialize repository.
      • Add remote.
      • Fetch repository.
      • Checkout commit-ish.
      • Merge remote branch in local branch.
      • Emit event "fetched".
    • deploy:update
      • Create and define release path.
      • Remote copy project.
      • Emit event "updated".
    • deploy:publish
      • Update symlink.
      • Emit event "published".
    • deploy:clean
      • Remove old releases.
      • Emit event "cleaned".
    • deploy:finish
      • Emit event "deployed".
  • rollback
    • rollback:init
      • Define release path.
      • Emit event "rollback".
    • deploy:publish
      • Update symlink.
      • Emit event "published".
    • deploy:clean
      • Remove old releases.
      • Emit event "cleaned".
    • rollback:finish
      • Emit event "rollbacked".
  • pending
    • pending:log
      • Log pending commits (diff between HEAD and currently deployed revision) to console.



Current Tags

  • 5.3.0                                ...           latest (6 months ago)

26 Versions

  • 5.3.0                                ...           6 months ago
  • 5.2.0                                ...           7 months ago
  • 5.1.0                                ...           a year ago
  • 5.0.0                                ...           a year ago
  • 4.1.4                                ...           2 years ago
  • 4.1.3                                ...           2 years ago
  • 4.1.2                                ...           2 years ago
  • 4.1.1                                ...           2 years ago
  • 4.1.0                                ...           2 years ago
  • 4.0.2                                ...           3 years ago
  • 4.0.0                                ...           3 years ago
  • 2.5.1                                ...           3 years ago
  • 2.5.0                                ...           3 years ago
  • 2.4.0                                ...           4 years ago
  • 2.3.0                                ...           4 years ago
  • 2.2.0                                ...           4 years ago
  • 2.1.3                                ...           5 years ago
  • 2.1.2                                ...           5 years ago
  • 2.1.1                                ...           5 years ago
  • 2.0.0                                ...           5 years ago
  • 1.3.1                                ...           5 years ago
  • 1.3.0                                ...           5 years ago
  • 1.2.0                                ...           6 years ago
  • 1.1.1                                ...           6 years ago
  • 1.1.0                                ...           6 years ago
  • 1.0.0                                ...           6 years ago
Maintainers (2)
Today 0
This Week 80
This Month 278
Last Day 30
Last Week 80
Last Month 260
Dependencies (7)
Dev Dependencies (0)

Copyright 2014 - 2016 © |