Load balancers now come in small, medium, and large sizes. The larger the load balancer, the more simultaneous connections and requests per second it can manage. Existing load balancers are now considered “small” load balancers and are unaffected by this change.

You can specify the size of a load balancer during its creation using the size field. The available size values are lb-small, lb-medium, or lb-large.

Example request body:

{
  "name": "example-lb-01",
  "region": "nyc3",
  "size": "lb-small",
  "forwarding_rules": [
    {
      "entry_protocol": "https",
      "entry_port": 444,
      "target_protocol": "https",
      "target_port": 443,
      "tls_passthrough": true
    }
  ],
  "health_check": {
    "protocol": "http",
    "port": 80,
    "path": "/",
    "check_interval_seconds": 10,
    "response_timeout_seconds": 5,
    "healthy_threshold": 5,
    "unhealthy_threshold": 3
  },
  "sticky_sessions": {
    "type": "none"
  }
  ]
}

Once you have created a load balancer, you can’t change its size.

We recently replaced Standard Droplet plans with Basic Droplet plans. As part of this process, we deprecated Standard Droplet plans from the control panel for all users.

Starting today, new users will no longer have access to the deprecated Standard Droplet plans from the API as well. Existing customers will retain grandfathered access to these plans.

This is the complete list of plans deprecated for new users:

You can view Droplet plans, the resources they provide, and the size slug used to identify them programmatically by querying the /v2/sizes endpoint.

You can now integrate your DOCR registry with a Kubernetes cluster. When a registry is integrated with a Kubernetes cluster, we create docker registry type secrets in all the namespaces in the cluster. These secrets can be used with the workloads or added to the default service account in the namespace.

Additionally, we’ve added DOCR integration support for our official clients, godo and doctl. Only versions of doctl 1.49.0 and godo 1.48.0 and above support docr integration for clusters.

You can now update a VPC network to be the default VPC network for a region using the PUT /v2/vpcs/$VPC_ID and PATCH /v2/vpcs/$VPC_ID endpoints.

For example:

{
  "name": "renamed-new-vpc",
  "description": "A new description",
  "default": "true"
}

When you change the default VPC network for a region, all applicable resources are placed into the default VPC network unless otherwise specified during their creation.

You can now apply taints to Kubernetes node pools. When you configure taints for a node pool, the taint automatically applies to all current nodes in the pool and any node you add to the pool thereafter. For more information about taints and tolerations, see Kubernetes’ documentation.

Additionally, we’ve added node taint support for our official clients, godo and doctl. Only versions of doctl 1.47.0 and godo 1.45.0 and above support persistent node pool taints.

You can define taints during a pool’s creation by submitting a POST request to the /v2/kubernetes/clusters/<cluster-id>/node_pools and the /v2/kubernetes/clusters endpoints, or you can update existing pools by submitting a PUT request to the /v2/kubernetes/clusters/<cluster-id>/node_pools/<node-pool-id> endpoint. For example, this request body defines two taints for a node pool.

{
  "name": "frontend",
  "size": 10,
  [...]
  "taints": [
    {
      "key": "priority",
      "value": "high",
      "effect": "NoSchedule",
    },
    {
      "key": "workloadKind",
      "value": "database",
      "effect": "NoExecute",
    }
  ]
}

All Droplets created after 1 October 2020 are placed into a VPC network by default. The enable_private_networking action and private_network parameter have been deprecated. Use the vpc_uuid parameter to specify the VPC network for your Droplets.

You can migrate existing Droplets into VPC networks using Snapshots.

Load balancer health checks now support the HTTPS protocol. You can now configure load balancers to verify the health of your Droplets’ HTTPS endpoints.

The response body to POST requests creating multiple Droplets has been extended to include an actions link for each Droplet created. For example:

"links": {
  "actions": [
    {
      "id": 24404896,
      "rel": "create",
      "href": "https://api.digitalocean.com/v2/actions/24404896"
    },
    {
      "id": 24404897,
      "rel": "create",
      "href": "https://api.digitalocean.com/v2/actions/24404897"
    }
  ]
}

These can be used to check the status of each individual Droplet create event rather than polling each Droplet.

Listing records for a domain now supports filtering by both name and type using query parameters. For example, to only include A records for a domain, send a GET request to /v2/domains/$DOMAIN_NAME/records?type=ATo only include records matching sub.example.com, send a GET request to /v2/domains/$DOMAIN_NAME/records?name=sub.example.com. name must be a fully qualified record name. Both name and type may be used together to further filter the records returned.

It is now possible to adjust the behavior of the OAuth authorization flow by specifying a prompt and/or max_auth_age query parameter:

• The prompt query parameter can be used to specify how the authorizing user should be authenticated.
• The max_auth_age query parameter can be used to determine a deadline (in seconds) after which a user must re-authenticate on the control panel.

For more details, consult the OAuth documentation.

It is now possible to destroy snapshots, volumes, and volume snapshots associated with a Droplet while destroying the Droplet itself in a single request. A number of new related endpoints are now available:

• To list the resources that can be destroyed along with the Droplet, send a GET request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources endpoint.
• To destroy a Droplet along and a sub-set of its associated resources, send a DELETE request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources/selective endpoint.
• To destroy a Droplet along with all of its associated resources, send a DELETE request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources/dangerous endpoint.
• To check on the status of a request to destroy a Droplet with its associated resources, send a GET request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources/status endpoint.
• If the status reported any errors, the destroy request can be retried by sending a POST request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources/retry endpoint.

DigitalOcean Load balancers now allow you to set a keepalive option for forwarding rules. Enabling this option allows the load balancer to use fewer active TCP connections to send and receive HTTP requests between the load balancer and your target Droplets.

Starting today, we have begun the incremental release of DigitalOcean VPC, including its API. VPCs (virtual private clouds) allow you to create virtual networks containing resources that can communicate with each other in full isolation using private IP addresses. The VPC service will be available for all customers soon. It replaces the existing private networking service.

When enabled on your account, you will be able to create, configure, list, and delete custom VPCs as well as retrieve information about the resources assigned to them. For example, to create a new VPC, make a POST to the /v2/vpcs endpoint with a JSON body like:

{
  "name": "staging-vpc",
  "description": "VPC for the staging environment"
  "region": "nyc1"
}

For the more details, see the full API reference documentation for DigitalOcean VPCs.

Related Changes

This release contains related functionality for a number of other DigitalOcean resources.

When VPC is enabled on your account, the private_networking attribute previously used to enable private networking while creating a Droplet will now provision the Droplet inside of your account’s default VPC for the region. Use the new vpc_uuid attribute to specify a different VPC.

Kubernetes clusters, load balancers, and database clusters will also be provisioned inside of your account’s default VPC for the region when enabled. To specify a non-default VPC, set the appropriate attribute in the JSON body of the create request:

The DigitalOcean managed databases API now supports configuring the user authentication plug-in for both new and existing MySQL users. This is useful when needing to connect to a MySQL 8.0 cluster using an application or older MySQL client that does not support the default caching_sha2_password authentication plug-in.

For example, to create a new MySQL user using the mysql_native_password authentication plug-in, send a POST request to /v2/databases/$DATABASE_ID/users with a JSON body like:

{
  "name": "php-app-01",
  "mysql_settings": {
    "auth_plugin": "mysql_native_password"
  }
}

For more details, see the full reference documentation for the managed databases API.

To provide a better service for all customers we are introducing burst request rate limits to our public API. Now clients will be rate limited if they consume more than 5% of their total requests for an hour over a 1 minute period (going over 250 requests in a minute). This only affects clients making their requests in large bursts, clients that spread their requests over time will not be affected. Check the rate limits documentation for more information about it.

Our managed DigitalOcean Kubernetes product DOKS now supports setting Kubernetes labels on node pools. Once assigned, they will propagate to the associated pool nodes, both existing and new ones. This way, customers may reliably reference groups of nodes through label selectors that Kubernetes provides.

Labels can be set on node pool API objects that are accessible on multiple endpoints. For instance, updating an existing node pool by the labels service=web and priority=high is done by submitting a PUT request to the /v2/kubernetes/clusters/<cluster ID>/node_pools/<node ID> endpoint with the following JSON body:

{
  "name": "web",
  "count": 10,
  "labels": {
    "service": "web",
    "priority": "high"
  }
}

For details, see the available operations on the Kubernetes API.

Our API has been extended with a new endpoint enabling you to retrieve balance information for an account. To do so, make a GET request to /v2/customers/my/balance. The response will be a JSON body including your balance details. For example:

{
  "month_to_date_balance": "23.44",
  "account_balance": "12.23",
  "month_to_date_usage": "11.21",
  "generated_at": "2019-07-09T15:01:12Z"
}

For all the details, see the balance endpoint in the full API reference documentation.

The DigitalOcean API currently offers the ability to retrieve a report of all Droplets co-located on the same physical hardware by sending a GET request to the /v2/reports/droplet_neighbors endpoint. This endpoint has been deprecated and will begin responding with an HTTP status of 410 (Gone) on December 17th, 2019.

Today, in its place, a new endpoint is now available: /v2/reports/droplet_neighbors_ids. Rather than listing the full Droplet object, responses from this endpoint only contain sets of Droplet IDs co-located on the same physical hardware. For example:

{
  "neighbor_ids": [
    [168671828,168663509,168671815],
    [168671883,168671750]
  ]
}

This implementation is more performant and better able to scale for users with many Droplets. For all the information, find the full API reference documentation here.

The API also continues to offer the ability to list “neighbors” for a specific Droplet by sending a GET request to /v2/droplets/$DROPLET_ID/neighbors. This endpoint will continue to function without change.

We apologize for the inconvenience. If you need guidance on this transition, please feel free to reach out to the team by opening a support ticket.

DigitalOcean’s API now supports managing a database cluster’s firewall rules (known as “trusted sources” in the control panel) as well as the ability to configure the SQL mode used by MySQL clusters.

Using the /v2/databases/$DATABASE_ID/firewall endpoint, you can specify which resources should be able to open connections to your database. You may limit connections to specific Droplets, Kubernetes clusters, or external IP addresses. When a tag is provided, any Droplet or Kubernetes node with that tag applied to it will have access. For example, the body a PUT request might look like:

{
  "rules": [
    {"type": "ip_addr", "value": "192.168.1.1"},
    {"type": "droplet", "value": "163973392"},
    {"type": "k8s", "value": "ff2a6c52-5a44-4b63-b99c-0e98e7a63d61"},
    {"type": "tag", "value": "backend"}
  ]
}

To configure the SQL modes for a MySQL cluster, use the /v2/databases/$DATABASE_ID/sql_mode endpoint. For example, the body a PUT request might look like:

{
  "sql_mode": "ANSI,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE"
}

For more information, see the full API reference documentation for managed databases.

The /v2/volumes?name=$VOLUME_NAME endpoint now lists all volumes that match the specified name as a query parameter. For more information, see the API v2 reference documentation on list Block Storage volumes filtered by name.

Today DigitalOcean’s Managed Database service launched support for two new database engines, MySQL and Redis. Both are currently in Limited Availability and can initially be used in the NYC1, FRA1, and SFO2 regions.

When creating a new database cluster using the API, you must specify the engine attribute to select which type of database to use (mysql for MySQL or redis for Redis). For example, to create a new Redis cluster, make a POST to the /v2/databases endpoint with a JSON body like:

{
  "name": "cache-01",
  "engine": "redis",
  "version": "5",
  "region": "nyc1",
  "size": "db-s-1vcpu-2gb",
  "num_nodes": 2
}

See the full API reference documentation for all the details. For more information about DigitalOcean Managed Databases including the roll-out plan for additional regions, check out the blog post announcing the release.

The ttl of a domain record now has a minimum value of 30 seconds, and if not set, the default value has changed from 1800 to the ttl of the SOA record.

DigitalOcean Managed Databases now provide support for private networking. All new database clusters will be provisioned with private networking enabled. Existing clusters will require an update to connect over the private network. This can be triggered in the control panel.

Databases, read-only replicas, and connection pools will now contain a new private_connection object holding the information needed to access the resource via the private network. Its attributes are identical to the existing connection object, but the values for private_connection.uri and private_connection.host will contain FQDNs only accessible from resources (e.g. Droplets or Kubernetes clusters) within your account and in the same region.

For more information, see the full Managed Databases API documentation.

SOA records are now returned in record results, and you can update the TTL on a SOA record as you would with other records. This allows you to control the negative caching of your domain. SOA records cannot be manually deleted or created on a domain, they are created when the domain is created, and cleaned up on the domain deletion.

Today, we are promoting the Kubernetes API to General Availability. As part of this release, we have also extended the API with additional functionality:

• When creating or updating a cluster, you may now configure a maintenance window policy specifying the day of the week and time of day that updates should take place for the cluster. Additionally, setting a cluster’s auto_upgrade attribute to true will specify that the cluster can be automatically upgraded to new Kubernetes patch releases (e.g. 1.13.1 to 1.13.2) during its maintenance window.

• An upgrade endpoint is now available to imminently trigger an upgrade to a newer patch release of Kubernetes at your own convienience. You may list available upgrades for your cluster using the upgrades endpoint.

• In order to give users finer control over individual nodes, the recycle endpoint has been deprecated. Instead, we now offer the ability to delete or replace specific nodes in a node pool. By default, workloads will be drained from the node before deletion. Appending the skip_drain=1 query parameter to the request will cause the node to be imminently deleted. Appending the replace=1 query parameter to the request will cause the node to be replaced by a new one after it has been deleted.

For the full details, see the API reference documentation for Kubernetes.

Thank you to everyone who took the time to provide us with feedback.

