Ubuntu 24.04 LTS Droplet Setup Guide 2026 — Getting Started

Ubuntu 24.04 LTS (Noble Numbat) เป็นเวอร์ชันที่ DigitalOcean แนะนำสำหรับ Droplet ใหม่ในปี 2026 ด้วยระยะเวลาซัพพอร์ตยาวถึงปี 2029

Ubuntu 24.04 LTS (Noble Numbat) is the recommended version for new DigitalOcean Droplets in 2026, offering long-term security support through 2029. This article covers all essential initial setup steps: creating a Droplet, configuring SSH keys, creating a new non-root user to avoid using root directly, enabling the firewall, updating the system, setting the timezone, and enabling swap for machines with limited RAM. By following these steps, your server will be fully secured and ready for production use from day one.

Creating an Ubuntu 24.04 LTS Droplet

Proper Droplet initialization begins with creating a machine tailored to your needs from the start. Go to the DigitalOcean Control Panel and click Create > Droplets. Select the Image as Ubuntu, making sure it's version 24.04 (LTS) x64 only—not daily builds or beta versions. LTS (Long Term Support) receives security updates through 2029, making it ideal for production workloads requiring long-term stability without frequent version upgrades. Next, choose a Plan appropriate for your workload. For testing or running light static/API services, the Basic Shared CPU plan with 1 GiB RAM / 1 vCPU / 25 GB SSD / 1,000 GiB transfer at $6/month is often sufficient. However, if you're running web apps with real traffic or databases, upgrading to 2 GiB RAM / 1 vCPU / 50 GB SSD / 2,000 GiB transfer at $12/month is recommended to avoid exhausting swap constantly. Choosing the right size upfront saves you the hassle of resizing later. For the Region, users in Thailand should select sgp1 (Singapore), the closest datacenter among DigitalOcean's 15 locations, ensuring significantly lower latency than US or European regions. Bangalore (blr1) is a secondary option if you want to distribute risk or serve South Asian users as well. Keep in mind that moving a Droplet's region directly isn't possible—you must create a new one from a Snapshot instead, so choose correctly the first time. During Authentication, select SSH Key instead of Password right when creating the Droplet (SSH key creation details are in the next section). Enable Monitoring, a free feature with no additional cost, to track CPU/RAM/Disk metrics for later review. Give your Droplet a meaningful Hostname like web-01-sgp1, then click Create Droplet. Once created, the system displays the Droplet's Public IPv4 Address—save this for connecting. Test your first connection with ssh root@your_droplet_ip from your local terminal. If you successfully connect and see the Ubuntu 24.04 prompt, your Droplet is ready for the next security configuration steps.

• Select Image as Ubuntu 24.04 (LTS) x64 only—not daily builds or beta versions.
• Choose Plan by workload: Basic $6/month (1 GiB RAM) for testing, $12/month (2 GiB RAM) for real web servers.
• Select Region sgp1 (Singapore) for closest access to Thai users; blr1 (Bangalore) as second choice.
• Enable free Monitoring when creating the Droplet with no additional cost.
• Save the Public IPv4 Address for your initial SSH connection.

Configuring SSH Key Instead of Password

SSH keys are far more secure than passwords, protecting against brute-force attacks and eliminating the need to type passwords every time you connect. Start by generating a key pair on your local machine (not on the Droplet) with ssh-keygen -t ed25519 -C "[email protected]". The system asks for the file location (default ~/.ssh/id_ed25519 works fine) and an optional passphrase for additional security. The ed25519 algorithm is recommended over older RSA because it offers shorter keys, superior security, and faster performance. If you didn't add a Key during Droplet creation, you can add it afterward in two ways. The first is using ssh-copy-id root@your_droplet_ip, which automatically copies your public key to the remote ~/.ssh/authorized_keys. The second is copying the contents of ~/.ssh/id_ed25519.pub into your DigitalOcean Control Panel at Settings > Security > SSH Keys, so future Droplets automatically get this key without re-copying. Once you confirm SSH with keys works (test opening a new session without closing the current one in case something breaks), disable password login by editing /etc/ssh/sshd_config. Set PasswordAuthentication no and configure PermitRootLogin prohibit-password so root can SSH in only via key, not password. Then restart the SSH daemon with systemctl restart ssh. Critically, never close your original terminal session until you successfully open a new one. If configuration fails and you close the window, you'll lock yourself out immediately. If this happens, use the DigitalOcean Droplet Console (Droplet Access > Launch Droplet Console) to access the server directly through your browser, bypassing SSH entirely, so you can fix the configuration and regain access.

• Generate keys with ssh-keygen -t ed25519 on your local machine only, never on the Droplet.
• Add keys to the Droplet using ssh-copy-id or paste into the Control Panel during Droplet creation.
• Always test a new session successfully before closing the original one.

Creating a Non-root User

Running daily operations directly as root is risky—a single typo can damage the entire system. Best practice is to create a new user with sudo privileges instead. Start with adduser deploy, which prompts for a password and basic info (you can skip non-essential fields by pressing Enter). Then grant sudo access with usermod -aG sudo deploy. A commonly forgotten step is transferring SSH keys to the new user; without this, you can't SSH into that account. Copy the .ssh directory from root to the new user in one command: rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy. This copies authorized_keys and sets ownership correctly in a single operation. Open a new terminal and immediately test ssh deploy@your_droplet_ip. Once logged in, verify sudo privileges with sudo apt update—it will prompt for the deploy user's password, not root's. If this succeeds, you're ready to disable direct root login. When confident the new user works perfectly, return to /etc/ssh/sshd_config and change PermitRootLogin from prohibit-password to no, then run systemctl restart ssh again. From this point forward, root can only be accessed via sudo or the Droplet Console. This significantly reduces your attack surface because bots scanning for root SSH login is the most common internet attack pattern.

• Create a user with adduser deploy, then grant sudo with usermod -aG sudo deploy.
• Transfer SSH keys to the new user with rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy.
• Test ssh deploy@ip and sudo apt update before disabling root login.

Enabling Basic UFW Firewall

UFW (Uncomplicated Firewall) wraps iptables, making it much simpler than writing raw iptables rules directly. The first rule to set—always before enabling UFW—is to allow SSH, or you'll lock yourself out immediately. Use ufw allow OpenSSH (or ufw allow 22/tcp if you've changed the SSH port). Then enable UFW with ufw enable. The system asks for confirmation because it may disrupt the current session; type y to confirm. For web servers, open HTTP and HTTPS with ufw allow 80/tcp and ufw allow 443/tcp, or use ufw allow "Nginx Full" to open both in one command if Nginx is installed. Check all active rules with ufw status verbose, which displays the default policy and all open ports. For added security, use ufw limit OpenSSH instead of a simple allow rule. This rate-limits connection attempts from any single IP, slowing down brute-force attacks without requiring additional tools. Remember that UFW operates only within the Droplet itself (host-based firewall), whereas DigitalOcean Cloud Firewall works at the network edge before traffic even reaches your Droplet, and it's free with no additional cost. Using both layers together (defense in depth) is more secure than relying on one alone. If UFW is accidentally disabled or misconfigured, Cloud Firewall remains as a backup defense.

• Always run ufw allow OpenSSH first, then ufw enable to avoid locking yourself out.
• Open web ports with ufw allow 80/tcp and ufw allow 443/tcp, or use ufw allow "Nginx Full".
• Verify all rules with ufw status verbose.

System Updates and Timezone Configuration

In practice, after basic security is in place, update all packages to the latest versions, since the DigitalOcean image may have been created weeks earlier. Run apt update && apt upgrade -y, where apt update fetches the latest package list from repositories and apt upgrade -y upgrades all packages automatically. After upgrading, check if a reboot is needed by looking for /var/run/reboot-required—if present, a kernel or major library update requires a restart. To avoid manually running apt upgrade constantly, install unattended-upgrades, Ubuntu's standard tool for automatic security updates in the background. Install it with apt install unattended-upgrades -y, then configure it with dpkg-reconfigure --priority=low unattended-upgrades. This reduces risk from newly discovered vulnerabilities without requiring daily server maintenance. Another often-overlooked detail is Timezone. Droplets default to UTC, causing log timestamps and cron jobs to mismatch Thailand time. Set it correctly with one command: timedatectl set-timezone Asia/Bangkok. No manual config file edits needed. Verify with timedatectl status, which shows Local time now as UTC+7. Setting Timezone correctly from the start is critical for systems with scheduled cron jobs or timestamp-dependent logging. Changing it later after data accumulates makes troubleshooting time-related issues across multiple log files far more complicated.

1. Update the system with apt update && apt upgrade -y immediately after creating a new Droplet.
2. Check if a reboot is needed by looking for /var/run/reboot-required.
3. Install unattended-upgrades to automatically apply security updates in the background.
4. Set Timezone with a single command: timedatectl set-timezone Asia/Bangkok.

Enabling Swap for Low-Memory Droplets

Small Droplets with 512 MiB or 1 GiB RAM are prone to Out-of-Memory (OOM) issues, especially during apt upgrade compilations or memory-intensive tasks. Enabling Swap provides a safety buffer, preventing the OOM killer from abruptly terminating processes. While swap is slower than real RAM (using disk), it's better than an instant application crash. Create a 2GB swap file with fallocate -l 2G /swapfile (if your filesystem doesn't support fallocate, use dd if=/dev/zero of=/swapfile bs=1M count=2048 instead). Restrict access to root only for security: chmod 600 /swapfile, since this file may temporarily contain sensitive data from RAM. Next, format the file as a swap area with mkswap /swapfile, then activate it with swapon /swapfile. Verify success with swapon --show or free -h, which displays the Swap row with the configured size. However, this only lasts until reboot. To persist swap across reboots, add the line /swapfile none swap sw 0 0 to /etc/fstab—a frequently forgotten step that causes swap to mysteriously disappear after rebooting. Finally, adjust vm.swappiness for optimal performance. Ubuntu defaults to 60, causing the system to use swap fairly quickly. For servers that should exhaust RAM first before relying on swap as a last resort, lower this to 10 by adding vm.swappiness=10 to /etc/sysctl.conf, then apply it with sysctl -p without needing a reboot.

• Create a swap file with fallocate -l 2G /swapfile, then chmod 600 /swapfile.
• Activate it with mkswap /swapfile && swapon /swapfile.
• Add the line to /etc/fstab, or swap will disappear after reboot.
• Verify with free -h or swapon --show.
• Adjust vm.swappiness=10 in /etc/sysctl.conf to prioritize RAM over swap.

Common Mistakes and Troubleshooting

One thing that surprised us: the most common mistake is disabling password authentication or root login before testing whether SSH keys actually work, causing instant lockout from the server. The fix is the DigitalOcean Droplet Console (Access > Launch Droplet Console), which connects directly through your browser without SSH, so you can correct sshd_config or firewall misconfiguration and regain access. This is why this guide emphasizes testing before every change. The second frequent error is enabling UFW before allowing OpenSSH, immediately dropping the current connection and blocking new ones. Prevention is simple: always run ufw allow OpenSSH first, then ufw enable. If you accidentally enabled it without allowing SSH, use Droplet Console to disable UFW with ufw disable first. Another common pitfall is creating a new user but forgetting to add it to the sudo group or transfer SSH keys, giving the false impression setup is complete when the account still depends on root. Always test ssh deploy@ip and sudo whoami before disabling root login. For Swap, the frequent mistake is forgetting to add the line to /etc/fstab, causing swap to vanish after every reboot. Simple verification: run free -h after each kernel reboot to confirm swap is still active. Finally, selecting the wrong region (like a US-based one for Thailand users) creates unnecessary latency and can't be fixed by moving the Droplet—you must create a new one from a Snapshot instead.

1. Locked out via SSH due to misconfigured password/root login? Use Droplet Console to fix it.
2. Enabled UFW before allowing OpenSSH and lost connection? Use Droplet Console to disable UFW.
3. Created a new user but forgot sudo or SSH keys? Test both before disabling root login.
4. Forgot to add the line to /etc/fstab? Swap disappears after reboot.

Best Practices

After completing all setup steps in this guide, immediately create a Droplet Snapshot to preserve the hardened configuration as a golden image. Snapshots cost $0.06/GiB per month—very affordable compared to the time saved if you need to rebuild. Snapshots let you rapidly create identical pre-configured Droplets in the future (for example, during scale-out) without repeating SSH keys, user creation, firewall, and timezone steps every time. Always enable DigitalOcean Cloud Firewall as an additional layer alongside UFW, since it's free and operates at the network edge before traffic reaches your Droplet. This shields your server and reduces processing load. Also enable Monitoring and set Alert Policies to notify you by email when CPU or disk usage approaches limits—both free features that alert you to problems before users notice. For SSH keys, generate separate keys for each device you use to connect (e.g., work laptop, home desktop) instead of using one key everywhere. If a device is lost or compromised, you can remove only that key from authorized_keys or the Control Panel, leaving other devices unaffected. For teams that repeatedly create Droplets like this, consider writing the entire setup as a cloud-init user data script, attaching it when creating the Droplet via Advanced Options. This automates user creation, firewall configuration, timezone setup, and swap initialization on first boot, eliminating manual steps and the risk of human error during repetition. Finally, don't forget to configure unattended-upgrades to run continuously—server security isn't a one-time task but an ongoing responsibility throughout the Droplet's lifetime.

• Create a Droplet Snapshot after setup as a golden image—costs only $0.06/GiB/month.
• Enable DigitalOcean Cloud Firewall alongside UFW for free, network-edge defense.
• Enable Monitoring and set Alert Policies (free) for CPU and disk warnings.
• Use separate SSH keys per device so compromised devices don't affect others.

Get $200 Free Credit →