doctl CLI Guide 2026 — Manage DigitalOcean from Command Line

คู่มือสำหรับการติดตั้ง ตั้งค่า authentication และการใช้ doctl ในการจัดการ DigitalOcean infrastructure ผ่าน command line

doctl is the official command-line interface from DigitalOcean that gives developers the power to manage Droplets, Domains, Snapshots, Volumes, and other resources directly from the terminal without opening the control panel web interface. This guide walks you through installation, configuring authentication, essential commands, and writing practical automation scripts that actually work in production.

What is doctl and Why Developers Should Use It

doctl is DigitalOcean's official command-line interface, developed as open source and published on GitHub at github.com/digitalocean/doctl. It lets developers manage virtually any DigitalOcean resource from the terminal without opening the web control panel — whether creating, deleting, or checking Droplet status, managing Domains and DNS records, creating and restoring Snapshots, attaching Volumes to servers, or even fetching kubeconfig for Managed Kubernetes (DOKS) to use directly with kubectl. The main reason developers should use doctl instead of clicking through the web interface is speed and repeatability. A command you type once can be saved as a script and run again exactly the same way every time, without needing to remember a sequence of UI clicks. This matters tremendously when teams need to spin up staging environments repeatedly or destroy them after testing to save money. Additionally, doctl supports outputting results as JSON via the -o json flag, making it trivial to pipe into tools like jq to extract specific data for use in other scripts. doctl doesn't compete with DigitalOcean's official Terraform provider (digitalocean/digitalocean on Terraform Registry), but they serve different purposes. Terraform excels at declaring infrastructure structure declaratively and managing state over time, while doctl is better for imperative tasks that need immediate execution — checking server status, force-restarting a Droplet, or pulling a complete resource inventory for mid-day audits. Many teams use both together: Terraform provisions the core infrastructure and doctl handles daily operations or debugging. For newcomers to DigitalOcean's API, doctl is a faster learning tool than reading the API docs directly because commands are organized into clear categories — doctl compute, doctl kubernetes, doctl databases, doctl apps — making it easy to discover commands via --help at any level.

• Open source and free at github.com/digitalocean/doctl — no cost for the tool itself
• Supports multiple output formats like -o json or -o text for easy script integration
• Commands are organized by resource type: doctl compute, doctl kubernetes, doctl databases
• Works alongside Terraform — Terraform manages long-term infrastructure, doctl handles day-to-day operations
• Every command has --help documentation for available flags, reducing time spent in external docs

Installing doctl (brew/snap/binary)

Worth highlighting here — doctl installation varies by operating system. For macOS users, the easiest and most maintainable method is via Homebrew with brew install doctl, which installs the latest binary and required dependencies automatically. Later, updating to a newer version is as simple as running brew upgrade doctl. Linux users on distributions that support Snap (like Ubuntu) can install via snap install doctl. Snap handles sandboxing and file permissions to some degree, though you may need to grant additional permissions for SSH key access in the home folder with a command like snap connect doctl:ssh-keys if you encounter file access issues during use. For all operating systems including Windows, you can download precompiled binaries directly from the GitHub releases page at github.com/digitalocean/doctl/releases. Choose the file matching your system architecture (like amd64 or arm64), extract the tar.gz file with tar xf doctl-*.tar.gz, then move the resulting binary into a directory in your PATH, such as sudo mv doctl /usr/local/bin. This approach works well in environments like CI/CD pipelines where you want to pin a specific version and prevent accidental upgrades. Once installed, verify everything works by running doctl version, which displays the version number and build metadata. If the command isn't found, double-check that your installation directory is in your shell's PATH, especially if you installed manually and need to add the folder to .zshrc or .bashrc yourself.

• macOS: brew install doctl and update with brew upgrade doctl
• Linux (Snap): snap install doctl, may need snap connect doctl:ssh-keys for permissions
• All OS: Download binary from GitHub releases and move it into PATH yourself — ideal for CI/CD needing version pinning
• Verify installation with doctl version

Authentication with Personal Access Token

Before using doctl, you need to connect it to your DigitalOcean account via a Personal Access Token. Start by creating a token at cloud.digitalocean.com/account/api/tokens. Give it a meaningful name describing the machine or purpose, and choose permissions carefully. For read-only operations, select read-only scope to reduce risk if the token leaks, but for scripts that create or delete resources, you'll need full read and write permissions. Once you have your token, run doctl auth init on your machine. It will prompt you to paste the token, then save it to doctl's config file (typically ~/.config/doctl/config.yaml). A useful feature is that doctl supports multiple contexts in one machine, perfect for people managing several DigitalOcean accounts like separate work and personal accounts. Create a new context with doctl auth init --context work, then switch between contexts with doctl auth switch --context work, and list all available contexts with doctl auth list. For automation pipelines like CI/CD that can't do interactive input, doctl supports reading tokens from the environment variable DIGITALOCEAN_ACCESS_TOKEN automatically, or you can pass tokens via the -t flag in every command, like doctl -t $DIGITALOCEAN_ACCESS_TOKEN compute droplet list. This eliminates the need to run interactive auth init in non-interactive environments. After setup, test the connection with doctl account get, which retrieves account information like email and verification status. If the token has expired or been revoked from the web interface, this command fails immediately, alerting you to create a new token. Never embed tokens in files committed to git, and always use your CI/CD system's secret manager instead.

• Create a token at cloud.digitalocean.com/account/api/tokens, choosing read-only or read+write scope based on your needs
• doctl auth init for interactive setup on first run
• doctl auth init --context name and doctl auth switch --context name to manage multiple accounts

Basic Commands: Create, Delete, and List Droplets

The doctl compute droplet command group is what most developers use most frequently, covering the entire Droplet lifecycle from creation to deletion. Create a new Droplet with a command like doctl compute droplet create mydroplet --region sgp1 --image ubuntu-22-04-x64 --size s-1vcpu-1gb --ssh-keys <fingerprint>, specifying at minimum a region, OS image, size (server spec), and SSH key for login. For users in Thailand, region sgp1 (Singapore) is the closest option with the lowest latency compared to other DigitalOcean regions. Before creating a Droplet, check available values using helper commands: doctl compute region list to see all regions, doctl compute size list for available server specs, doctl compute image list --public for OS images DigitalOcean provides, and doctl compute ssh-key list to see uploaded SSH keys with their fingerprints for reference when creating Droplets. A 1 GiB RAM / 1 vCPU Droplet starts at $6/month according to DigitalOcean's published pricing. After creation, list all Droplets with doctl compute droplet list to see IPs and status, or get details for a specific one with doctl compute droplet get <id>. Delete with doctl compute droplet delete <id>, which asks for confirmation unless you add the --force flag to skip confirmation — useful for unattended automation scripts. To control machine state during operation, use the doctl compute droplet-action commands like doctl compute droplet-action reboot <id> or doctl compute droplet-action power-cycle <id>. For SSH access without memorizing IPs, use doctl compute ssh <droplet-name>, and doctl automatically looks up the IP from the Droplet name.

• doctl compute droplet create name --region sgp1 --image ubuntu-22-04-x64 --size s-1vcpu-1gb --ssh-keys <fingerprint> to create a new Droplet
• doctl compute region list, doctl compute size list, doctl compute image list --public to verify available values before creating
• doctl compute droplet list and doctl compute droplet get <id> to view inventory and details

Managing Domains, Snapshots, and Volumes via doctl

In practice, beyond Droplets, doctl manages other critical resources via command line. For Domains and DNS records, use doctl compute domain commands to add a domain to DigitalOcean DNS with doctl compute domain create example.com --ip-address <IP>, which auto-creates the initial A record. Add additional records like subdomains with doctl compute domain records create example.com --record-type A --record-name www --record-data <IP>, and list all records with doctl compute domain records list example.com. For backups using Snapshots, create a snapshot of an entire Droplet with doctl compute droplet-action snapshot <droplet-id> --snapshot-name mybackup. This temporarily halts the machine while imaging (best done during low load). View all snapshots with doctl compute snapshot list and delete unused ones with doctl compute snapshot delete <id>. Droplet snapshots cost $0.06 per GiB per month based on actual snapshot size, not the Droplet's full disk. Volumes or Block Storage are separate from a Droplet's primary disk and work well for expandable storage or moving data between machines freely. Create one with doctl compute volume create myvolume --region sgp1 --size 100GiB and attach it to a Droplet with doctl compute volume-action attach <volume-id> <droplet-id>. Volumes cost $0.10 per GiB per month — a 100 GiB Volume runs about $10 monthly. You can snapshot Volumes too using doctl compute volume-action snapshot <volume-id> --snapshot-name <name>, charged at $0.06 per GiB per month like Droplet snapshots. One important caveat: Volumes created but not attached to any Droplet still incur charges at their full reserved size. Use doctl compute volume list regularly to spot unused Volumes and avoid surprise billing from idle storage.

• doctl compute domain create example.com --ip-address <IP> and doctl compute domain records create ... to manage DNS records
• doctl compute droplet-action snapshot <id> --snapshot-name ... to back up entire Droplets, costing $0.06/GiB/month
• doctl compute volume create ... --size 100GiB to create separate Block Storage, priced at $0.10/GiB/month
• doctl compute volume-action attach/detach to connect or disconnect Volumes from Droplets

Writing Automation Scripts with doctl

