Security Best Practices Guide for Droplets

<- Back to Security

DigitalOcean Droplets are Linux-based virtual machines (VMs) that run on top of virtualized hardware. Each Droplet you create is a new server you can use, either standalone or as part of a larger, cloud-based infrastructure. Droplets have a set amount of CPU, RAM, and storage with an publicly accessible IP address (note: VPC Droplets are private, isolated networks).

Unless a customer has brought their own image, droplets are spun up with vanilla installs of one of six specific operating systems: AlmaLinux, CentOS, Debian, Fedora, Rocky Linux, and Ubuntu.

It is up to the customer to secure those instances and the following guide provides some best practices for how to do so.

There are many ways to improve security of the Droplet. Detailed hardening guides at the operating system level are not detailed here. For more information, please refer to the following:

Ensure Backups are Enabled

Droplet backup is a service provided by DigitalOcean to help users protect their data by creating automatic, system-level backups of their Droplets. These backups enable users to have access to recent copies of their data, which can be crucial for disaster recovery and minimizing downtime in case of accidental deletion, system failures, or other data loss scenarios.

Rationale

A few benefits of enabling backups for your Droplet are:

  • Data Loss Prevention: Backups act as a safety net in case of data loss, accidental file deletion, or corruption. With a backup, you can restore your Droplet to a previous state.
  • Disaster Recovery: In the event of a misconfiguration of your droplet, a hardware, software, or other significant error which renders your Droplet unusable, backups provide a method to minimize downtime by quickly recovering and rebuilding your system.
  • Easy Migration: Backups make it easier to migrate your Droplet to a different data center or region within DigitalOcean’s ecosystem. With a backup, you can spin up a new Droplet and load the backup into the new resource, thus replicating your server in a new location.
  • Security: Regular backups can help mitigate the impact of security incidents, stemming from malware, system or app compromise, etc. Should your Droplet be compromised, you can restore the resource from a clean backup created prior to the infection rather than trying to clean a compromised system.

Impact

In the event that you do not enable backups on your Droplet, the backup process is not properly configured or encounters issues during execution, you run the risk of having incomplete or corrupt backups, which can complicate data restoration.

Audit Procedure

Use the DigitalOcean Control Panel to View Existing Backups

  1. Sign in to your DigitalOcean account.
  2. Select Droplets in the side panel.
  3. Select a Droplet from the list.
  4. Click Backups in the side panel to view all backups.

Use an API to List Backups for a Droplet

  1. To retrieve any backups associated with a Droplet, send a GET request to
  1. /v2/droplets/$DROPLET_ID/backups
  1. You will get back a JSON object that has a backups key. This will be set to an array of backup objects, each of which contain the standard Droplet backup attributes.

Please review List Backups for a Droplet of the DigitalOcean API reference for more details.

Remediation Procedure

Please refer to our How to Enable Backups Guide.

Back to the top

Back to Security Best Practices Guides Intro


Ensure a Firewall is Created

A firewall is a security system that monitors and controls network traffic based on a set of security rules, deciding whether to allow incoming and outgoing traffic to pass through to the systems behind the firewall. Firewalls usually sit between a trusted network and an untrusted network; oftentimes the untrusted network is the Internet. DigitalOcean Droplets, by default, sit on the public internet making firewalls especially critical (note: this does not apply to VPC droplets).

DigitalOcean offers a firewall product that you can use and we will discuss the usage of that product below. However, you can also use Linux provided firewall tooling like iptables, ufw, etc. Host-based firewalls are not covered here.

Rationale

A few benefits of creating a firewall for your Droplet are:

  • Security: Firewalls act as a bidirectional barrier between your server, a trusted network, and untrusted networks, such as the Internet. Firewalls filter incoming and outgoing network traffic based on a set of predefined rules, allowing only authorized connections to reach your Droplet.

  • Access Control: Firewalls provide granular control over which services and ports are accessible from the Internet, therein reducing your server’s attack surface.

  • Protection Against Common Attacks: Firewalls can help mitigate common network-based attacks, such as Distributed Denial of Service (DDoS) attacks, port scanning, and brute force attacks. By blocking traffic, you can reduce the impact of these attacks on your server’s performance and availability.

  • Compliance: Many security regulations and compliance standards require the use of firewalls as a basic security measure.

Impact

