DigitalOcean Reserved IP Guide 2026 — Static IP for Failover

Reserved IP คือ IP address คงที่ที่ DigitalOcean ผูกไว้กับบัญชีผู้ใช้แทนที่จะผูกกับ Droplet ตัวใดตัวหนึ่งโดยตรง

Reserved IP is a static IP address that DigitalOcean ties to your account rather than to a specific Droplet. This allows you to move the IP to a new Droplet instantly if your primary server fails, without waiting for DNS propagation. This guide explains how to reserve, attach, and migrate Reserved IPs with real doctl and API commands for implementing failover systems.

What is Reserved IP and How It Differs from Regular Public IP

When you create a Droplet on DigitalOcean, the system automatically assigns a public IPv4 address. This IP is tied directly to the Droplet itself. If you delete the Droplet, that IP is immediately returned to DigitalOcean's pool and cannot be reused. Even if you create a new Droplet in the same account, you'll get a new IP. This is normal for testing purposes, but becomes a real concern in production systems that frequently need to rebuild or replace servers. Every time the IP changes, you have to update DNS records, config files, firewall whitelists, and wait for the TTL to expire before all users see the new IP. This can take anywhere from minutes to hours depending on the TTL value. Reserved IP solves this by completely separating the IP from the Droplet's lifecycle. When you reserve an IP, it becomes an account-level resource, not tied to any specific Droplet. You can choose to assign it to any Droplet in the same region. Whenever you want to switch, just unassign it from the old Droplet and assign it to the new one—the DNS record pointing to the Reserved IP doesn't need any changes because the IP address remains the same. Unlike changing a regular public IP, you don't have to wait for DNS propagation. Important to note: Reserved IP is tied to a region, not to a specific Droplet. So you can assign it to any Droplet as long as that Droplet is in the same region where you reserved the IP (for example, if you reserve it in sgp1, it can only be used with Droplets in sgp1—you can't move it across regions). One Reserved IP can be attached to only one Droplet at a time.

• Regular public IP vanishes immediately when you delete the Droplet—cannot be reused
• Reserved IP is tied to your account, not to a Droplet, so you can move it to another Droplet with the same IP
• Can only be attached to Droplets in the same region where the Reserved IP was created

Pricing: Free When Attached to Droplet / $5/Month Unattached