doctl's true power emerges when combined with automation scripts instead of running individual commands. Every command supports JSON output via the -o json flag, letting you pipe into jq to extract specific values and feed them into other script steps. For example, pull IPs of all Droplets tagged staging, loop through them, and delete them after testing, or grab old Snapshots and auto-delete them to control costs. For CI/CD pipelines like GitHub Actions or GitLab CI, the typical flow is downloading doctl from GitHub releases directly (faster and more version-controlled than package managers), storing the Personal Access Token in the CI system's secret manager, and passing it as the environment variable DIGITALOCEAN_ACCESS_TOKEN so doctl reads it automatically without requiring interactive auth. When provisioning resources that subsequent pipeline steps depend on — like deploying an app right after creating a Droplet — add the --wait flag to your create command to block until the resource is fully active, preventing downstream steps from failing because the machine isn't ready yet. This is a frequent source of failure in hastily-written automation. Another common pattern is pulling a Managed Kubernetes kubeconfig and piping it into kubectl automatically with doctl kubernetes cluster kubeconfig save <cluster-id>, letting pipelines deploy to clusters without manually downloading config files from the web interface. For unattended scripts, use defensive practices: start with set -euo pipefail in bash to halt immediately on errors instead of continuing after something breaks, and add retry logic around API calls since temporary network or rate-limit errors are normal in production automation.

• Use -o json piped to jq to extract and reuse data in scripts
• CI/CD: Download doctl from GitHub releases binary + store tokens in secrets via DIGITALOCEAN_ACCESS_TOKEN
• Add --wait when provisioning resources that later steps depend on being ready

Common Errors and How to Fix Them

From our hands-on testing — the most common error when starting with doctl is "Unable to initialize DigitalOcean API client" or "401 Unauthorized", usually from a missing, expired, or revoked token. Check basic connectivity with doctl account get. If it fails, verify the active context with doctl auth list, then run doctl auth init again with a freshly created token. Another frequent issue is create or delete commands failing with 403 Forbidden even though auth succeeds — typically the token has only read-only permissions. Go to cloud.digitalocean.com/account/api/tokens and create a new token with write scope, or upgrade the existing one if the UI allows it. Many read-only tokens can't be upgraded in place, so creating a new one is often necessary. When scripts parse doctl's text output (tables), you'll sometimes hit parsing bugs from column misalignment or values with spaces, causing split errors. The fix is switching to -o json for any script that processes the output downstream, then extracting values with jq instead of string manipulation. JSON is far more robust and version-proof over time. Calling doctl very frequently in quick succession or in loops risks rate-limit errors from DigitalOcean's API. Mitigate by fetching larger batches once instead of looping and getting individual items, add delays between calls, and implement retry logic for transient failures from the network or API. If commands don't run after installation, verify the binary is truly in PATH with which doctl and check the version with doctl version.

• 401 Unauthorized: Check your token with doctl account get and doctl auth list, then doctl auth init again if token expired or was revoked
• 403 Forbidden despite successful auth: The token likely has read-only permissions only — create a new token with write scope
• Text output parsing errors: Switch from text/table format to -o json and extract values with jq instead of string manipulation
• Rate limit errors on frequent calls: Fetch large batches once instead of looping over individual items, add delays, and implement retry logic
• Command not found after install: Verify the binary is in PATH with which doctl and check version with doctl version

Best Practices

When using doctl in production, especially in teams or automation pipelines, several practices improve security and maintainability. Create separate Personal Access Tokens by purpose rather than sharing one everywhere — keep CI/CD tokens separate from local machine tokens so you can revoke just the compromised one without breaking everything else. Always use read-only permissions whenever a task doesn't require write access. Never hardcode tokens into scripts or commit them to git repositories. Use environment variables with secret managers from your CI/CD platform (GitHub Actions secrets, GitLab CI variables, etc.), and let doctl read the token via DIGITALOCEAN_ACCESS_TOKEN automatically. Avoid passing tokens as command-line arguments because process arguments get logged to shell history and system logs. For scripting, default to -o json whenever output will be processed further, and use the --format flag to restrict columns to only what you need when displaying text output on screen. This keeps output readable without stripping irrelevant data by hand. Scripts running non-interactively should include --force on commands that normally ask for confirmation, like deletes, to prevent scripts hanging waiting for input that will never arrive. Across teams, enforce consistent doctl versions via version pins in README files or version managers like asdf/mise to avoid behavior differences between machines. Always carefully review scripts that call doctl compute droplet delete or other destructive resource commands before merging — these commands destroy real data and usually can't be undone without a pre-existing snapshot.

• Create separate Personal Access Tokens by purpose (CI/CD, local machine) so you can revoke one point of compromise without affecting others
• Store tokens via secret managers only, reading them through DIGITALOCEAN_ACCESS_TOKEN — never hardcode or pass as an argument
• Use -o json by default in scripts, and use --format to limit columns when displaying text output

Get $200 Free Credit →