Gem Version Build Status Code Climate Coverage Status Dependency Status


A Test Kitchen Driver for Digital Ocean

Shamelessly copied from RoboticCheese's awesome work on an Rackspace driver.


From this version forward the driver uses API V2 only. Use of image_id, flavor_id, and region_id have been replaced with image, size, and region. You can now use slugs instead of relying on the old data.json to translate IDs. Please refer to the examples below, and the API documentation for more information.


There are no external system requirements for this driver. However you will need access to an DigitalOcean account.

Installation and Setup

You'll need to install the gem on your development machine.

gem install kitchen-digitalocean

or add it to your Gemfile if you are using Bundler

source ''

gem 'test-kitchen'
gem 'kitchen-digitalocean'

At minimum, you'll need to tell test-kitchen to use the digitalocean driver.

  name: digitalocean
  - name: ubuntu-12-10-x64

You also have the option of providing your credentials from environment variables.

export DIGITALOCEAN_SSH_KEY_IDS="1234, 5678"

Note that your SSH_KEY_ID must be the numeric id of your ssh key, not the symbolic name. To get the numeric ID of your keys, use something like to following command to get them from the digital ocean API:

curl -X GET -H "Authorization: Bearer $DIGITALOCEAN_ACCESS_TOKEN"

Please refer to the Getting Started Guide for any further documentation.

Default Configuration

The driver now uses api v2 which provides slugs for image names, sizes, and regions.

Example configuration:

- name: debian-7-0-x64
    region: ams1
- name: centos-6-4-x64
    size: 2gb
# ...

Private Networking

Private networking is enabled by default, but will only work in certain regions. You can disable private networking by changing private_networking to false. Example below.

  - private_networking: false


IPv6 is disabled by default, you can enable this if needed. IPv6 is only available in limited regions.

  - ipv6: true


Pull requests are very welcome! Make sure your patches are well tested. Ideally create a topic branch for every separate change you make. For example:

  1. Fork the repo
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Added some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request


Created and maintained by Greg Fitzgerald ([email protected])

Special Thanks:

Will Farrington, His fork was a help during the creation of my api v2 driver.


Apache 2.0 (see LICENSE)