The /v2/volumes/$volume_id/snapshots endpoint now accepts tags at creation time, and these are reflected on the /v2/snapshots endpoint. Volume snapshot tags may now be managed with the /v2/tags endpoint as well. For more information, see the API reference documentation for both block storage volumes and tags.

Spaces, DigitalOcean’s object storage solution, includes a built-in CDN. Today we’ve added the ability to use custom subdomains with your CDN endpoints. When configuring your CDN via the API, you can now set the custom_domain attribute to use a subdomain with the endpoint. When a custom subdomain is in use, the certificate_id attribute is also required. Its value must be the the ID of a DigitalOcean managed SSL certificate. For example, the body of your request to enable a CDN might look like:

{
  "origin": "static-images.nyc3.digitaloceanspaces.com",
  "certificate_id": "892071a0-bb95-49bc-8021-3afd67a210bf",
  "custom_domain": "static.example.com"
}

See here for more information about using the API to configure Spaces CDN endpoints.

DigitalOcean Load Balancers now support using PROXY Protocol to pass information like origin IP addresses and port numbers from connecting client requests along to the backend service. This can be configured using the API by setting the new enable_proxy_protocol attribute to true when creating a new Load Balancer or updating an existing one.

See here for more information about using PROXY Protocol with DigitalOcean Load Balancers.

As announced on September 5, 2018, the last_tagged attribute returned in response to GET requests to the /v2/tags or /v2/tags/$TAG_NAME endpoints has been deprecated. Beginning March 1st, 2019, last_tagged will no longer be populated in favor of the last_tagged_uri attribute.

For example, a GET request to /v2/tags/frontend currently might return:

{
  "tag": {
    "name": "frontend",
    "resources": {
      "count": 3,
      "last_tagged_uri": "https://api.digitalocean.com/v2/droplets/132000916",
      "droplets": {
        "count": 3,
        "last_tagged": {
          "id": 132000916,
          "name": "suspicious-bhabha-u8zq",
          "memory": 2048,
          "vcpus": 2,
          "disk": 60,
          "locked": false,
          "status": "active",
          "kernel": null,
          "created_at": "2019-02-13T05:29:52Z",
          "features": [
            "private_networking"
          ],
          "backup_ids": [],
          "next_backup_window": null,
          "snapshot_ids": [],
          "image": {
            "id": 43509743,
            "name": "do-kube-1.12.3",
            "distribution": "Debian",
            "slug": null,
            "public": false,
            "regions": [
              "ams2",
              "ams3",
              "blr1",
              "fra1",
              "lon1",
              "nyc1",
              "nyc2",
              "nyc3",
              "sfo1",
              "sfo2",
              "sgp1",
              "tor1"
            ],
            "created_at": "2019-02-11T20:38:04Z",
            "min_disk_size": 20,
            "type": "snapshot",
            "size_gigabytes": 2.99
          },
          "volume_ids": [],
          "size": {
            "slug": "s-2vcpu-2gb",
            "memory": 2048,
            "vcpus": 2,
            "disk": 60,
            "transfer": 3,
            "price_monthly": 15,
            "price_hourly": 0.02232,
            "regions": [
              "ams2",
              "ams3",
              "blr1",
              "fra1",
              "lon1",
              "nyc1",
              "nyc2",
              "nyc3",
              "sfo1",
              "sfo2",
              "sgp1",
              "tor1"
            ],
            "available": true
          },
          "size_slug": "s-2vcpu-2gb",
          "networks": {
            "v4": [
              {
                "ip_address": "192.0.2.255",
                "netmask": "255.255.240.0",
                "gateway": "192.0.2.1",
                "type": "public"
              },
              {
                "ip_address": "10.136.121.81",
                "netmask": "255.255.0.0",
                "gateway": "10.136.0.1",
                "type": "private"
              }
            ],
            "v6": []
          },
          "region": {
            "name": "New York 1",
            "slug": "nyc1",
            "sizes": [
              "s-1vcpu-3gb",
              "s-1vcpu-1gb",
              "s-3vcpu-1gb",
              "s-1vcpu-2gb",
              "s-2vcpu-2gb",
              "s-2vcpu-4gb",
              "s-4vcpu-8gb",
              "s-16vcpu-64gb",
              "s-6vcpu-16gb",
              "s-8vcpu-32gb",
              "s-12vcpu-48gb",
              "s-20vcpu-96gb",
              "s-24vcpu-128gb",
              "s-32vcpu-192gb"
            ],
            "features": [
              "private_networking",
              "backups",
              "ipv6",
              "metadata",
              "install_agent",
              "server_id",
              "management_networking"
            ],
            "available": true
          },
          "tags": [
            "frontend"
          ]
        },
        "last_tagged_uri": "https://api.digitalocean.com/v2/droplets/132000916"
      },
      "images": {
        "count": 1,
        "last_tagged_uri": "https://api.digitalocean.com/v2/images/42991114"
      },
      "volumes": {
        "count": 0
      }
    }
  }
}