If firewall rules are too strict or incorrectly configured, legitimate traffic such as client requests, administrative access, or inter-service communication might be blocked, leading to service disruptions or degraded performance.

Audit Procedure

Using the Control Panel to Verify Your Droplet has a Firewall

  1. Log in to your DigitalOcean account at https://cloud.digitalocean.com/login.
  2. In the DigitalOcean Control Panel, click on “Droplets” in the sidebar to access your Droplets.
  3. Find the Droplet you want to check for a firewall and click on its name to go to the Droplet’s detail page.
  4. In the Droplet detail page, click on the “Networking” tab.
  5. Scroll down to the “Firewalls” section. If a firewall is configured for this Droplet, it will be listed here, along with its name and any associated rules.

Using the Command Line to Verify Your Droplet has a Firewall

  1. Connect to your Droplet using SSH. You can do this using the following command, replacing `your-droplet-ip` with your Droplet’s IP address and `your-ssh-key` with your SSH private key file:
  1. ssh -i /path/to/your-ssh-key root@your-droplet-ip
  1. Once logged in, you can check if a firewall is configured. Run the following commands:
  1. doctl compute firewall list
  1. doctl compute firewall list-by-droplet <droplet-id>

If a firewall is enabled and has rules, you will see output similar to the following:

  1. | Status:Active | | |
  2. |--------------- |-------- |--------------- |
  3. | To | Action | From |
  4. | OpenSSH | Allow | Anywhere |
  5. | 80/TCP | Allow | Anywhere |

If no firewall is configured, the output will indicate that the firewall is inactive or not installed.

Remediation

Please review our How to Create Firewalls documentation.

Back to the top

Back to Security Best Practices Guides Intro


Ensure the Droplet is Connected to a Firewall

A firewall is a security system that monitors and controls network traffic based on a set of security rules, deciding whether to allow incoming and outgoing traffic to pass through to the systems behind the firewall. Firewalls usually sit between a trusted network and an untrusted network; oftentimes the untrusted network is the Internet. DigitalOcean Droplets, by default, sit on the public internet making firewalls especially critical (note: this does not apply to VPC droplets).

DigitalOcean offers a firewall product that you can use and we will discuss the usage of that product below. However, you can also use Linux provided firewall tooling like iptables, ufw, etc. Host-based firewalls are not covered here.

Rationale

A few benefits of connecting a firewall to your Droplet are:

  • Isolation Between Droplets: Firewalls can enforce security policies that isolate Droplets from each other. This is crucial for preventing a compromised Droplet from affecting others or accessing data it shouldn’t.
  • External Threat Protection: Firewalls can be configured to monitor and filter incoming and outgoing traffic to and from Droplets, protecting them from external threats.

Impact

If firewall rules are too strict or incorrectly configured, legitimate traffic such as client requests, administrative access, or inter-service communication might be blocked, leading to service disruptions or degraded performance.

Audit Procedure

Using the Control Panel to Verify Your Droplet has a Firewall

  1. Log in to your DigitalOcean account at https://cloud.digitalocean.com/login.
  2. In the DigitalOcean Control Panel, click on “Droplets” in the sidebar to access your Droplets.
  3. Find the Droplet you want to check for a firewall and click on its name to go to the Droplet’s detail page.
  4. In the Droplet detail page, click on the “Networking” tab.
  5. Scroll down to the “Firewalls” section. If a firewall is configured for this Droplet, it will be listed here, along with its name and any associated rules.

Using the Command Line to Verify Your Droplet has a Firewall

  1. Connect to your Droplet using SSH. You can do this using the following command, replacing `your-droplet-ip` with your Droplet’s IP address and `your-ssh-key` with your SSH private key file:
  1. ssh -i /path/to/your-ssh-key root@your-droplet-ip
  1. Once logged in, you can run the following command:
  1. doctl compute firewall list

If a firewall is enabled and has rules, you will see output similar to the following:

  1. | Status:Active | | |
  2. |--------------- |-------- |--------------- |
  3. | To | Action | From |
  4. | OpenSSH | Allow | Anywhere |
  5. | 80/TCP | Allow | Anywhere |

If no firewall is configured, the output will indicate that the firewall is inactive or not installed.

Remediation Procedure

Follow the instructions in our How to Add and Remove Droplets from Firewalls documentation.

Back to the top

