Virtual machines

On bitrise.io, we have macOS and Linux virtual machines hosted for your builds. You can select from multiple stacks, each with its own list of preinstalled tool versions. Read more about available stacks and stack prepare types in the Available Stacks docs.

The user account that is used for the builds is configured to have passwordless sudo enabled. This way you are able to install all the extra things you need for your builds and for other automation. If a tool is not preinstalled on your Stack of choice, you can install it yourself - see the Install Any Additional Tool guide.

Security ⚓

Every build runs in its own virtual machine and the virtual machine is rolled back to a saved state, the “base box” state, after the build is finished. This way your builds are always protected by changes made by others and by your previous builds and you can use a stable environment to define your build workflow, since no state persists between builds.

For more information about build and code security, see the Code security guide.

Network configuration for the virtual machines ⚓

For most users, who host their repositories on cloud-based service providers, there is no need for any network configuration to be able to use Bitrise. All we need is permission to access the repository and for that, an SSH key is enough.

However, your company security policy might not allow unknown and unauthorized IP addresses to communicate with the servers where your code is being stored - either on your own datacenter or in a private cloud. In that case, Bitrise won’t work unless the relevant IP addresses are added to your allow list.

Adding build machine IPs to your allow list ⚓

Our datacenters are behind a set of public static IP addresses, with the virtual machines having their own internal subnets behind these addresses. You need to add the public IP addresses that you can find in External and internal IP addresses.

Please note that the different stack types have different public IPs. If, for example, you only use the Xcode stacks, there is no need to add the IPs belonging to the Linux/Docker environments.

Configuring your network for VPNs ⚓

You can connect to Bitrise via VPN - but it can cause a conflict if your local network uses the same address space as our build VMs. In such a case, the VPN may detect a clash and return an error. In this case, the only solution is to re-configure your local address space to use different subnets than our virtual machines. You can find the build VM internal address subnets in External and internal IP addresses.

External and internal IP addresses ⚓

Storage space ⚓

Our virtual machines have different amounts of free space to use, depending on the stack type. The table summarises the data - please keep in mind that these numbers are subject to change, as different versions of pre-installed tools and resources take up a varying amount of space on the machines.

Freeing up disk space ⚓

If you need additional disk space, you can always delete tools and resources that you do not use. For example, if your app does not need Android SDK tools, you can remove them. Just add a Script Step to your Workflow with the appropriate commands:

sudo rm -rf ~/Library/Developer/Xamarin/android-sdk-macosx
sudo rm -rf /usr/local/share/android-sdk 
sudo rm -rf /opt/android-ndk

Similarly, feel free to delete iOS simulators that you do not use:

sudo rm -rf ~/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS\\ 10.3.simruntime/

Customization ⚓

You can find the macOS base box setup guide and automation scripts we use for building our macOS virtual machine base boxes in our OS X Box Bootstrap repository. The repository includes every script we use for preparing these base virtual machine images.

For our Linux machines, check out the Bitrise Base Docker Image’s repository.

The repositories used for our virtual machine preparation are open source, and pull requests are welcome. If you’d like to have a tool pre-installed in our machines, feel free to add your changes and they will be included in the related Stack(s) the next time the Stack is updated.

Virtual machine updates ⚓

Updates are always announced in the #changelog category of discuss.bitrise.io and can be seen on your Bitrise Dashboard. We will also send you a Platform Updates notification about significant changes, unless you disable this feature under your account settings page.

Stack updates ⚓

In general we do stack updates once a week, during the weekends.

Minor patches might be applied during the week in case we detect an issue with the current virtual machine environment. These patches do not change any pre-installed tool version, unless it’s really necessary.

We test every stack change as much as we can before it is released to avoid any changes / updates during the week.

Managing Java versions ⚓

By default, every Bitrise stack comes with Java 11 pre-installed and ready to use. If you do not switch to another version, your build will use Java 11.

For now, Java 8 is also available on every stack type, though the process of switching to Java 8 is slightly different on our Ubuntu-based stacks compared to the macOS-based stacks.

Setting Java versions with the Set Java version Step ⚓

You can easily switch between Java 8 and Java 11 with our Set Java version Step. The Step allows you to set the global Java version of the virtual machine that runs your build.

1. Add the Set Java version Step to your Workflow. We recommend setting it as the first Step of the Workflow.
2. Find the Java version to be set globally for the build input.
3. Set it to the version you need. The accepted input values are 8 and 11.

Setting Java versions with a Script Step ⚓

Our Android & Docker stacks run on virtual machines with Ubuntu, while our Xcode and Visual Studio for Mac stacks run on macOS. The process is a little different for the different stack types but on all stacks, switching to a different Java version requires three things:

• Setting Java itself and the Java compiler to the selected version.
• Setting the JAVA_HOME Environment Variable with the export command.
• Storing this Environment Variable with envman so it can be accessed by all Steps in your Workflow.

You can do all of it in one Script Step though, so it’s quite simple. To change the default Java version:

On macOS-based stacks ⚓

1. Add a Script Step to the Workflow before any Step that uses Java in any way.
   The simplest way to do it is to place it as the first Step of the Workflow.

2. Add the following commands to the Script content input of the Step:
   To set the global Java version for the build to Java 11:

   jenv global 11
   export JAVA_HOME="$(jenv prefix)"
   envman add --key JAVA_HOME --value "$(jenv prefix)"
   

   To set the global Java version for the build to Java 8:

   jenv global 1.8
   export JAVA_HOME="$(jenv prefix)"
   envman add --key JAVA_HOME --value "$(jenv prefix)"
   

3. Click Save at the top right corner.

On Ubuntu-based stacks ⚓

1. Add a Script Step to the Workflow before any Step that uses Java in any way.
   The simplest way to do it is to place it as the first Step of the Workflow.

2. Add the following commands to the Script content input of the Step: To set the global Java version for the build to Java 11:

   sudo update-alternatives --set javac /usr/lib/jvm/java-11-openjdk-amd64/bin/javac
   sudo update-alternatives --set java /usr/lib/jvm/java-11-openjdk-amd64/bin/java
      
   export JAVA_HOME='/usr/lib/jvm/java-11-openjdk-amd64'
   envman add --key JAVA_HOME --value '/usr/lib/jvm/java-11-openjdk-amd64'
   

   To set the global Java version for the build to Java 8:

   sudo update-alternatives --set javac /usr/lib/jvm/java-8-openjdk-amd64/bin/javac
   sudo update-alternatives --set java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
          
   export JAVA_HOME='/usr/lib/jvm/java-8-openjdk-amd64'
   envman add --key JAVA_HOME --value '/usr/lib/jvm/java-8-openjdk-amd64'
   

3. Click Save at the top right corner.

Using a Java version not installed on our Android stacks ⚓

If you need a Java or JDK version which is not installed on our Android stacks, follow this guide. The example below will install Java/JDK 1.14 with a Script Step. You can adapt it to the version of your choice.

1. Add the Script Step to your Workflow with the content below and don’t forget to replace the version to the version you wish to install:

   #!/bin/bash
   set -ex
      
   add-apt-repository -y ppa:openjdk-r/ppa
   apt-get update -qq
   apt-get install -y openjdk-14-jdk
   update-java-alternatives -s /usr/lib/jvm/java-1.14.0-openjdk-amd64
   echo "done"
   

2. Start a new build. This Script Step can be the very first Step in the Workflow, as it does not depend on anything else.

iOS Simulator version & SDK support ⚓

All the iOS Simulator versions (which can be installed through Xcode, Preferences, Components) are installed and available.