Following this change, the new response would look like:

{
  "tag": {
    "name": "frontend",
    "resources": {
      "count": 3,
      "last_tagged_uri": "https://api.digitalocean.com/v2/droplets/132000916",
      "droplets": {
        "count": 3,
        "last_tagged_uri": "https://api.digitalocean.com/v2/droplets/132000916"
      },
      "images": {
        "count": 1,
        "last_tagged_uri": "https://api.digitalocean.com/v2/images/42991114"
      },
      "volumes": {
        "count": 0
      }
    }
  }
}

For additional information, please see the full API reference documentation for tags.

Today DigitalOcean’s Managed Database service, including its API, has entered Limited Availability. In order to access these new endpoints, you must first enable Managed Databases on your account by opting-in via the cloud control panel. Once enabled, you will be able to create, scale, and manage your database clusters via the API. For example, to create a new database cluster, make a POST to the /v2/databases endpoint with a JSON body like:

{
  "name": "backend",
  "engine": "pg",
  "version": "10",
  "region": "nyc3",
  "size": "db-s-1vcpu-2gb",
  "num_nodes": 2
}

The response will include a full JSON representation of the database cluster. The initial value of the cluster’s status attribute will be “creating.” When the cluster is ready for use, this will transition to “online.”

For the all the details, see the full API reference documentation for DigitalOcean Managed Databases.

The /v2/volumes endpoint now displays tags and supports adding them to volumes at creation time. Volume tags may now be managed with the /v2/tags endpoint as well. For more information, see the API reference documentation for both block storage volumes and tags.

Today we opened up access to the DigitalOcean Kubernetes service for all users. As part of this release, the API is now also available to all. While still in Limited Availability, you must first enable Kubernetes on your account by opting-in via the cloud control panel to access these endpoints.

Once enabled, you will be able to list, create, or delete clusters as well as scale node pools up and down, recycle individual nodes, and retrieve the kubeconfig file for use with a cluster via the API. For example, to create a new cluster with a node pool using three s-2vcpu-2gb Droplets, make a POST to the /v2/kubernetes/clusters endpoint with a JSON body like:

{
  "name": "prod-cluster-01",
  "region": "nyc1",
  "version": "1.12.1-do.2",
  "tags": ["production"],
  "node_pools": [
    {
      "size": "s-2vcpu-2gb",
      "count": 3,
      "name": "woker-pool"
    }
  ]
}

The response will include a full JSON representation of the cluster. The initial value of the cluster’s status.state attribute will be “provisioning.” When the cluster is ready for use, this will transition to “running.” You can use the /v2/kubernetes/options endpoint to find the available versions of Kubernetes as well as the supported regions and Droplet sizes.

Once ready, you can retrieve the credentials for use with the cluster by sending a GET request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/kubeconfig. The response will be a kubeconfig file in yaml format. This file can be used to connect to and administer the cluster using the Kubernetes command line tool, kubectl. For more information, see “How to Connect to a DigitalOcean Kubernetes Cluster with kubectl.”

For the all the details, see the full API reference documentation for DigitalOcean Kubernetes.

Today, we are promoting the Projects API to General Availability. For the full details, see the API reference documentation for both Projects and Project Resources.

Thank you to everyone who took the time to provide us with feedback.

Today, we are launching a beta of our new Projects API. Projects enable you to group your resources in ways that align with the applications you host on DigitalOcean, and now you can do so via our API as well. This initial release includes the ability to:

• Create, list, retrieve, update, and delete Projects
• Assign existing resources to a Project
• List resources in a Project

Additionally, we’ve added beta support for Projects to our official clients (Droplet Kit, godo, and doctl).

You can create a new project by sending a POST request to the /v2/projects endpoint including a body like:

{
  "name": "my-web-api",
  "description": "My website API",
  "purpose": "Service or API",
  "environment": "Production"
}

To assign resources to a project, send a POST request to /v2/projects/$PROJECT_ID/resources including a list of those resources in the body:

{
  "resources": [
    "do:droplet:123456",
    "do:floatingip:192.168.99.100",
    "do:space:static-assets",
    "do:volume:0e250b2a-8a01-11e8-96ae-0242ad114410"
   ]
}

Resources are identified by uniform resource names or URNs, a string consisting of the type of resource and its unique identifier. A valid URN has the following format: do:resource_type:resource_id. For the full details, see the API reference documentation for both Projects and Project Resources.