Back to Security Best Practices Guides Intro


Ensure Operating System on Droplet is Upgraded

Upgrading an operating system is crucial for maintaining an efficient, secure, and compatible computing environment. The upgrades may provide enhanced security, improved performance, and access to new features. Regularly upgrading ensures that users can take full advantage of technological advancements while keeping their systems secure against evolving threats.

Rationale

A few benefits of upgrading/patching the operating system on a Droplet are:

  • Security: Newer versions of operating systems come with updated security patches which address vulnerabilities discovered in older versions.
  • Extended Support: Older operating systems eventually reach their end-of-life, after which they no longer receive updates or support from the developers. Upgrading ensures continued support, which is crucial for maintaining a secure and stable server environment.
  • Improved Performance via Enhanced Resource Utilization: Newer operating systems often have better mechanisms for resource allocation and management, which can lead to more efficient use of the Droplet’s resources like CPU, RAM, and storage. Upgraded operating systems often come with enhancements in performance, including better memory management and faster processing. This can lead to more efficient running of applications and services hosted on the Droplet.

Impact

Upgrades to any operating system carry an inherent risk of failure, data loss, or broken software configuration. Comprehensive backups and extensive testing are strongly advised.

Audit Procedure

DigitalOcean supports a fixed set of operating systems: Ubuntu, AlmaLinux, Fedora, Debian, CentOS and Rocky Linux). The End of Life.Date project gives a good idea which versions of what operating system are going to expire.

Remediation Procedure

Please note that the specific commands may vary depending on the Linux distribution you are using. The following instructions are for a typical Ubuntu-based system (such as Ubuntu, Debian, or a similar distribution).

  1. SSH into your Droplet: Open your terminal or SSH client and connect to your Droplet using its IP address or hostname. Replace <your-droplet-ip> with your Droplet’s actual IP address:
  1. ssh username@your-droplet-ip

If you are using a non-root user with sudo privileges, you can log in with that user and use sudo for administrative commands.

  1. Check OS Version:
  • Debian,Ubuntu OS:
  1. lsb_release -a
  • Fedora,CentOS,RedHat
  1. cat /etc/os-release
  2. cat /etc/redhat-release
  • Other Linux Distributions
  1. uname -a

Back to the top

Back to Security Best Practices Guides Intro


Ensure Operating System is Updated

An operating system update, also known as a patch, improves an operating system’s functionality, security, and stability without upgrading it to a new version. These updates address various issues such as security vulnerabilities, bugs, and other software flaws that could affect the performance and safety of the system.

Rationale

Updating the operating system on a Droplet is important for:

  • Security: Operating system updates often include patches for known vulnerabilities. By keeping your OS up to date, you reduce the risk of security breaches and potential attacks on your server.
  • Bug fixes: Updates also include fixes for software bugs and stability improvements, which can help prevent unexpected crashes.
  • Performance: Newer versions of the operating system may offer performance enhancements and optimizations, leading to improved server performance and responsiveness.
  • Compatibility: Updated software is more likely to be compatible with the latest applications and services, ensuring that your Droplet can run modern software without issues.

Impact

Improperly updating your operating system can cause several adverse effects, affecting system stability and security to the functionality of installed applications. Best practices for updating an operating system are regularly backing up data, following official documentation, and testing updates in a controlled environment.

Audit Procedure

DigitalOcean supports a fixed set of operating systems: Ubuntu, AlmaLinux, Fedora, Debian, CentOS and Rocky Linux). The End of Life.Date project gives a good idea which versions of what operating system are going to expire.

Remediation Procedure

  • AlmaLinux, Fedora, Rocky Linux
  1. dnf update
  1. dnf needs-restarting -r
  • CentOS
  1. dnf update
  • Debian, Ubuntu
  1. apt update
  1. apt upgrade

OR

  1. apt dist-upgrade

Back to the top

Back to Security Best Practices Guides Intro


Ensure Auditd is Enabled

Auditd is a user-space component of the Linux Auditing System, mainly used for collecting and writing audit logs to the disk. It helps system administrators monitor security incidents by logging various system events like file accesses and user activities.

Auditd can be configured to track detailed system activity, facilitating the identification of patterns and anomalies that may be indicative of malicious behavior. The system’s flexibility allows for the creation of custom rules tailored to the specific monitoring needs of an organization.

