---
title: "Migrate from Travis CI"
description: "An overview of how to migrate from Travis CI to CircleCI."
doc_version: "unversioned"
last_updated: "2026-04-24"
---

> For the complete documentation index, see [llms.txt](https://circleci.com/docs/llms.txt)

# Migrate from Travis CI

This document provides an overview of how to migrate from Travis CI to CircleCI.

The example build configurations referenced throughout this article are based on this [example JavaScript repository](https://github.com/CircleCI-Public/circleci-demo-javascript-express/blob/master/.circleci/config.yml).

## Prerequisites

This document assumes that:

*   You have an account with CircleCI that is linked to a repository. If you do not have an account, consider reading our [Getting Started Guide](https://circleci.com/docs/guides/getting-started/getting-started/).
    
*   You understand the [Basic Concepts](https://circleci.com/docs/guides/about-circleci/concepts/) in CircleCI.
    

## Why migrate to CircleCI?

*   **Scaling Concurrency**: You can run up to 80 concurrent jobs on our monthly Performance Plan or even more on a [Custom Plan](https://circleci.com/pricing/). Travis CI has capped concurrencies of 1, 2, 5, and 10 on each of their plans.
    
*   **Resource Classes**: [vCPU and RAM](https://circleci.com/docs/reference/configuration-reference/#resourceclass) are configurable within CircleCI jobs to strategically speed up builds and spend credits, whereas these values are fixed on Travis CI.
    
*   **Parallelization by Timing**: On top of running many jobs concurrently, CircleCI offers built-in [Test Splitting](https://circleci.com/docs/guides/optimize/parallelism-faster-jobs/) across multiple environments by timing. This dramatically reduces wall clock time for large test suites to finish. You must implement this manually in Travis CI.
    
*   **Orbs**: Rather than proprietary integrations, CircleCI offers [Orbs](https://circleci.com/docs/orbs/use/orb-intro/), which are reusable, templated configuration. On top of connecting to services and tools, orbs can be used to standardize and templatize configuration for your team and organization as well. [Visit the registry](https://circleci.com/developer/orbs).
    

## Configuration files

Both Travis CI and CircleCI make use of a _configuration file_ to define your workflows and jobs. The only difference is that your CircleCI configuration will live in `.circleci/config.yml` at the root of your repository.

Below, you’ll find a side-by-side comparison of different configuration declarations.

| Travis CI | CircleCI | Description |
| --- | --- | --- |
| `language:`<br>`os:` | [`docker`, `machine`, `macos`, `windows`](https://circleci.com/docs/guides/execution-managed/executor-intro/) | CircleCI doesn’t assume dependencies or commands based on a language; instead, choose an executor and use `run:` steps as shown below to execute commands you require (for example, install, build, test). |
| `dist:` | [Machine](https://circleci.com/docs/reference/configuration-reference/#machine) | Our Linux VM executor is a Ubuntu VM. You can specify [Versions](https://circleci.com/docs/reference/configuration-reference/#available-linux-machine-images-cloud) in the config. |
| `cache:` | [`restore_cache`](https://circleci.com/docs/reference/configuration-reference/#restorecache), [`save_cache`](https://circleci.com/docs/reference/configuration-reference/#restorecache) | Use the restore and save cache features to control caching in the builds. |
| `before_cache` | [`run`](https://circleci.com/docs/reference/configuration-reference/#run) | If you want to run any commands before you cache, place a run: step before your cache step(s) in CircleCI. |
| `before_install:` | [`run`](https://circleci.com/docs/reference/configuration-reference/#run) | CircleCI doesn’t separate commands into stages or types. Use `run:` steps to specify any commands and order them per your needs. See [Documentation](https://circleci.com/docs/reference/configuration-reference/#the-when-attribute) for usage of conditional steps. |
| `install:` | [`run`](https://circleci.com/docs/reference/configuration-reference/#run) | (see above) |
| `before_script` | [`run`](https://circleci.com/docs/reference/configuration-reference/#run) | (see above) |
| `script:` | [`run`](https://circleci.com/docs/reference/configuration-reference/#run) | (see above) |
| `after_script:` | [`run`](https://circleci.com/docs/reference/configuration-reference/#run) | (see above) |
| `deploy:` | [`run`](https://circleci.com/docs/reference/configuration-reference/#run) | Use a `run` step to run needed commands for deployment. See our [Deployment Overview Page](https://circleci.com/docs/guides/deploy/deployment-overview/) for links to examples. |
| `env:` | [`environment`](https://circleci.com/docs/reference/configuration-reference/#environment) | Use the `environment` element to specify environment variables. |
| `matrix:` | [`matrix`](https://circleci.com/docs/reference/configuration-reference/#matrix) | CircleCI also offers matrix syntax under our workflows configuration. |
| `stage:` | [`requires`](https://circleci.com/docs/reference/configuration-reference/#requires) | Use the requires: element to define job dependencies and control concurrent jobs in workflows. |

## Building on pushing code

The example repository linked above is a basic application for creating, reading, updating, and deleting articles. The app is built with the `MERN` stack. Tests are present on the client as well as the REST API that run whenever code is pushed.

To get tests running for this example repository, the beginnings of a simple Travis Configuration might look like the following example:

```yaml
language: node_js
services: mongodb
before_install:
  - npm i -g npm@5
node_js:
  - "5"
cache: npm
```

For basic builds, a Travis CI configuration will leverage a language’s best known dependency and build tools. It will abstract them away as default commands (which can be overridden) in [a job lifecycle](https://docs.travis-ci.com/user/job-lifecycle/#the-job-lifecycle). In this case, when the build runs, Travis CI will automatically run `npm install` for the `install` step, and run `npm start` for the `script` step.

If a user needs more control with their CI environment, Travis CI uses _hooks_ to run commands before/after the `install` and `script` steps. In the example above, a "before hook" is used to specify that the npm version be pinned to `5`. Hooks can execute shell scripts as well, which users will sometimes store in a `.travis` folder at the root of their repository.

The following CircleCI configuration to achieve the same results is excerpted from the example repository:

**Using Docker?** Authenticating Docker pulls from image registries is recommended when using the Docker execution environment. Authenticated pulls allow access to private Docker images, and may also grant higher rate limits, depending on your registry provider. For further information, see [Using Docker Authenticated Pulls](https://circleci.com/docs/guides/execution-managed/private-images/).

```yaml
version: 2.1

workflows:
  build:
    jobs:
      - build

jobs:
  build:
    working_directory: ~/mern-starter
    docker:
      - image: cimg/node:17.2.0 # Primary execution image
      - image: mongo:3.4.4         # Service/dependency image
    steps:
      - checkout
      - run:
          name: update-npm
          command: 'sudo npm install -g npm@5'
      - restore_cache:
          key: dependency-cache-{{ checksum "package-lock.json" }}
      - run:
          name: install-npm
          command: npm install
      - save_cache:
          key: dependency-cache-{{ checksum "package-lock.json" }}
          paths:
            - ./node_modules
      - run:
          name: test
          command: npm test
```

In the config above, no _language_ is specifically required, and the user is able to specify any number of `steps` that can be run, with no restrictions on step order. By leveraging Docker, specific Node.js and MongoDB versions are made available in each `command` that gets run.

### Caching dependencies

With CircleCI you have control over when and how your config caches and restore dependencies. In the above example, the CircleCI `.circleci/config.yml` checks for a dependency cache based specifically on a checksum of the `package-lock.json` file. You can set your cache based on any key (not just `package-lock.json`) as well as set a group of cache paths to defer to in the declared order. Refer to the [caching dependencies document](https://circleci.com/docs/guides/optimize/caching/) to learn about customizing how your build creates and restores caches.

In a Travis Configuration, [dependency caching](https://docs.travis-ci.com/user/caching/) occurs in your build after the `script` phase and is tied to the language you are using. In our case, by using the `cache: npm` key in `.travis.yml`, dependencies will default to caching `node_modules`.

## Environment variables

Both Travis and CircleCI enable the use of environment variables in your builds.

In your CircleCI `.circleci/config.yml` you can put environment variables directly in your build config in a step, a job, or a container. These variables are public and unencrypted. With Travis CI, it is possible to include [encrypted environment](https://docs.travis-ci.com/user/environment-variables#defining-encrypted-variables-in-travisyml) variables directly in your config (if you install the `travis` gem).

### Setting environment variables in the web application

If you have used the Travis CI [repository settings](https://docs.travis-ci.com/user/environment-variables#defining-variables-in-repository-settings), you’ll be comfortable setting your environment variables in CircleCI’s project settings page. Read the docs for setting environment variable in a [single project](https://circleci.com/docs/guides/security/set-environment-variable/#set-an-environment-variable-in-a-project).

With CircleCI, it is also possible to securely set environment variables across _all_ projects using [Contexts](https://circleci.com/docs/guides/security/contexts/).

In addition, CircleCI has several [Built-in Environment Variables](https://circleci.com/docs/reference/variables/#built-in-environment-variables).

## Artifacts uploading

With Travis CI you can upload build artifacts either manually using AWS S3 or as an attachment to a GitHub Release.

On CircleCI, artifact uploading occurs in a step in your config:

```yaml
      - run:
          name: test
          command: npm test
      - run:
          name: code-coverage
          command: './node_modules/.bin/nyc report --reporter=text-lcov'
      - store_artifacts: # < stores test-results.xml, available in the web app or through the api.
          path: test-results.xml
          prefix: tests
      - store_artifacts:
          path: coverage
          prefix: coverage
      - store_test_results:
          path: test-results.xml
```

After an artifact is successfully uploaded, you can view it in the Artifacts tab of the Job page in your browser, or access them through the CircleCI API. Read the documentation on [Artifact Uploading](https://circleci.com/docs/guides/optimize/artifacts/) to learn more.

## Advanced tooling

More advanced configuration on Travis might make use of a _Build Matrix_ (a configuration that specifies running multiple concurrent jobs). It might also use _Build Stages_ (grouping jobs into stages that can run concurrently or sequentially based on previous job success).

With CircleCI you can use [Workflows](https://circleci.com/docs/guides/orchestrate/workflows/) in your `.circleci/config.yml` to define a collection of jobs and their run order. This includes leveraging concurrency, fan-in or fan-out builds, or sequentially-dependant builds. Workflows allow complex and fine-grained control over your build configuration.