AppVeyor premium build environment and new pricing

Posted on November 13, 2014

Based on feedback from our customers we’ve been working on improving AppVeyor performance and got amazing results!

New super-fast environment

For the last couple of months we’ve been experimenting with running builds on new “Premium” environment. It’s based on Hyper-V and hosted on a dedicated hardware with SSD drives and faster CPUs.

We moved most of our existing customers to this new environment and they were very satisfied with the results. Builds start almost instantly, run 2-3 times faster with greater stability!

We still have Azure environment for open-source projects and “Basic” plan.

New Pricing

With the introduction of the new environment we decided to review our plans once again to make them more flexible for companies with different business needs.

There is a new entry-level plan for individual developers and small teams with 1 private project and 1 concurrent job building on Azure. There is an upgraded “Pro” plan now with unlimited number of projects and super-fast builds. For those teams actively using AppVeyor new “Premium” plan now offers 3 concurrent jobs on fast environment.

Also, we introduce yearly pricing for “Pro” and “Premium” plans giving you 2 months free!

Basic Pro Premium
$19/month $59/month $159/month
  $590/year - 2 months free $1590/year - 2 months free
1 private project Unlimited private projects Unlimited private projects
1 concurrent job 1 concurrent job 3 concurrent jobs
- Super-fast build environment Super-fast build environment
- Instant build start Instant build start
Forums support Priority technical support Priority technical support

All existing plans are honored.

If you are a student, educational organization or open-source project looking for more calculation power or concurrent jobs we provide 50% discount on all plans.

AppVeyor on-premise

You may have noticed that we don’t have “Enterprise” plan anymore. This is because “Enterprise” is reserved for AppVeyor on-premise edition that will be available in January 2015!

If you are interested to be a beta tester just reply to this message and we’ll add you to the “AppVeyor Enterprise early bird” mailing list. We’ll be publishing more information and roadmap for on-premise in the coming weeks.

Updated website

AppVeyor has gathered many great open-source projects, such as Mono, Julia, Grunt, Redis, nodegit, Chocolatey, just to mention a few. People contribute their priceless knowledge and experience on AppVeyor forums.

To more actively engage the community in shaping AppVeyor we decided to host our entire website with documentation on GitHub where everyone could contribute by sending a pull request.


The website runs on a new Jekyll-like engine (we called it NJekyll), so you can grab it and use for your own website :)

AppVeyor with a hint of Chocolatey

Posted on November 06, 2014


Chocolatey is a wonderful tool that allows you installing your favourite programs with a single command. Unlike regular process of installing software with interactive setup package where you keep clicking “Next”, “Accept”, “Finish”, etc. Chocolatey does the job without questions asked. By analogy from Linux world Chocolatey is a package manager for Windows.

Chocolatey is great when you setup your development environment and it’s especially great for installing custom software during the build process on AppVeyor! As you know AppVeyor offers fully-customizable build environment where you have admin rights on build machines. For example, if you need to install MongoDB for your integration tests you can do that with the following command (the latest version of Chocolatey is already installed on AppVeyor build workers):

choco install mongodb

The list of software that can be installing with Chocolatey is huge and it’s growing fast. The catalog is community-driven and you can contribute your own packages or update existing ones. Behind the scene Chocolatey uses feed of NuGet packages. Each package contains install.ps1 and uninstall.ps1 PowerShell scripts. If it’s so-called “portable” package application files are stored along with scripts or if it’s “native” package application MSI is downloaded from the Internet and silently installed.

So, Chocolatey is well-established thing, but Chocolatey team want moving it to the next level and making Chocolatey an alternative Windows Store! They created a KickStarter campaign and are asking for our support! Let’s help Chocolatey to do an open, community-driven Application Store for Windows.

Let’s get Chocolatey!

appveyor.yml and multiple branches

Posted on July 23, 2014

The problem

If you use git flow you may want to have a different build configuration (e.g. deploying to a different environment) in a feature branch. Changing appveyor.yml in a feature branch becomes an issue when you merge it into master overriding appveyor.yml and breaking master builds.

The solution

To solve this problem AppVeyor allows having multiple per-branch configurations in a single appveyor.yml.

Multiple configurations are defined as a list with branches section in every item that:

# configuration for "master" branch
# build in Release mode and deploy to Azure
      - master

  configuration: Release
    provider: AzureCS

# configuration for all branches starting from "dev-"
# build in Debug mode and deploy locally for testing
      - /dev-.*/

  configuration: Debug
    provider: Local

