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 8 pre-installed and ready to use. For now, if you do not switch to another version, your build will use Java 8. However, we recommend switching to Java 11: it should give you better performance, and Java 8 will be removed entirely at some point in the future. Use the older version only if you absolutely must: for example, if your app uses an older tool or dependency.

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

Switching to Java 11 ⚓

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 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 set the Java version to Java 11:

Switching to 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.