When the auditd service starts, it reads the audit.rules file to load its configuration. The audit.rules file contains specific rules that tell auditd what to log. These rules can specify which system calls to track, which files to watch for changes, and what types of user activity to monitor. Please refer to Red Hat’s Defining Audit Rules guide to determine which rules are appropriate for your organization.

Refer to this list for audit record types: Audit Record Types

Rationale

A few benefits of service auditing for a Droplet are:

  • Security: Auditd produces logs that can help recreate events on your Droplet. This is a critically important part of recovery after a security incident or understanding events on your Droplet in a security lens.
  • Fault Detection: Auditing helps in early detection of faults and errors in services. It allows you to identify and troubleshoot issues such as service crashes, failures, or unexpected behavior, preventing downtime and service disruptions.
  • Compliance: For businesses and organizations that need to adhere to specific regulatory requirements or compliance standards, regular service auditing helps ensure that services are configured and operated in accordance with those standards.

Impact

Auditd can have performance impacts if incorrectly configured. For example you may not want to audit all filesystem writes if you’re running a database service.

Auditd can generate a large volume of logs, especially if configured to track a wide range of activities. This logging can consume considerable system resources (CPU, memory, and disk I/O), potentially affecting the performance of the Droplet, especially if it has limited resources.

The logs generated by auditd can quickly consume disk space. Without proper log rotation strategy and management, this can lead to disk space issues, affecting the Droplet’s stability and performance.

When auditing, it is important to carefully configure the storage requirements for audit logs. By default, auditd will max out the log files at 5MB and retain only 4 copies of them. Older versions will be deleted. It is possible on a system that the 20 MBs of audit logs may fill up the system causing loss of audit data. While the recommendations here provide guidance, be sure to understand the context of your specific environment for audit storage requirements.

Audit Procedure

To check if service auditing is set up on your DigitalOcean Droplet, you can follow these steps:

  1. Log in to your DigitalOcean Droplet console using SSH.
  2. DigitalOcean uses the auditd daemon for auditing. Use Audit Procedure section of the Benchmark for your Linux distribution to test if auditd is installed:

Remediation Procedure

Please follow the steps and links below to install and configure auditd for your operating system. The links require a CIS Workbench account.

  1. SSH into Your Droplet: Open your terminal or SSH client and connect to your Droplet using its IP address or hostname:
  1. ssh username@your-droplet-ip

Replace username with your username, and your-droplet-ip with your Droplet’s IP address.

  1. Install auditd using the Remediation Procedure appropriate for your Linux distribution:

  2. Ensure auditd is enabled and active. Please refer to the CIS Benchmark guide for your Linux distribution:

  3. Enable auditd service at bootup.Audit events need to be captured on processes that start up prior to auditd, so that potential malicious activity cannot go undetected. Please refer to the CIS Benchmark guide for your Linux distribution:

  4. Ensure the audit backlog limit is sufficient. If audit=1 during boot, then the backlog will hold 64 records. If more that 64 records are created during boot, auditd records will be lost and potential malicious activity could go undetected. The recommended audit backlog limit value is 8192 or larger. Please refer to the CIS Benchmark guide for your Linux distribution:

  5. Configure data retention. Once the log reaches the maximum size, it will be rotated and a new log file will be started. It is important that an appropriate size is determined for log files so that they do not impact the system and audit data is not lost. Please refer to the CIS Benchmark guide for your Linux distribution:

  6. Configure and test auditd rules. The Audit system operates on a set of rules that define what is to be captured in the log files. The following types of Audit rules can be specified:

    • Control rules: Allow the Audit system’s behavior and some of its configuration to be modified.
    • File system rules: Allow the auditing of access to a particular file or a directory. (Also known as file watches)
    • System call rules: Allow logging of system calls that any specified program makes.

    Audit rules can be set on the command line using the auditctl utility (note: these rules are not persistent across reboots). They can also be set in a file ending in .rules in the /etc/audit/audit.d/ directory. To define Audit rules that are persistent across reboots, you must either directly include them in the /etc/audit/audit.rules file or use the augenrules program that reads rules located in the /etc/audit/rules.d/ directory.

  7. Test the rules using the following command. No output implies correct syntax.

  1. sudo auditctl -t < THE FILEPATH FOR YOUR AUDIT.RULES FILE
  1. Configure logrotate. The system includes the capability of rotating log files regularly to avoid filling up the system with logs or making the logs unmanageably large. The file /etc/logrotate.d/syslog is the configuration file used to rotate log files created by syslog or rsyslog. By keeping the log files smaller and more manageable, a system administrator can easily archive these files to another system and spend less time looking through inordinately large log files. Please refer to the CIS Benchmark guide for your Linux distribution:

Back to the top

Back to Security Best Practices Guides Intro


Ensure SSH Keys are Used to Authenticate

SSH keys are a pair of cryptographic keys that can be used to authenticate to an SSH server as an alternative to password-based logins. SSH, which stands for Secure Shell, is a network protocol used to securely access and manage machines over an unsecured network. SSH keys offer a more secure way of logging into a server with SSH than using a password alone.

SSH keys must be added prior to Droplet set up. They cannot be retroactively added to Droplets when other keys are added. When the authorized keys are placed on a Droplet, they control access to the root account only, not named users. Access for named users must be setup individually on the Droplet operating system itself and not via DigitalOcean cloud platform.

Rationale

Reasons why SSH key authentication is considered more secure than password authentication:

  • Strong Encryption: SSH key pairs are typically generated using strong encryption algorithms, such as RSA or Ed25519, which are significantly more secure than passwords. Keys are stronger than passwords because of the asymmetric encryption key pair. A well generated key pair is much harder to brute force than a password.
  • No Passwords: With SSH key authentication, there are no passwords involved in the authentication process. Passwords can be vulnerable to various attacks, including brute force attacks, phishing, and credential leaks. Since SSH keys are cryptographically secure, they are not susceptible to these types of attacks.
  • Lowers Probability of Credential Theft: SSH keys are not easily stolen or intercepted because the private key is never transmitted over the network. Even if an attacker gains access to the server, they won’t have access to your private key unless it’s stored on the server (which is not recommended). In contrast, passwords are sent over the network during authentication and can be intercepted if the connection is not secure.
  • Logging and Accountability: SSH key-based authentication allows for better auditing and accountability. When someone uses an SSH key to log in, their actions are associated with that key, making it easier to trace who did what on a server.
  • Revocation and Rotation: If you suspect that your private key has been compromised, you can easily revoke it and generate a new one.

Impact

SSH keys do not have an inherent expiration date like some other authentication methods. This means that old, possibly forgotten keys can remain valid indefinitely unless manually removed, potentially leading to unauthorized access if those keys are compromised. The security of SSH key authentication relies on the private key remaining confidential. If a user’s private key is exposed or stolen, an attacker can gain access to all systems where the corresponding public key is authorized. This risk necessitates careful handling, protection (e.g., with a passphrase), and secure storage of private keys.

Audit Procedure

To check if your DigitalOcean account has an SSH key associated:

  1. Log into your DigitalOcean Control Panel.
  2. Select Settings in the bottom left of the panel.
  3. Select the Security tab in the settings menu.
  4. In the “SSH Keys” section, you should see a list of all the SSH keys associated with your DigitalOcean account. Each SSH key is typically identified by a name you provided when you added it. If there are SSH keys listed, it means you have SSH keys associated with your account.
  5. Verify the key details by clicking on each SSH key to view its details, including the name, fingerprint, and the date it was added. This can help you confirm the existence of your SSH key.

If you do not see any SSH keys listed in this section, it means that there are no SSH keys associated with your DigitalOcean account. In that case, follow the steps outlined in the remediation.

Remediation Procedure

Creating an SSH Key Before Droplet Creation

Open a terminal and run the following command (macOS example):

  1. ssh-keygen

You will be prompted to save and name the key.

  1. Generating public/private rsa key pair. Enter file in which to save the key (/Users/USER/.ssh/id_rsa):

Next you will be asked to create and confirm a passphrase for the key (highly recommended):

  1. Enter passphrase (empty for no passphrase): Enter same passphrase again:

Copy the contents of the .pub file, typically id_rsa.pub.

  1. cat ~/.ssh/id_rsa.pub

Next,

  1. Go to the Settings section of your DigitalOcean dashboard.
  2. Select the Security tab.
  3. Click the Add SSH Key button.
  4. Paste the public key into the Public Key box and name your key.
  5. Click the blue Add SSH Key button.

This SSH key can be selected during the Choose Authentication Method step of Droplet creation.

For extra security on Ubuntu, Debian, and CentOS droplets, disable Password-based SSH authentication with the following steps:

  1. Open up the SSH configuration file. It is typically found at one of the following locations, depending on your operating system:
  1. sudo nano /etc/ssh/sshd_config
  1. sudo vi /etc/ssh/sshd_config
  1. This command will open up the file within the text editor. Find the line in the file that includes PasswordAuthentication (or create the line if it doesn’t exist), make sure it is not commented out with a # at the beginning of the line, and change it to no:
  1. Password Authentication no
  1. Save and close the file when you are finished.
  • In nano, use CTRL+O to save, hit ENTER to confirm the filename, then CTRL+X to exit.
  • In vi, press ESC and then :wq to write the changes to the file and quit.
  1. Reload the sshd service to put these changes into effect:
  1. sudo systemctl reload sshd
  1. Before exiting your current SSH session, make a test connection in another terminal to verify you can still connect.

Password-based authentication for newly created Alma 9, Rocky 8, and Fedora Droplets has been disabled due to an incompatibility between the operating system’s password authentication mechanism and DigitalOcean’s provisioning system. SSH-based login will remain available.

Creating an SSH Key After Droplet Creation

Please select the link for your Linux distribution to learn how to create a key pair, authenticate keys, and disable password authentication for your server

Back to the top

Back to Security Best Practices Guides Intro


Delete SSH Keys

Description

SSH keys are a pair of cryptographic keys that can be used to authenticate to an SSH server as an alternative to password-based logins. SSH, which stands for Secure Shell, is a network protocol used to securely access and manage machines over an unsecured network. SSH keys offer a more secure way of logging into a server with SSH than using a password alone.

Rationale

Deleting SSH keys are important for:

  • Preventing Unauthorized Access: If an SSH key is no longer needed—such as for an employee who has left the company or a device that’s been decommissioned—leaving it active could open a security vulnerability. Removing old or unused keys reduces the attack surface.
  • Audit Trails: For auditing and monitoring purposes, it’s important to track who has access to what. Deleting keys of former users or devices ensures that audit logs are accurate and reflect actual access privileges.
  • Key Rotation: Regularly deleting old keys and rotating them (changing to new ones) is part of good security hygiene. If a key becomes stale or compromised, attackers may exploit it, so keeping only current, active keys ensures better control over access.

Impact

Deleting or rotating SSH keys is essential for maintaining strong security, but if not managed properly, it can lead to several issues. The most significant risk is losing access to servers if keys are deleted or rotated without properly configuring the new keys first. Automated processes and services that rely on SSH keys may break if they aren’t updated, leading to disruptions. Additionally, if keys are deleted or rotated without proper documentation or communication, it could result in confusion or accidental removal of critical access.

Remediation

Via the Control Panel

  1. Log in to your DigitalOcean Account.
  2. Select “Settings.”
  3. Click the “Security” tab.
  4. The tab shows a table of created SSH keys. Select the three dots at the end of the row of the key you want to delete.
  5. Select “Delete.”

Via the Command Line

Please refer to the API documentation for deleting an SSH key from your account: https://docs.digitalocean.com/reference/api/api-reference/#operation/sshKeys_delete

These methods delete the SSH key from the account and prevent it from being used on new Droplets, but it does not remove the SSH key from existing Droplets.

To ensure the security of existing assets, review each Droplet and (1) delete the departing user’s account or (2) remove keys from appropriate authorized_keys file and change the user account’s password.

For each Droplet in your team account:

  • Delete the departing user’s user’s account

If the system has configured authorized_keys in a different way, please remove them from however your system manages keys.

If it is necessary to keep the user account, please:

  1. Change the password
  2. Remove all appropriate entries from /home/$departing_user_username/.ssh/authorized_keys

If your team’s Droplets are using password auth you must:

  1. Remove the user account all together; or
  2. If the account must persist, change the password of the account to a complex string 18+ characters in length.
  3. If the user had knowledge of the root password, and root logins are allowed in /etc/ssh/sshd_config, you must change the root password on all Droplets that have that password and sshd config.

Back to the top

Back to Security Best Practices Guides Intro

Get started for free

Sign up and get $200 in credit for your first 60 days with DigitalOcean.*

*This promotional offer applies to new accounts only.