# "fall back" configuration for all other branches
# no "branches" section defined
# do not deploy at all
  configuration: Debug

Unlike white- and blacklisting branches section here works like a selector, not a filter. Configuration selection algorithm is the following:

  • Check configurations with branches/only section defined. If branch is found in configuration’s only section use this configuration.
  • Check configurations with branches/except section defined. If branch is NOT found in configuration’s exceptsection use this configuration.
  • Check configurations without branches section. If such configuration is found use it.
  • If all previous steps fail, the build is not run.


Shallow clone for Git repositories

Posted on June 04, 2014

AppVeyor runs every build on a new VM which is getting decommissioned right after the build finishes. The state between consequent builds of the same project is not preserved and every time a new build starts AppVeyor clones entire repository and then checkouts a specific commit. This becomes a challenge for very large repositories or repositories with long history as it takes a significant time to do a clone.

We introduced a new feature called “shallow clone” aiming to improve the situation with large repositories. It offers two options:

  1. Setting depth of git clone command
  2. Downloading repository as zipball using GitHub API

Setting depth of git clone command

By default AppVeyor clones entire repository with all the history. You can limit the number of last commits you’d like to clone. This feature works for Git repositories hosted at GitHub, BitBucket and Kiln. You can set clone depth on General tab of project settings:

Git clone depth

To set clone depth in appveyor.yml add the following in the root of config:

clone_depth: <number>

Note: Be aware that if you do a lot of commits producing queued builds and depth number is too small, git checkout operation following git clone can fail because the requested commit is not present in a cloned repository.

Downloading repository using GitHub API

As title says this option is specific to GitHub. It uses GitHub API to download specific commit of the repository as zip archive and then unpacks it on build worker machine. This feature works for regular commits, branch commits and pull requests.

You can enable this option through UI on General tab of project settings:

GitHub shallow clone

To enable it through appveyor.yml add the following in the root of config:

shallow_clone: true


Build worker improvements

Posted on April 23, 2014

While we are working on some new exciting stuff we continue improving things to make your AppVeyor experience even more smooth and streamlined. One of those recent improvements is a new build worker provisioning engine. Every build in AppVeyor runs on a dedicated virtual machine hosted in Microsoft Azure (yes, now it’s called “Microsoft Azure”). Azure is a great platform - their VMs are considerably faster than competitors’ and creation of a new VM is a blast (usually around 3 minutes). Simplified build flow is the following:

  • Build starts
  • A new VM is provisioning from “master” image (VHD) or being taken from “pre-heated” cache.
  • Build Agent installed on VM runs the build and “talks” to AppVeyor via Web Sockets (SignalR).
  • VM is being deleted after the build

How it was before

We were creating a new VM and then passing build details and starting Build Agent service through PowerShell remoting. That approach had a number of disadvantages:

  • Open WinRM endpoint accessible from the same network.
  • Constantly “pinging” starting up VM until it’s ready to accept WinRM connection. That solution had very high fault rate.
  • Once assigned to a build it was hard to switch build to another VM if the first one is unhealthy.

New approach

The new provisioning mechanism works “inside out”, i.e. Build Agent is started on VM boot and is “listening” for incoming command from AppVeyor using Web Sockets.


This new approach gives a number of benefits:

  • Build worker VM is completely isolated. It doesn’t have an external IP and no endpoints are configured - all inbound connections are prohibited. Even if you know its internal IP address (which is not a secret if you read NIC properties) you still can’t knock it as it sits in a separate private network (Azure cloud service).
  • No more starring at “Provisioning build worker…” or “pending” builds. Now it’s just “Queued” and then “Running”. We got some feedback that knowing VM is in provisioning state doesn’t feel very good and make customers nervous :)
  • If there is pre-heated VM available (we maintain between 3-4 VMs) your build starts almost instantly!
  • If there are no pre-heated VMs it would take around 3 minutes to provision new VM from scratch.
  • Whenever AppVeyor detects there is unhealthy VM worker it will re-schedule the build to another healthy instance, so generally it means being a bit longer in “Queued” state.

We also optimized worker “master” image (VHD) itself to make sure only minimum set of services is enabled to boot fast, eliminate lags and free more memory for your builds. Of course, you can still configure required services such as IIS and SQL Server databases.

Oh, and we introduced Windows Server 2012 R2 image which has almost identical configuration to Windows Server 2012 (except it doesn’t have VS 2010 installed).