We’re still experimenting with new VM providers and VM configurations, but in general, what you can expect:
- at least 7.5GB RAM
- at least 2 CPU cores
- 64 bit CPU
- at least 10GB free disk space
We use standard Docker images, published on Docker Hub,
and the related
Dockerfile (the description file which describes the docker image / environment,
and which is directly used to build the image) can be found on GitHub.
Right now we have three docker images, built on top of each other:
- Bitrise Base image ( GitHub / Docker Hub )
- includes all the non-Android tools and environment setup
- ideal to be used for non-Android projects as a base image, if you want to use it locally too, as this is the smallest image
gitand the bitrise command line tools are all preinstalled and ready to use.
Ubuntu 16.04, 64 bit
Dockerfilewhere you can see what’s preinstalled in this image: https://github.com/bitrise-docker/bitrise-base/blob/master/Dockerfile
- Base Android image ( GitHub / Docker Hub )
- extends the Bitrise Base image with Android specific tools and environments.
- Multiple Android SDK, Build Tool and system image versions are preinstalled, as well as
- You can use the
$ANDROID_HOMEenvironment variable to point to the location of the pre-installed Android SDK
Dockerfilewhere you can see what’s preinstalled in this image: https://github.com/bitrise-docker/android/blob/master/Dockerfile
- Android NDK image ( GitHub / Docker Hub )
- built on the Base Android image, extends it with the latest Android NDK.
- You can use the
$ANDROID_NDK_HOMEenvironment variable to point to the location of the preinstalled Android NDK, and it’s also added to
Dockerfilewhere you can see what’s preinstalled in this image: https://github.com/bitrise-docker/android-ndk/blob/master/Dockerfile
You can find the pre-installed tools & System Report of this Stack at: https://github.com/bitrise-io/bitrise.io/blob/master/system_reports/linux-docker-android.log
Docker & Virtual Machines ⚓
Every build runs in a new VM (which is destroyed right after the build),
not just in a new container! This allows us to grant you full control over
and the whole environment.
When your build starts on the Docker based Stack we volume mount the
into your container (similar to calling
docker run -v /var/run/docker.sock:/var/run/docker.sock ...;
you can find a description about this access granting method at:
This means that you have access to
docker in your container, and can use other tools which use docker,
You can, for example, configure and run tests and other automations on website projects using
You can call
etc. exactly how you would on your own machine.
Shared volumes ⚓
Practically this means that if you use the standard paths and you use relative paths to mount volumes it’ll work as expected,
as the default source code directory is located inside
/bitrise (by default it’s
/bitrise/src in our Docker images).
What won’t work is if you change the source code directory to be located outside of
or you want to mount a folder with an absolute path outside of