This article is about Codeship Pro.

Using The Local CLI

You'll need roughly 7 minutes to read this article.

This article is about the local CLI tool that you can use to test and debug your Codeship Pro builds and configuration files as well as to encrypt your environment variables and build arguments.

If you are unfamiliar with Codeship Pro, we recommend our getting started guide or the features overview page.

Note that if you are using Codeship Basic, you will not be able to use the local CLI.

What is Jet?

Jet is a CLI tool designed to make working with Codeship Pro faster and easier, as well as to put more power in a developer’s hands so that there is less time spent configuring and debugging projects via a web UI.


In order to run the Jet binary on your computer, you need to have Docker installed and configured, with a running Docker host such as Docker For Mac.

Installing Jet

Please follow the steps below for the operating system you are using. See the Jet Release Notes for the ChangeLog.

See the sha256sums file for checksums for the latest release. To check the downloaded files on Linux / Unix based systems run the following command.

shasum -c -a 256 sha256sums

Installing Jet On Mac OS X

The jet CLI is now included in our custom Homebrew Cask. If you already have Homebrew installed you can install jet by running the following command

brew cask install codeship/taps/jet

# If you already have the CLI installed and want to update to the latest version
brew update
brew cask reinstall codeship/taps/jet

If you don’t have Homebrew installed or don’t use Homebrew Cask you can install jet via the following commands.

curl -SLO ""
tar -xC /usr/local/bin/ -f jet-darwin_amd64_2.1.0.tar.gz
chmod u+x /usr/local/bin/jet

Installing Jet On Linux

curl -SLO ""
sudo tar -xaC /usr/local/bin -f jet-linux_amd64_2.1.0.tar.gz
sudo chmod +x /usr/local/bin/jet

Installing Jet On Windows

There is no supported Jet version for Windows machines, although Windows Subsystem For Linux works for many of our customers.

Dynamically linked version

The above version is statically linked and will work the same way on all platforms. But it doesn’t support certain features, e.g. resolving .local DNS names. If your builds require this, please use the dynamically linked version instead.

Validating Installation

Once this is done you can check that Jet is working by running jet help. This will print output similar to the following.

$ jet version
$ jet help
  jet [command]

Docker Configuration

DOCKER_HOST must be set. DOCKER_TLS_VERIFY and DOCKER_CERT_PATH are respected in the same way as with the official Docker client. If you installed Docker via Docker For Mac this is typically done by default during installation.

If you installed and configured your Docker environment via Docker Machine (and you are on OS X or Linux) and named the environment dev, running the following command will set those variables.

eval $(docker-machine env dev)

Using Jet

Now that you have Jet installed and configured, learn how to use it.

Jet Steps

The most often used feature of Jet is jet steps.

By running jet steps, you are running your full CI/CD process on your local machine. This lets you test your builds, configuration files and pipelines locally without having to commit your code.

Note that jet steps skips image pushes and any branch-specific commands by default, but you can always run jet steps --help to see a list of special options you can pass Jet to invoke different CI/CD contexts and behaviors.

Jet Encrypt

Jet also allows you to encrypt environment variables, build arguments and registry credentials. This is done with the jet encrypt command. Click the links in this paragraph for specific instructions on encrypting different types of secrets.

Jet Run

While jet steps runs your CI/CD pipeline locally, you can also use jet run to instead build a single service or run a single command.

For instance, you can run jet run service_app or jet run service_app echo "hello" where service_app is one of the services defined in your codeship-services.yml.

Note that you can also run jet run --help to see a list of special options you can pass Jet to invoke different CI/CD contexts and behaviors.

Jet Cleanup

With jet cleanup you can be sure that Jet removes any leftover containers, networks and all other Docker build artifacts of your local build run.

Typically, cleanup happens by default but the jet cleanup command allows you to invoke it manually if there are any issues that prevent Jet from completing.

Jet Validate

The jet validate command will confirm that your codeship-services.yml and codeship-steps.yml are valid and ready to be used. If there are any configuration issues with your files, the jet validate command will let you know what to address.

Debugging Your Builds

While Codeship Pro does not offer SSH access to build machines for debugging like Codeship Basic does, you can debug your builds locally in a similar way using jet. You will just need to use jet run, as seen above, and then connect to your running containers to manually run the commands from your codeship-steps.yml file.

To do this, you will need to execute the following commands:

docker ps -a
docker exec CONTAINERID

Note that you are running your containers, looking up the container ID and then connecting to the running container using the container ID.

Common Issues

There are several common issues that you may experience when using the Jet CLI:

  • The --no-cache flag is deprecated as-is and currently does not work locally. You will need to manually delete images and re-run jet steps to force new images to build.

  • No AES key provided - this error occurs when the Jet CLI can not find an AES key during encryption or decryption. Note that the key file can be found in your Project Settings, must be in the same directory you are running jet encrypt from and must be named codeship.aes.

  • Sometimes a build will fail on Codeship and pass locally, or vice versa. A good first step is to delete your locally saved Docker images and re-run jet steps. On remote builds, we have to build the images every time, whereas locally by default Docker will use existing images when it can. This means that the images jet is running against locally may not be the same, up to date images being used remotely. By deleting your saved images, you are forcing the images to be rebuilt and thus increase parity between local and remote builds.