To follow this tutorial on your own computer, please install the
jet CLI locally first.
Using Codeship Pro, you can set environment variables in two formats: Encrypted and unsecured.
This is important because some environment variables may not need to be securely stored, but some may relate to authentication or deployment access and therefore need to be secured and never visible in your repo or configuration files.
You can set your environment variables directly in your Services file, or via your Dockerfile.
To set unsecured enviroment variables via your Services file, you will use the
environment specification. For example:
app: build: image: myorg/appname dockerfile_path: Dockerfile environment: - NAME=Codeship - URL=www.codeship.com
To set unsecured environment variables via your Dockerfile, you will use the
ENV directive. For example:
FROM ubuntu:latest ENV URL=www.codeship.com
The most common way to use environment variables on Codeship Pro is by using our
encrypted_env_file option. This lets you keep all environment variables securely encrypted, via a project-specific AES KEY, and therefore never explicitly visible in your repo.
By doing this, you never have to worry about using environment variables for passing your secrets to your CI/CD pipeline and to your builds.
If you have a project on https://codeship.com, head over to the General page of your project settings and you’ll find a section labeled AES Key which allows you to either copy or download the key.
Save that file as
codeship.aes in your repository root and don’t forget to add the key to your
.gitignore file so you don’t accidentally commit it to your repository.
To encrypt your environment variables, first create a new text file with your variables defined in it. In this case, let’s call the file
env and add some example environment variables:
Once you create this file and save it in your project directory, we’ll encrypt it. This will require that you have installed the Jet CLI and that you have downloaded your AES key to your project root, as well.
From your terminal, you will run:
jet encrypt env env.encrypted
In this example
env is the name of the text file containing your environment variables, and
env.encrypted is the name of the encrypted file.
Note that both names are customizable and up to you. Once encrypted, you also want to make sure to add your origin, plain-text
env file to your
.gitignore, or to delete it altogether.
Now that you have created your encrypted environment variables file (and added the plain-text version to your
.gitignore), you will want to use the encrypted file in your Services file. You do this using the
encrypted_env_file directive. For example:
app: build: image: myorg/appname dockerfile_path: Dockerfile encrypted_env_file: env.encrypted
If you need to decrypt the encrypted file run the following command instead
jet decrypt env.encrypted env
Just like when encrypting but in reverse,
env.encrypted is the name of the file you want to decrypt and
env is the name you give to the decrypted file.
If you want to set environment variables just for the purpose of using secrets in your Dockerfile, you will want to use build arguments. Build arguments are buildtime-only variables populated just for the purposes of being used in your Dockerfiles.
In some situations, you may find that you want to run one set of credentials locally and a different set during your Codeship builds. Or, some developers on your team may need to use different sets of credentials. There is no ideal way to resolve this issue, at the moment, although we hope to solve for it better in the future.
For the time being, there are several workarounds that may be worth investigating for your team if you have this need:
You can create another, separate version of your service in your Services file, such as
services_local , that would use a different encrypted env file. Your team would keep this alternative file locally, with their personal credentials, and it would be added to .gitignore so that it is not committed. Your Steps file would only reference your main service definition, which would use the encrypted env file that you commit. Locally with the Jet CLI, you would run
jet steps service_name command rather than just
You could keep a different encrypted env file on hand locally. From there, you would maintain local
.gitignore files so that the local credential files are not committed by individual developers and only the canonical, production encrypted environment file would be in the repo. The developers would then need to override the pulled encrypted enviroment variables file with their own, but it would be ignored on all commits back to the repo because of the
Your team could also maintain branches just for local development, and these branches would not have any environment variables file committed on them. Developers could then maintain a local env file that is never committed, with the main branches continuing to host a primary, encrypted environment variables file.