Note that as this is a beta release, we may make additional changes based on your feedback. So let’s us know how you’re using projects, and please follow along with the API changelog for updates.

Today’s release brings Content Delivery Network (CDN) support to Spaces, DigitalOcean’s object storage solution. This can be configured and managed using our API. By sending requests to /v2/cdn/endpoints, you can list, create, or delete CDN endpoints as well as purge cached content.

To enable the CDN for your Space, send a POST request to /v2/cdn/endpoints. In the JSON body of your request, specify the origin of your content and the desired TTL. For example:

{
  "origin": "static-images.nyc3.digitaloceanspaces.com",
  "ttl": 3600
}

Currently, the origin must be a DigitalOcean Space.

To purge cached content from a CDN endpoint, send a DELETE request to /v2/cdn/endpoints/$ENDPOINT_ID/cache. The body of the request should include a files attribute containing a list of cached file paths to be purged. A path may be for a single file or may contain a wildcard (*) to recursively purge all files under a directory. When only a wildcard is provided, all cached files will be purged. For example, the body of your request might look like:

{
  "files": [
    "assets/img/hero.png",
    "assets/css/*"
  ]
}

For additional details, see the API reference documentation for managing CDN endpoints.

Today DigitalOcean released support for uploading custom images, enabling you to create Droplets based on your own Linux virtual machine images. Our image management API has been extended with support as well. By sending a POST to the /v2/images endpoint, you can create a new custom image. The request must contain a url attribute pointing to where the image can be downloaded. The image itself may be in the raw, qcow2, vhdx, vdi, or vmdk format. It can be compressed using gzip or bzip2 but must be smaller that 100 GB after being decompressed. For example, the body of you request might look like:

{
  "name": "ubuntu-18.04-minimal",
  "url": "http://cloud-images.ubuntu.com/minimal/releases/bionic/release/ubuntu-18.04-minimal-cloudimg-amd64.img",
  "distribution": "Ubuntu",
  "region": "nyc3",
  "description": "Cloud-optimized image w/ small footprint",
  "tags": [
    "base-image",
    "prod"
  ]
}

To make organizing your images easier, we’ve also extended tagging support to custom images as well as Droplet snapshots. For additional details, see the API reference documentation for creating custom images and tagging resources.

When listing or getting tags by sending a GET request to /v2/tags or /v2/tags/$TAG_NAME, the response payload currently includes a last_tagged value inside the tag’s resources.droplets containing a full representation of the resource. This payload is considerably nested and adds additional overhead to the request. In order to improve performance as well as lay the groundwork for bring tagging support to additional resources, this attribute is being deprecated. Beginning March 1st, 2019 last_tagged will no longer be populated in favor of the new last_tagged_uri attribute introduced today.

For all resources (and each resource type supported), the last_tagged_uri attribute contains a string indicating the URI which can be used to retrieve details about that specific resource. If you need information about the last tagged resource specifically, issuing another call to that URI will provide you with all the data for that resource.

Additionally, a count attribute describing how many resources overall have been tagged with the tag in question has been added. Each individual resource type will continue providing a count attribute.

If you need guidance on transitioning from using last_tagged to using of the new last_tagged_uri attribute , please feel free to reach out to the team by opening a support ticket.

New Domain resources can now be created via the DigitalOcean v2 API without providing an IP address. The previous behavior, which would automatically create an A record pointing to the apex domain, will be retained for backwards-compatibility when an IP address is provided.

This example demonstrates how to create a new domain without providing an IP address:

curl -X POST -H "Content-Type: application/json" \
    -H "Authorization: Bearer $DIGITALOCEAN_API_TOKEN" \
    -d '{"name":"example.com"}' \
    "https://api.digitalocean.com/v2/domains"

For more information, see the full Domains API documentation.

The /v2/volumes endpoint has been updated to support automatically formatting the filesystem of newly created Block Storage volumes. Volume resources now expose two new attributes: filesystem_type and filesystem_label. They can be used to specify the filesystem and the label to be applied. Currently, the available filesytem types are ext4 and xfs.

For example, here is a request creating a new volume formatted with an EXT4 filesystem:

  curl -X POST \
    -d '{"name":"volume-nyc3-01","region":"nyc3","filesystem_type":"ext4","filesystem_label":"example","size_gigabytes": 100}' \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
    https://api.digitalocean.com/v2/volumes

Additionally, Ubuntu, Debian, Fedora, Fedora Atomic, and CentOS Droplets created on or after April 26, 2018 will now automatically mount volumes with pre-formatted filesystems when attached. Attaching pre-formatted volumes to other Droplets is not recommended. When the filesystem_type attribute is not provided, volumes will continue to be presented as raw block devices and require additional configuration.