From our hands-on testing — reserved IP pricing is straightforward and has two clear cases. First case: attaching it to an active Droplet—no additional cost. It's free as long as there's a Droplet backing it. Second case: leaving it unattached (not assigned to any Droplet)—DigitalOcean charges $5 per month, or $0.01 per hour, billed per-second just like regular Droplet billing. Why does DigitalOcean charge for unused Reserved IPs? Because IP addresses are a limited resource. If you could reserve IPs for free with no strings attached, many users would hoard IPs without actually using them, straining the already-limited IPv4 pool much faster. This fee is a mechanism to discourage unused reservations. One thing to know: Reserved IPv6 has no cost at all, whether attached or unattached. The IPv6 pool is much larger than IPv4, so there's no scarcity concern like with IPv4. If your architecture supports IPv6, using Reserved IPv6 instead of or alongside IPv4 can mitigate unexpected costs. A common oversight: after you delete a Droplet that had a Reserved IP attached, the Reserved IP doesn't get deleted with it. Instead, it automatically switches to unattached status and starts incurring $5/month charges. You should periodically check your Networking tab in Control Panel to verify no unused Reserved IPs are sitting around costing you money (pricing as of July 2026—check the provider's website for the latest rates).

• Attached to an active Droplet = free
• Unattached = $5/month or $0.01/hour for IPv4
• Reserved IPv6 is always free, whether attached or not
• Deleting a Droplet does not delete its Reserved IP—you must delete it manually if you don't need it
• Periodically check Networking > Reserved IPs to avoid paying for unused IPs

Reserving and Attaching a Reserved IP to a Droplet

You can reserve a Reserved IP three ways: through the Control Panel, via doctl CLI, or directly through the DigitalOcean API v2. In the Control Panel, go to Networking, select the Reserved IPs tab, then click Reserve IP Address. Choose your desired region (must match the Droplet's region) and pick a target Droplet if you want—or reserve it empty and attach later. For command-line users, use doctl (DigitalOcean's official CLI tool). Reserve with doctl compute reserved-ip create --region sgp1. The system returns the IP address. Then attach it to a Droplet with doctl compute reserved-ip-action assign <reserved-ip> <droplet-id>, where droplet-id comes from doctl compute droplet list. To detach, use doctl compute reserved-ip-action unassign <reserved-ip>. To delete it entirely (stopping unattached charges), use doctl compute reserved-ip delete <reserved-ip>. For automation via API (like writing custom failover scripts), call the REST API v2 directly with curl. Create a new Reserved IP with curl -X POST -H "Authorization: Bearer $DO_TOKEN" -H "Content-Type: application/json" -d '{"droplet_id":"DROPLET_ID"}' "https://api.digitalocean.com/v2/reserved_ips". To attach an existing Reserved IP to a new Droplet, send an action to that IP's endpoint: curl -X POST -H "Authorization: Bearer $DO_TOKEN" -H "Content-Type: application/json" -d '{"type":"assign","droplet_id":"NEW_DROPLET_ID"}' "https://api.digitalocean.com/v2/reserved_ips/45.55.32.11/actions". This approach works well for automated health-check scripts that reassign the IP if the primary Droplet goes down. After attaching a Reserved IP, verify inside the Droplet that the IP is bound to the network interface with ip addr show eth0. DigitalOcean adds it automatically through the metadata service—you typically don't need to configure anything at the OS level.

• Via Control Panel: Networking > Reserved IPs > Reserve IP Address
• doctl: doctl compute reserved-ip create --region sgp1 then assign with reserved-ip-action
• API: POST to /v2/reserved_ips or /v2/reserved_ips/{ip}/actions

Moving a Reserved IP Between Droplets with Zero Downtime

The main strength of Reserved IP is its ability to move from one Droplet to another without changing the IP address that users see. This is ideal for blue-green deployments where you want to switch traffic from an old version to a new version instantly. The typical workflow is: create a new Droplet, install and test the application using its temporary public IP (or via private VPC IP), and once you're confident everything works, issue the command to move the Reserved IP to the new Droplet. You can move it in a single command without separate unassign/assign steps. DigitalOcean supports direct reassignment with doctl compute reserved-ip-action assign <reserved-ip> <new-droplet-id>. The system handles the unassign from the old Droplet and assign to the new one in one operation. This switchover happens very quickly at DigitalOcean's internal network level—it's a routing change at the data center, not DNS propagation like a typical A record update. This makes the user-visible downtime far shorter than a DNS change. However, understand that "zero downtime" here means zero DNS propagation delay, not a guarantee of zero broken connections. Connections still in-flight on the old Droplet may drop during the switch if you don't have connection draining or session persistence in place. For truly high-availability systems, design your app to be stateless and support client-side retries—don't rely solely on Reserved IP. Before switching in production, test the new Droplet thoroughly during a maintenance window or use health checks to verify everything passes (web server, database, TLS certificate, environment variables) before switching for real. Once you flip the switch, all traffic goes to the new Droplet instantly. If problems emerge, you can reassign the IP back to the old Droplet just as quickly—rollback is a single command, much faster than fixing DNS.

• Reassign in one command with doctl compute reserved-ip-action assign—no need to unassign first
• Much faster than changing a DNS A record because no TTL propagation wait
• Always test the new Droplet thoroughly before switching for real
• In-flight connections on the old Droplet may drop if you lack connection draining

Example Use Case: High Availability

From our hands-on testing — a basic HA pattern using Reserved IP is an active-passive architecture with two Droplets: a primary Droplet that receives real traffic through the Reserved IP, and a standby Droplet that runs identical software and data but doesn't receive traffic. A monitoring script or health check continuously watches the primary. If it detects the primary is unresponsive (HTTP health check fails repeatedly, or the Droplet becomes unreachable via SSH), the script calls the DigitalOcean API to reassign the Reserved IP to the standby. Traffic then flows to the standby Droplet without end-users waiting for DNS changes. The failover script typically runs with an external monitoring tool like Uptime Kuma or a cron job on a third server (not on the primary or standby itself, because if your monitoring box fails alongside the primary, nobody can trigger the failover). When the health check fails, the script calls the reserved-ip-action assign endpoint pointing to the standby. This reduces RTO (Recovery Time Objective) compared to waiting for a human engineer to manually fix it. Another common use case is database failover: attach the Reserved IP to the Droplet running PostgreSQL or MySQL primary. When the primary fails, the replication system promotes a replica to become the new primary, then you reassign the Reserved IP to point to the new primary Droplet. Applications connecting via a connection string that specifies the Reserved IP don't need any reconfiguration—the IP still works normally. For systems that truly need multiple Droplets serving traffic simultaneously (not just standby failover), Reserved IP isn't the right fit because it attaches to only one Droplet at a time. Use a Load Balancer instead, which distributes traffic across multiple backends with built-in health checks.

1. Active-passive: primary receives real traffic, standby sits ready for failover
2. Monitoring script should run on a third machine to avoid failing with the primary
3. Works well with database replication—reassign Reserved IP after promoting a replica
4. Dramatically reduces RTO compared to manual fixes or DNS changes

When to Use This Feature (Real Use Cases)

Reserved IP is ideal for teams or developers wanting basic failover capability without the cost of a Load Balancer (which starts at $12/month). For small-to-medium projects with a single primary Droplet receiving real traffic, a Reserved IP attached to it costs nothing—unlike Load Balancer which charges every month regardless of usage. This makes Reserved IP more cost-effective for systems that don't need traffic distribution across multiple machines but do need a "backup" in case the primary fails. Another common use case is blue-green deployment. Teams that deploy new code by spinning up an entire new Droplet (instead of updating the old one in-place) benefit from Reserved IP as a traffic switch between old and new versions without touching DNS at all. This suits teams that deploy frequently and want instant rollback if bugs appear post-deployment. Another scenario is basic HA for self-hosted databases on Droplets where you're not ready to commit to a managed database or full multi-node cluster. Use Reserved IP on the primary database with a replica ready to promote if needed—faster to implement than a full managed database cluster. Conversely, if your system has high traffic and needs traffic distributed across multiple Droplets all the time (not just standby), or if your team wants native automated health checks without writing scripts, Load Balancer is better suited. Reserved IP is the right tool when you need simple, cost-free failover—not when you need active load distribution.

• Small-to-medium systems with a single primary Droplet needing failover without Load Balancer costs
• Blue-green deployments: switch traffic between old-new versions without touching DNS
• Basic HA for self-hosted databases before upgrading to a managed cluster
• Teams deploying frequently and needing fast rollback

Common Mistakes and How to Fix Them

The most common mistake is forgetting that unattached Reserved IPs cost $5/month. Many people reserve one for testing, forget to delete it, or delete the Droplet without realizing the Reserved IP persists in unattached status and starts accruing charges. The fix: set up billing alerts and periodically review Networking > Reserved IPs to catch unused ones. If you don't plan to use it again, delete it immediately with doctl compute reserved-ip delete. Second mistake: pointing your DNS A record to the Droplet's regular public IP instead of the Reserved IP from day one. This defeats the purpose—when you later want to switch Droplets, you still have to update DNS and wait for propagation. Lesson: configure DNS to point to the Reserved IP from the very start, even if you only have one Droplet and no failover plans yet. The cost of doing this upfront is zero (attached Reserved IPs are free), but it gives you flexibility for future scaling or failover without re-doing DNS. Third mistake: trying to attach a Reserved IP across regions, like one reserved in sgp1 to a Droplet in nyc1. You can't—Reserved IPs are region-locked. Fix: plan your regions carefully from the start. If you genuinely need to move across regions, you must reserve a new IP in the target region and update DNS completely. Fourth mistake: firewall rules (Cloud Firewall or ufw) referencing the Droplet's old public IP instead of the Reserved IP. After failover, those rules don't apply to the new Droplet. Better approach: write firewall rules using Tags instead of hardcoding IPs. Tags apply to all Droplets with that tag regardless of which physical Droplet it is. Fifth mistake: writing a failover script but never testing it before relying on it in production. You discover bugs or permission errors only when it's actually needed. Fix: rehearse your failover during a planned maintenance window at least once before depending on it in a real outage.

• Unattached Reserved IPs cost $5/month—set billing alerts and check regularly
• Point DNS to Reserved IP from day one, not the Droplet's public IP
• Cannot attach across regions—plan regions carefully from the start

Best Practices

First principle: configure DNS to point to the Reserved IP from day one of system setup, even if you have only one Droplet and no HA plan yet. The upfront cost is zero (attached Reserved IPs are free), but it gives you future flexibility for scaling or failover without re-doing DNS every time. Second: store API tokens for failover scripts securely—use environment variables or a secret manager, never hardcode them into source code that goes into version control. Restrict token permissions to the bare minimum needed (principle of least privilege) to limit damage if the token leaks. Third: write a runbook or documented failover procedure that the entire team can access. Specify exactly when to trigger manual failover versus letting the script handle it automatically, and document the rollback steps if failover causes new problems. This document is especially critical when the engineer familiar with the system is unavailable during an incident. Fourth: test your failover regularly, not just once at setup. Systems and dependencies evolve (OS updates, library versions, certificate expiration). Rehearsing failover at least quarterly confirms the system still works when it matters. Final principle: tailor your approach to system scale. Small systems benefit from Reserved IP with a simple monitoring script. As systems grow and need to distribute traffic across many Droplets simultaneously, consider switching to Load Balancer with built-in health checks and automatic failover—less to maintain yourself. And always delete unused Reserved IPs immediately to avoid lingering charges.

• Configure DNS to point to Reserved IP from day one even without HA plans—zero cost, maximum flexibility
• Store API tokens in environment variables or secret manager, never hardcode them
• Write a documented runbook for failover and rollback that your team can access

Get $200 Free Credit →