Every build runs on a fresh virtual machine which is not shared with other builds and the state of which is not preserved between consequent builds. After the build is finished its virtual machine is decommissioned.
AppVeyor runs builds on two build clouds:
Hyper-V cloud is a primary build cloud hosted in LiquidWeb’s Lansing, Michigan data center. It is a pool of pre-heated virtual machines, so, generally, builds start faster on Hyper-V cloud.
Google Compute Engine (GCE) cloud is a secondary build cloud running in Google Cloud “Central US” zone. Builds are routed to GCE cloud when they use a custom build worker image not available on Hyper-V cloud. GCE cloud is also used as a failover solution for Hyper-V cloud.
It usually takes a build around 3-4 minutes to start on GCE environment as this is the time required to provision and boot up build virtual machine.
There might be build scenarios that cannot be covered by AppVeyor build workers. For example, some proprietary software should be pre-installed to support your builds or you need more powerful build VMs or private network access.
AppVeyor allows running builds on your own cloud:
In this scenario AppVeyor service provides UI, orchestration, artifacts storage and NuGet feeds while AppVeyor build agents run on your virtual machines. Private build clouds are available to customers with Premium plan and can be enabled upon request. Please let us know if you are interested.
|Build cloud / configuration||CPU||Memory||Nested virtualization|
|Hyper-V||2 cores||4 GB||-|
|Hyper-V "4-cores"||4 cores||7 GB||Enabled|
|GCE||2 cores||7.5 GB||-|
IP addresses assigned to build VMs in Google data center (
IP addresses assigned to build VMs in LiquidWeb data center (Lansing, MI):
18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11
IP address of AppVeyor Cloud in Azure data center (
West US region) - when deploying with “Environments”:
Build worker image is a template used to provision a virtual machine for your build. Physical implementation of the template depends on the build cloud platform and can be a master VHD for Hyper-V and Azure, snapshot or image for GCE or AWS.
AppVeyor provides these “standard” build worker images:
Visual Studio 2013
Visual Studio 2015
Visual Studio 2017
Ubuntu1604- Ubuntu 16.04
Ubuntu1804- Ubuntu 18.04
Below you can find the list of pre-installed software for all images.
AppVeyor also provides a build image which contains, in place of the Visual Studio 2017 version on the current image, the VS2017 preview relative to that version.
Visual Studio 2017 Preview
The aim is to stay in sync with the release rhythm of Visual Studio 2017.
If the build configuration does not specify build worker image then
Visual Studio 2015 image is used.
You can select a different image on AppVeyor UI (“Environment” tab of project settings) or in
image: Visual Studio 2017
or to build on Linux:
Please note that
appveyor.ymlhas precedence over UI settings, so when
appveyor.ymlexists the image should be specified in YAML, not on UI.
image is first class dimension for build matrix, therefore the following YAML configuration will work (and will create 4 build jobs):
image: - Visual Studio 2015 - Visual Studio 2017 - Ubuntu environment: matrix: - MY_VAR: value1 - MY_VAR: value2
Also for some combinations it makes sense to use
APPVEYOR_BUILD_WORKER_IMAGE “tweak” environment variable, so this configuration will also work (and will create 2 build jobs):
environment: matrix: - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015 MY_VAR: value1 - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017 MY_VAR: value2 - APPVEYOR_BUILD_WORKER_IMAGE: Ubuntu MY_VAR: value3
AppVeyor team regularly (once in 2-3 weeks) updates build worker images by installing new or updating existing software.
The history of build worker image updates can be found here.
Before rolling out an image update we perform its extensive testing. However, not all usage scenarios can be covered by our automated tests and sometimes even a smallest change in the image can break someone’s build. If that happened - no worries - you’re covered! We provide an access to “last good” versions of build worker images from previous update:
Previous Visual Studio 2013
Previous Visual Studio 2015
Previous Visual Studio 2017
You can use those images to unblock your builds while we are working together with you to understand the root cause and do a fix by the next image update.
The following pages contain the up-to-date list of software pre-installed on build worker VMs: