Build Environment Overview
What This Guide Covers #
This guide provides an overview on the different environments in which Travis CI can run your builds, and why you might want to pick one over another.
Virtualization environments #
Each build runs in one of the following virtual environments.
Travis CI supports two virtualization types for Linux builds: ‘full VM’ and ‘LXD’. On top of that, Linux builds can be run on multiple CPU architectures.
Full VM #
This is sudo enabled, full virtual machine per build, that runs Linux
- Slow spin-up (increased build time compared to LXD container) yet without any limitations.
- It has a fixed amount of vCPUs and RAM assigned.
LXD container #
This is sudo enabled LXD container build environment, as close to a virtual machine as you can get in containers world. A Linux environment is run within an unprivileged LXD container.
- Fast spin-up (decreased build time when compared to full VM) yet some limitations do apply
- It starts with min 2 vCPUs and if there is more computing time available, the host can dynamically assign it to speed up your build
Which one do I use? #
For the majority of cases, whenever available, we recommend to use LXD-based containers.
Use full VM only if LXD is not available or you need
- privileged fs access
- specific system call interception
- hugepages support (subject to changes on short notice)
The table below sums up the available Ubuntu environments and virtualization type per CPU architecture:
|Ubuntu version||Linux Virtualization Type|
|Ubuntu Focal 20.04||
|Ubuntu Bionic 18.04||
|Ubuntu Xenial 16.04 default||
|Ubuntu Trusty 14.04||
|Ubuntu Precise 12.04||
You can select Linux virtualization type by setting a
virt tag to either
lxd. See relevant
.travis.yml examples below.
A macOS environment for Objective-C and other macOS specific projects
A Windows environment running Windows Server, version 1803.
Virtualisation Environment vs Operating System #
The following table summarizes the differences across virtual environments and operating systems:
|Ubuntu Linux (Focal, Bionic, Xenial , Trusty, Precise)||macOS||Windows||Ubuntu Linux / LXD container (Focal, Bionic, Xenial)|
|Infrastructure||Virtual machine on GCE or AWS||Virtual machine||Virtual machine on GCE||ARM: LXD container on Packet or AWS
IBM Power: LXD container on IBM Cloud
IBM Z: LXD container on IBM Cloud
ppc64le (IBM Power)
s390x (IBM Z)
|Approx boot time||20-50s||60-90s||60-120s||<10s|
|Operating system||Ubuntu Linux||macOS||Windows Server 2016||Ubuntu Linux|
|Memory||7.5 GB||4 GB||8 GB||~4 GB|
|IPv4 network||IPv4 is available||IPv4 is available||IPv4 is available||IPv4 is available|
|IPv6 network||IPv6 is not available||IPv6 is not available||IPv6 is not available||IPv6 is available|
|Available disk space||approx 50GB||approx 41GB||approx 40 GB||approx 18GB (Arm, IBM Power, IBM Z)|
Available disk space is approximate and depends on the base image and language selection of your project. The best way to find out what is available on your specific image is to run
df -has part of your build script.
What infrastructure is my environment running on? #
Usually, knowing the virtualization environment characteristics from the table above is sufficient.
But, if you do need more detail, you have one of these two questions:
- you want to see what infrastructure a finished build ran on.
- you want to determine what infrastructure a particular
.travis.ymlconfiguration will run on.
For a finished build #
To see what infrastructure a finished build ran on, look at the hostname at the top of the build log:
if it contains:
aws→ the build ran on Amazon Web Services (AWS).
gce→ the build ran in a virtual machine on Google Compute Engine.
wjb→ the build ran on macOS.
1803-containers→ the build ran on Windows.
lxd-arm64→ the build ran within an LXD container on Arm64-based infrastructure (currently delivered by Equinix Metal, formerly known as Packet)
lxd-ppc64le→ the build ran within an LXD container on Power-based infrastructure (currently delivered by IBM)
lxd-s390x→ the build ran within an LXD container on Z-based infrastructure (currently delivered by IBM)
If instance, right under the hostname contains
ec2 → the build ran within an LXD container or as a ‘full VM’ on AWS Arm64 Graviton2 infrastructure
For a particular .travis.yml configuration #
Our default infrastructure is an Ubuntu Linux (
os: linux) virtual machine running on AMD64 architecture (
arch: amd64), on Google Compute Engine. You can specify which version of Ubuntu using the
os: osx, setting a version of Xcode using
osx_image:, or using a macOS specific language such as
language: objective-croutes your build to macOS infrastructure.
os: windowsroutes your build to Windows infrastructure.
arch: arm64routes your build to Arm-based LXD containers. You can specify which version of Ubuntu using the
arch: arm64-graviton2routs your build to Arm-based infrastructure. You must specify target virtualization environment (virtual machine or LXD container) using
arch: ppc64leroutes your build to IBM Power-based LXD containers. You can specify which version of Ubuntu using the
arch: s390xroutes your build to IBM Z-based LXD containers. You can specify which version of Ubuntu using the
arch: arm64-graviton2routes you to the AWS environment powered by Arm64 Graviton2 CPUs. Available Ubuntu versions depend on the virtualization type (lxd/vm).
If you have set
os:key to target Linux environment, you can further specify the environment type using the
To avoid mistreated keys you can validate your
.travis.ymlfile using the Build Config Validation.
Partner Queue Solution #
With the introduction of a new billing system in Travis CI, the IBM and part of the ARM64 infrastructures are kept available free of charge for OSS as a part of the Partner Queue Solution. For more details see Billing Overview - Usage based Plans - Credits.
Linux: .travis.yml examples #
The AMD64 builds #
arch: amd64 # optional, this is default, routes to a full VM os: linux # optional, this is default dist: focal # or bionic | xenial | trusty | precise with xenial as default
The Arm64 builds #
arch: arm64 # LXD container based build for OSS only os: linux # required for arch different than amd64 dist: focal # or bionic | xenial with xenial as default
arch: arm64-graviton2 # in AWS over Graviton2 CPU virt: lxd # required, routes to an LXD container os: linux # required for arch different than amd64 dist: focal # or bionic | xenial with xenial as default group: edge
arch: arm64-graviton2 # in AWS over Graviton2 CPU virt: vm # required, routes to a 'full VM' instance os: linux # required for arch different than amd64 dist: focal group: edge
The IBM Power and Z builds #
arch: ppc64le # The IBM Power LXD container based build for OSS only os: linux # required for arch different than amd64 dist: focal # or bionic | xenial with xenial as default
arch: s390x # The IBM Z LXD container based build for OSS only os: linux # required for arch different than amd64 dist: focal # or bionic | xenial with xenial as default
Linux: Security and LXD Container #
These limitations are not applicable if your builds are run on
virt: vm(virtual machine) environment. However, please note that VMs start slower and have fixed computing power assigned compared to containers (LXD).
Access to Privileged fs/Features (Apparmor) #
Due to security reasons, builds run in LXD containers will be denied access to privileged filesystems and paths - a privileged container with write access to e.g. /sys/kernel/debugfs might muddle an LXD host.
As a result, for instance a command in
sudo docker run --privileged --rm -t -v /sys/kernel/debug:/sys/kernel/debug:rw
would result in an error.
System Calls Interception #
If you run into a message like:
System doesn’t support syscall interception
It most probably means a system call interception is outside of the list of the ones considered to be safe (LXD can allow system call interception if it’s considered to be safe).
Linux: Hugepages Support from within LXD Container #
As of now, Travis CI is not configured to allow hugepages within unprivileged containers. This may change on short notice.
The unprivileged containers access to hugepages is added by the great Linux and LXD teams. To understand what needs to be addressed in order to avoid memory issues with LXD containers, please look at the resources below:
VM Instance Size #
If you need more than the default 2vCPU and RAM, you can run a build on a larger instance size. Variable instance sizes are available only for ‘full-vm’ build jobs. All you need to do is type the appropriate instance size to your
.travis.yml using the following tags and one of the available values:
vm: size: [large|x-large|2x-large]
Available instance sizes can be selected for following build jobs:
- OS is Linux, FreeBSD or Windows
- CPU architecture is amd64
In other cases you may find your job rerouted to the default Linux queue in Google Cloud. The support for larger instances of arm64 Graviton2 is on the way.
Please note, that the usage of VM instance sizes requires some credits to be available in the user’s account. Read more in our billing overview.
Each tier of instance size delivers more vCPU and RAM resources available at your discretion. The default one is ‘medium’, which is mapped to any basic instance in our infrastructure providers, usually being 2vCPU and around 4 or 8 GB of RAM. One does not need to call it out explicitly, the ‘medium’ is assigned automatically to your build job.
|large||4||~16||requires credits to use|
|x-large||8||~32||requires credits to use|
|2x-large||16||~64||requires credits to use; may be limited to certain Plans|
Deprecated Virtualization Environments #
Historically, Travis CI has provided the following virtualization environments.
- Trusty Container-based environment: was available between July, 2017 and December, 2018.
- Precise Container-based environment: was available between December, 2014 and September, 2017.
- Legacy Linux environment: was available until December, 2015.
If you’re trying to use
sudo: false or
dist: precise keys in your
travis.yml, we recommend you remove them and switch to our current Xenial Linux infrastructure.