When retrieving an existing Block Storage volume, filesystem_type and filesystem_label will reflect the current filesystem and label used on the volume even if these were applied manually.

For more information, see the full API documentation for Block Storage Volumes.

Today, DigitalOcean released a number of Load Balancer improvements including support for using SSL/TLS certificates automatically generated by Let’s Encrypt. Our Certificate management API has been updated to support automatically generating Let’s Encrypt certificates in addition to uploading custom, user-generated certificates.

A request to generate a new SSL/TLS certificate using Let’s Encrypt would look like:

  curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $DO_TOKEN" \
    -d '{"name": "le-cert-01", "type": "lets_encrypt", "dns_names": ["www.example.com","example.com"]}' \
    "https://api.digitalocean.com/v2/certificates"

The new type attribute must be set to lets_encrypt when using Let’s Encrypt. If omitted, it will default to custom in order to maintain backwards compatibility. For additional details, see the Certificate management API reference documentation.

For more information on how to use Let’s Encrypt with DigitalOcean Load Balancers, see this tutorial on our community site.

Today, we announced wide-ranging changes to our Droplet plans, bringing improved resources across the board. These new plans are now available via the API and can be referenced using their respective size slugs.

Size slugs are human-readable strings used to specify the type of Droplet in certain API requests. In the past, size slugs were typically based on the amount of RAM provided with the plan (e.g. 1gb). Moving forward, we are standardizing on a format comprised of the identifier for the Droplet’s class, the vCPU count, and the amount of RAM in order to provide more flexibility in the plans we are able to offer you. For example, our new $5 per month Standard Droplet comes with 1 vCPU and 1 GB of RAM. So its size slug is: s-1vcpu-1gb

Applications and scripts with hard-coded size slugs must be updated to take advantage of these new plans. In order to provide a transition period, 1st Generation Droplet plans will continue to be available via the API using the legacy size slugs. We will provide additional notice before their removal.

The table below shows the new 2nd Generation Standard Droplet plans along with their corresponding size slug. For always up-to-date information on available plans and pricing, please see our pricing page.

Available Droplet plans, the resources they provide, and the size slug used to identify them can be accessed programmatically by querying the /v2/sizes endpoint.

Domain Record resources have been updated to add support for CAA records. As specified in RFC-6844, this record type can be used to specify which certificate authorities (CAs) are permitted to issue certificates for a domain.

For example, in order to restrict TLS/SSL certificate creation for example.com to letsencrypt.org, you would use a request like:

  curl -X POST \
    -d '{"type":"CAA","name":"@","data":"letsencrypt.org.","priority":null,"port":null,"ttl":1800,"flags":0,"tag":"issue"}' \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
    https://api.digitalocean.com/v2/domains/example.com/records

For more information on how to use CAA records, see this tutorial on our community site.

Our API has been extended to support configuring the TTL value for individual domain records. This can be done when creating a new record as well as when updating an existing one via a PUT request. See the domain record documentation for further information.

Our API currently offers the ability to “rename” a tag by sending a PUT request to /v2/tags/$TAG_NAME. Due to low usage and operational complexities involved with its maintenance, we are deprecating this functionality. Beginning April 26th, 2017 all requests to this endpoint will respond with an HTTP status of 410 (Gone). A tag’s name also serves as its unique identifier. We’ve found that the ability to change a tag’s name introduces unneeded complexity. If you need guidance on this transition, please feel free to reach out to the team by opening a support ticket.

You may now pass tags as an attribute when creating one or more new Droplets. This optional parameter will create and apply the specified tag(s) to the newly created Droplet(s). For more information see create Droplet documentation.

API v2 now supports volume snapshots, and exposes a unified snapshot endpoint for volume and Droplet snapshots.

Size objects now contain a size_gigabytes attribute which represents the physical size of the image in gigabytes. For more information see the images documentation.

API v2 now supports tagging and managing tagged droplets.

API v2 now supports creating multiple droplets simultaneously.

Account objects now contain a floating_ip_limit attribute which provides the maximum number of floating IPs that may be provisioned by the account. For more information, see the account documentation.

Version 1 of the DigitalOcean API reached end-of-life on November 9, 2015.

Version 2 of our API provides a more RESTful interface, OAuth support, and allows access to new DigitalOcean products and features. To learn more, please visit the full API reference documentation.

API V2 now supports enabling backups on a Droplet.

Account objects now contain status and status_message attributes, describing whether an account is locked, active or has a pending warning. For more information, see the account documentation.

We’ve deprecated final (temporary) snapshots and therefore temporary is no longer an acceptable value for type for a snapshot.

The access token response from the OAuth API now returns a canonical UUID for an account. This should be used to canonically identify a user.

Since releasing version 2 of our API nearly a year ago and officially bringing it out of beta last month, we’ve seen a tremendous uptake of usage by our community. As the ecosystem of tools and libraries continues to grow, we’ve decided that it is time to sunset version 1 of the API.

Don’t worry! We’re not going to pull the rug out from under you. In order to give everyone time to port their tools, version 1 will not be turned off until Monday, November 9, 2015.

With its (more) RESTful interface and features like OAuth support, v2 is both powerful and easy to use. Our developer documentation should give you all the information you need to begin the transition. If you have questions, you can always ask on our Community site or on Twitter.

We are very pleased to announce that API v2 is no longer in beta. Thank you to everyone who helped report bugs and suggest features during the beta period. Read more about this release on our blog.

The Image action endpoint now responds to a convert attribute, that allows backups and temporary snapshots to be saved permanently as snapshots. For more information, see the image actions documentation.

Images objects now return a type attribute, describing whether they are snapshots, backups or temporary images. For more information, see the images documentation.

Size objects now expose an available boolean attribute, which represents whether new Droplets can be created with the size.

All action objects, i.e. those returned by the /v2/actions, /v2/droplets/$ID/actions and /v2/images/$ID/actions endpoint now return a region_slug attribute, in addition to a region attribute. At 00:01 March 20, 2015 UTC, API v2 will start returning an embedded region object at the region attribute, not a slug.

For example, the API request:

curl -X GET -H 'Content-Type: application/json' \
    -H 'Authorization: Bearer b7d03a6947b217efb6f3ec3bd3504582' \
    "https://api.digitalocean.com/v2/actions?page=1&per_page=1" 

would return:

{
  "actions": [
    {
      "id": 36804636,
      "status": "completed",
      "type": "create",
      "started_at": "2014-11-14T16:29:21Z",
      "completed_at": "2014-11-14T16:30:06Z",
      "resource_id": 3164444,
      "resource_type": "droplet",
      "region": {
        "name": "New York 3",
        "slug": "nyc3",
        "sizes": [
          "32gb",
          "16gb",
          "2gb",
          "1gb",
          "4gb",
          "8gb",
          "512mb",
          "64gb",
          "48gb"
        ],
        "features": [
          "virtio",
          "private_networking",
          "backups",
          "ipv6",
          "metadata"
        ],
        "available": true
      },
      "region_slug": "nyc3"
    }
  ],
  "links": {
    "pages": {
      "last": "https://api.digitalocean.com/v2/actions?page=159&per_page=1",
      "next": "https://api.digitalocean.com/v2/actions?page=2&per_page=1"
    }
  },
  "meta": {
    "total": 159
  }
}

Two new endpoints in API v2 report if droplets are running on the same physical hardware. They exist for an individual droplet or for an entire account.

The maximum allowed rate limit per O-Auth token has been increased to 5,000 requests/hour.

The images now supports a private filter which will allow you to retrieve all images that are specific to your account (IE: backups and snapshots).

For more information, you can view the documentation for this endpoint here.

API V2 now validates SSH key IDs and identifiers passed into the Droplet create call. In addition, API V2 now validates that requested features are available for a Droplet (backups, private networking, IPv6 and user data).

The API v2 now supports retrieving images by type, to retrieve an image by type, simply append:

GET /v2/images?type={distribution,application}

Change type to what you would like to retrieve and voilà!

DropletKit (The Ruby API Client) also supports this functionality as well in Version 1.1.0

You can view the documentation for this feature here.

The JSON object for a droplet no longer contains a nested Size object, but rather a slug called size_slug that references a Size object. Please see the droplet docs for the updated structure.

The Image JSON object now includes a min_disk_size attribute that contains the slug of the minimum size droplet required for that image. For example a snapshot of a 1 Gig droplet will have “1gb” as it’s min_disk_size.

Remove embedded action_ids from Droplet and Image.

Both price_monthly and price_hourly were previously strings. This made them harder to work with so we have gone ahead and turned them into floats.

We have tweaked the per_page limits to default to 20 and be a maximum of 200. We have found in our testing, so far, for this to be a good balance of requests versus results. Head on over and read up on pagination.

API V2 now supports expanding a droplet’s disk size, along with other resources.

API V2 now supports disabling backups on a Droplet.

Want to know which regions support IPv6 or Private Networking? It is now possible to check which features are enabled in each region.

It seems adding X- to custom HTTP headers is going out of style.

So we gone ahead and changed our RateLimit headers to no longer include the X.

They now look like this:

RateLimit-Limit:
RateLimit-Remaining:
RateLimit-Reset: