Self-Hosted VPN on DigitalOcean: WireGuard Guide

Build your own WireGuard VPN on a DigitalOcean droplet for $4/month, with the full setup, the IPv6 and DNS leaks most guides miss, and an honest comparison against a commercial VPN.

By Tudor Uzun

Founder and Senior Software Engineer, IP Trackers

Published August 11, 2026Editorial standards

Running your own VPN on a cloud server sounds like the purist option: no provider to trust, no shared IP address, no subscription. On a DigitalOcean droplet it takes about twenty minutes and costs four dollars a month. But most guides skip the part that actually matters, which is what a self-hosted VPN protects you from and what it does not. This guide covers the full WireGuard build, the two leaks nearly every hand-rolled setup ships with, and an honest comparison against paying a commercial provider instead.

What "self-hosted VPN" actually means

A self-hosted VPN is a server you rent, running VPN software you configure, that your devices connect to. Your traffic leaves your home or phone network inside an encrypted tunnel, surfaces at that server, and continues to the internet wearing the server's IP address instead of yours.

That is exactly the same shape as a commercial VPN. The difference is ownership. With NordVPN or Proton you are one of thousands of people sharing an exit address, and you are trusting the provider's logging policy. With a droplet you are the only person on the machine, and the party you are trusting is DigitalOcean, plus yourself to configure it correctly.

That last clause carries more weight than people expect. A commercial VPN client is a tested product. A hand-written WireGuard config is whatever you typed. The two most common mistakes both produce a tunnel that looks like it is working while quietly leaking, and both are covered below.

The honest tradeoff nobody puts in the headline

Self-hosting is frequently sold as the more private option. For one specific threat it is, and for another it is clearly worse.

A droplet is registered to your name, your email address, and your payment card. Its IP address is allocated to your account. If anyone with legal authority asks DigitalOcean who was using that address, there is a complete and truthful answer available, and it is you. There is no crowd to hide in, because you are the only person who has ever used that address.

A shared commercial VPN exit inverts this. Hundreds of people leave through the same address simultaneously, so the address alone does not identify anyone. Whether that helps depends entirely on whether the provider keeps records connecting sessions to subscribers, which is the entire purpose of an audited no-logs policy.

So the accurate framing is this: a self-hosted VPN gives you a private connection, not an anonymous one. It hides your traffic from the network you are sitting on. It does not hide your identity from a determined investigator, and it never will, because you signed up for the server with your own details.

What DigitalOcean can still see

Removing a VPN provider from the picture does not remove every third party. It replaces one with another, and it is worth being precise about what the new one is positioned to observe.

DigitalOcean operates the physical machine, the hypervisor it runs on, and the network it sits behind. They cannot read the contents of your encrypted sessions any more than your ISP can, because TLS terminates at the sites you visit rather than at the droplet. But your traffic exits their network unencrypted at the tunnel boundary in the sense that matters for metadata: they are positioned to observe which addresses your droplet connects to, how much data moves, and when.

In practice, a large cloud provider has no commercial interest in analysing one customer's outbound connections, and doing so at scale would be expensive and pointless. The realistic concern is not routine snooping but compelled disclosure: they know exactly who you are, so a valid legal request produces your identity immediately. That is the structural difference from a provider that accepts cash and holds no account records.

None of this makes a droplet a bad choice. It makes it a different choice, and the honest summary is that you are moving your trust from a privacy company to an infrastructure company, while gaining full control over the configuration in between.

What a droplet VPN genuinely fixes

• Hostile local networks. Hotel, airport, cafe, and conference Wi-Fi cannot read or modify your traffic. This is the strongest and least arguable benefit.
• ISP visibility. Your home provider sees an encrypted stream to one address instead of every site you visit. In countries where ISPs are required to retain browsing records, that is a real change.
• A dedicated, clean IP. Nobody else can get your address rate-limited, CAPTCHA-walled, or blocked, because nobody else is using it. Anyone who has fought Google CAPTCHAs on a busy commercial VPN exit will recognise the appeal.
• Reaching your own services. A tunnel into a server you control is a clean way to expose a private database, admin panel, or home service without publishing it to the internet.
• A fixed address for allowlists. Some services let you restrict logins to specific IPs. A droplet gives you one that does not change.

What it does not fix

• Anonymity. Covered above. The droplet has your name on it.
• Streaming catalogues.Datacenter IP ranges are published and widely known. Streaming platforms block them in bulk, and DigitalOcean's ranges are among the best documented on the internet. Expect this to fail.
• Censorship circumvention. Plain WireGuard has a distinctive handshake. A network that blocks VPNs by protocol fingerprint will block yours, and you have no obfuscation mode to fall back on.
• Browser-level tracking. Cookies, fingerprinting, and logged-in accounts identify you regardless of which IP you arrive from.
• Location variety. One droplet is one country. Wanting to appear in three places means paying for three servers and switching configs by hand.

When self-hosting is the right call

Self-host when your goal is control and your threat model is the network between you and the internet. Concretely: you travel and use untrusted Wi-Fi, you want a stable IP for allowlisting, you are comfortable on a Linux command line, and you would rather trust your own configuration than a company's policy document. It is also simply a good way to learn how VPNs actually work, and that has value on its own.

When you should buy a commercial VPN instead

Buy one when you need any of: many exit countries, streaming access, obfuscation on a restrictive network, genuine distance between your identity and your traffic, or an app your family can use without your help. None of those are things a single droplet does well, and pretending otherwise would be dishonest. Our VPN comparison covers the providers worth considering if that describes you better.

Self-hosted against commercial, side by side

Read that table as a description of two different tools rather than a scoreboard. The self-hosted column wins on control and IP cleanliness. The commercial column wins on reach, convenience, and distance from your real identity. Plenty of people should run both, which is covered near the end.

What you need before you start

• A DigitalOcean account and a payment method.
• An SSH key pair. If you do not have one, generate it with ssh-keygen -t ed25519 before creating the droplet.
• Basic comfort with a terminal. You will edit files, run a handful of commands, and read error output.
• The WireGuard client for whichever devices you want to connect. It is available for Windows, macOS, Linux, iOS, and Android.
• About twenty minutes.

Choosing a droplet size

WireGuard is remarkably light. It runs in the Linux kernel, uses modern cryptography that is cheap on current hardware, and will comfortably saturate a gigabit link on a single shared vCPU. You are not buying CPU or RAM for this. You are buying transfer.

Every byte your devices send and receive through the tunnel counts twice against the droplet allowance, once inbound and once outbound. That is the single most misunderstood part of the cost model. The $4 tier with 500 GB of transfer therefore supports roughly 250 GB of actual browsing per month, which is generous for normal use and tight if you stream video through it daily.

Why region matters more than specs

Every packet you send takes a detour through the droplet before reaching its destination. That detour costs latency, and latency is set by physical distance. A droplet in Frankfurt when you live in Frankfurt adds a few milliseconds. The same droplet when you live in Sydney adds roughly 250 milliseconds to every request, which makes video calls unpleasant and interactive SSH sessions miserable.

Pick the region nearest to you, not the one in the country whose content you want. The exception is when appearing in a specific country is the entire point, in which case accept the latency knowingly. Geographic distance is a rough guide rather than a reliable one, since network paths do not follow maps: once a droplet is running, the quickest way to judge a region is to run ping YOUR_DROPLET_IP from your own terminal and compare. Droplets are cheap enough to create in two regions, measure, and destroy the loser.

Creating the droplet

In the DigitalOcean control panel choose Create, then Droplets. Select the current Ubuntu LTS image, the Basic shared-CPU plan, and the size you settled on above. Under authentication choose SSH key rather than password, and paste in your public key. Password authentication on a machine exposed to the public internet will be under automated attack within minutes of boot, and this one setting removes that entire class of problem.

Give the droplet a hostname you will recognise later. Once it finishes provisioning, note the public IPv4 address shown in the panel. That address is the endpoint your clients will connect to, and it is also the address the rest of the internet will see you as.

Locking down SSH before anything else

Connect as root, create a normal user, and give it sudo rights. Working as root permanently is how small mistakes become unrecoverable ones.

ssh root@YOUR_DROPLET_IP

adduser tunnel
usermod -aG sudo tunnel
rsync --archive --chown=tunnel:tunnel ~/.ssh /home/tunnel

apt update && apt upgrade -y

Then disable root login over SSH. Open /etc/ssh/sshd_config, set PermitRootLogin no and PasswordAuthentication no, and restart the service with systemctl restart ssh. Before you close your current session, open a second terminal and confirm you can log in as the new user. Locking yourself out of a fresh droplet is recoverable through the DigitalOcean console, but it is an annoying way to spend ten minutes.

Configuring the cloud firewall

DigitalOcean provides a network-level firewall that sits in front of the droplet, which is preferable to relying only on rules inside the machine. Create one under Networking, then Firewalls, and attach it to your droplet with these inbound rules:

• SSH, TCP 22, ideally restricted to your own address rather than open to everyone.
• WireGuard, UDP 51820. This must be UDP. Setting it to TCP is a common mistake and produces a tunnel that never completes a handshake.

Leave outbound rules permissive. The droplet needs to reach the whole internet on your behalf, which is the entire point.

WireGuard or OpenVPN on a droplet?

Both work. WireGuard is the right default in almost every case, and it is worth understanding why rather than taking it on faith.

WireGuard is roughly four thousand lines of code against OpenVPN's hundreds of thousands. That difference is not trivia: a smaller codebase is easier to audit and offers less surface to attack. It runs inside the Linux kernel rather than in userspace, which is most of why it is faster and why it barely touches the CPU on a $4 droplet. It uses one modern cipher suite with no negotiation, so there are no weak options to misconfigure. And it reconnects instantly when your device changes network, which is the difference between a tunnel that survives moving from Wi-Fi to mobile data and one that stalls.

OpenVPN retains exactly one meaningful advantage for this use case: it can run over TCP on port 443, where it is difficult to distinguish from ordinary HTTPS traffic. On a network that blocks VPN protocols by signature, that camouflage is the entire game, and WireGuard's distinctive UDP handshake gets it blocked. If you are specifically trying to get through a restrictive network, OpenVPN on 443 or a purpose-built tool like Outline will serve you better.

For everything else, WireGuard is faster, simpler, and easier to get right. The rest of this guide uses it.

Installing WireGuard

sudo apt install wireguard -y

That is the whole installation. WireGuard ships in the mainline Linux kernel, so there is no module to compile and no service stack to configure. The package provides the wg and wg-quick tools and nothing else you need to think about.

Generating the key pairs

WireGuard authenticates peers with public key cryptography. Every participant, server and client alike, has a private key it never shares and a public key it hands out. Generate the server pair first:

cd /etc/wireguard
umask 077
wg genkey | sudo tee server_private.key | wg pubkey | sudo tee server_public.key

Then generate a pair for each client. Keys are per device, not per person: your laptop and your phone each need their own.

wg genkey | sudo tee laptop_private.key | wg pubkey | sudo tee laptop_public.key

The umask 077 line matters. Without it the key files are world-readable, and a private key readable by every account on the box is not a private key. If you skipped it, fix the permissions with sudo chmod 600 /etc/wireguard/*.key.

Enabling IP forwarding

By default Linux will not pass packets between network interfaces, which means your droplet will accept tunnel traffic and then refuse to send it anywhere. Turn forwarding on permanently:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Miss this step and the symptom is distinctive: the handshake succeeds, wg show reports a recent handshake and rising byte counts, and yet nothing loads. If you ever see a working handshake with dead traffic, check forwarding first.

Writing the server config

Create /etc/wireguard/wg0.conf. Substitute the server private key and the client public key you generated above, and replace eth0if your droplet's public interface is named differently, which you can check with ip route get 1.1.1.1.

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# laptop
PublicKey = LAPTOP_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

The 10.8.0.0/24 range is a private network that exists only inside the tunnel. The server is 10.8.0.1, the first client is 10.8.0.2, and so on. Any private range works; this one is conventional and unlikely to collide with a home network, which is exactly why 192.168.x.x is a poor choice here.

Understanding the NAT rules

The PostUp lines are worth understanding rather than pasting blindly, because they are where most broken setups break.

The FORWARD rule permits packets arriving on the tunnel interface to be routed onward. The MASQUERADErule rewrites their source address from the private tunnel address to the droplet's public address before they leave. Without it, packets would reach their destination carrying a source of 10.8.0.2, and replies would be sent into a private range that no router on the internet can deliver to. This is the same address translation your home router performs, described in more depth in our guide to public and private IP addresses.

The PostDown lines simply remove those rules when the tunnel stops, so repeated restarts do not accumulate duplicates.

Starting the tunnel

sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0
sudo wg show

wg show should list the interface, its public key, the listening port, and your configured peer. There will be no handshake yet because no client has connected. Enabling the service means the tunnel returns automatically after a reboot, which you want.

Writing the client config

On the client device, create a config file with the client's private key and the server's public key. This is the reverse of the server file, and mixing up which key goes where is the single most common configuration error.

[Interface]
PrivateKey = LAPTOP_PRIVATE_KEY
Address = 10.8.0.2/32
DNS = 9.9.9.9

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = YOUR_DROPLET_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0 is what makes this a full VPN rather than a private link to one server: it tells the client to route everything through the tunnel. Narrowing it to 10.8.0.0/24 would produce a split tunnel where only traffic to the droplet itself uses the VPN, which is useful for some purposes and is not what you want here.

PersistentKeepalive = 25 sends a small packet every 25 seconds so that routers between you and the droplet keep the connection mapping alive. Without it, a tunnel that has been idle behind a home router often needs to be nudged before it starts passing traffic again.

Split tunnelling: routing only what you need

Full-tunnel routing sends everything through the droplet, which is usually what you want but not always. Two situations argue for splitting.

The first is bandwidth. If you only need the tunnel for specific work and you also stream a lot of video, routing everything through the droplet burns transfer allowance fast for no benefit. The second is latency: local services, a nearby game server, or a device on your own network are all worse off going halfway across a continent and back.

The AllowedIPs field on the client controls this, and it is more literal than it sounds. It is not an access rule; it is a routing table. Whatever ranges you list are the ranges the client sends through the tunnel, and everything else takes the normal path. Listing only your tunnel range keeps the VPN for reaching the droplet and its services while leaving general browsing on your local connection:

AllowedIPs = 10.8.0.0/24

You can be selective in the other direction too, listing specific destination ranges you want tunnelled. That is useful for reaching a private subnet without redirecting your whole connection.

Be clear-eyed about the consequence: with a split tunnel you are no longer hiding your browsing from the local network, because most of it never enters the tunnel. Split tunnelling is a convenience and performance feature, not a privacy one. If your reason for building this was untrusted Wi-Fi, keep the full tunnel.

DNS, and why most guides get it wrong

The DNS line is the difference between a working VPN and a VPN that broadcasts every site you visit to your ISP.

Routing your traffic through a tunnel does not automatically change which resolver your operating system asks for name lookups. If your laptop was configured to use your router's resolver, and you bring up a tunnel without specifying DNS, it will keep asking your router's resolver. Those queries go out over the tunnel, but they arrive at your ISP's infrastructure carrying the name of every domain you request. The payload is hidden and the destinations are not, which defeats a large part of the point.

You have two reasonable options. The simple one is to point the client at a public resolver, as the config above does. The thorough one is to run a resolver on the droplet itself, set DNS = 10.8.0.1 in the client, and have lookups resolved by a machine you control. The second is genuinely more private, since the public resolver never learns anything about you, but it is another service to maintain.

Either way, verify it rather than assuming. Our DNS leak test shows which resolver actually answered, and it is the only way to know the setting took effect. If the distinction between a resolver and a destination is not yet second nature, how DNS resolution works covers the mechanism that makes this leak so easy to miss.

The IPv6 leak almost every hand-rolled setup ships with

This is the most important section in the guide, and it is the one missing from most tutorials.

The config above tunnels 0.0.0.0/0, which is all IPv4 traffic. It says nothing about IPv6. If your home connection or mobile carrier provides IPv6, and most now do, then your device still has a working IPv6 path that does not go through the tunnel at all. Any site reachable over IPv6, which includes Google, Facebook, Netflix, and a large share of the modern web, will be reached directly, from your real address, completely outside the VPN.

The tunnel appears to work perfectly. An IPv4 address check shows the droplet. And a meaningful fraction of your browsing never enters the tunnel. This is precisely the failure mode our IPv6 leak test exists to catch, and on a self-built WireGuard setup it is the default outcome rather than an edge case.

There are two correct fixes.

Carry IPv6 through the tunnel. Enable IPv6 on the droplet, add a private IPv6 range to the server interface, add a matching ip6tables masquerade rule, and set the client to AllowedIPs = 0.0.0.0/0, ::/0. This is the better answer because it preserves IPv6 connectivity while protecting it.

Or disable IPv6 on the client while the tunnel is up, so there is no untunnelled path to leak through. Cruder, and it will break IPv6-only destinations, but it closes the hole.

What you must not do is leave AllowedIPs = 0.0.0.0/0 alone on a dual-stack device and assume you are covered.

Verifying the tunnel actually works

Bring the tunnel up on the client, then work through these checks in order. Do not skip to the end because the first one passed; the whole point is that a broken setup passes the first check.

Start on our home page, which shows the public address you are presenting. It should be the droplet's address. Then run the DNS leak test, the IPv6 leak test, and the WebRTC leak test. Together they cover the three ways a tunnel that looks fine can expose you. Is my VPN working runs the combined check if you would rather do it in one pass.

Checking your droplet's IP reputation

Cloud IP addresses are recycled. The address your droplet receives was almost certainly used by someone else before you, and you have no idea what they did with it. If the previous tenant ran a spam operation or got the address listed for abuse, you inherit that reputation on day one.

The symptoms are easy to misread as something else: sites throwing CAPTCHAs constantly, mail you send being rejected, or specific services refusing connections. Before blaming your configuration, run the address through our IP blacklist check to see whether it appears on the major DNSBLs, and our ASN lookup to confirm how it is classified.

The fix is refreshingly simple. Destroy the droplet and create a new one. You will get a different address, and since your entire setup is a few config files, rebuilding costs minutes. Keep copies of your keys and configs somewhere safe and this becomes routine rather than painful.

Worth knowing regardless: every DigitalOcean address is publicly identifiable as datacenter space through its ASN. Anything that checks for hosting ranges will flag you, which is why streaming does not work and why some sites treat you with suspicion. Our proxy and VPN detection check shows what those systems see when you connect.

Adding phones and tablets with a QR code

Typing a base64 private key into a phone keyboard is unpleasant. WireGuard's mobile apps scan QR codes instead. Install qrencode on the droplet, then render any client config to the terminal:

sudo apt install qrencode -y
qrencode -t ansiutf8 < /etc/wireguard/phone.conf

Scan it from the WireGuard app and the tunnel is configured. Be aware that this prints a private key to your terminal, so do not do it on a shared screen, and clear the scrollback afterwards.

Adding more devices without breaking the first

Each device needs its own key pair and its own address inside the tunnel range. Generate a new pair, add a second [Peer] block to the server config with the next address, and reload:

[Peer]
# phone
PublicKey = PHONE_PUBLIC_KEY
AllowedIPs = 10.8.0.3/32

sudo systemctl reload wg-quick@wg0

Resist the temptation to reuse one key pair across devices. Two peers presenting the same public key confuse the server's routing table, producing a connection that works for whichever device connected most recently and fails intermittently for the other. It is a genuinely confusing bug to diagnose and it is entirely avoidable.

What a kill switch means here

Commercial clients ship a kill switch that blocks all traffic if the tunnel drops. WireGuard has no such feature, because it is a protocol rather than an application. You implement the behaviour yourself with firewall rules on the client.

On Linux clients, wg-quick supports this directly: add PostUp and PostDownrules that permit outbound traffic only on the tunnel interface. On Windows, the official client has a "Block untunneled traffic" option that does the same job, and it is off by default. On mobile, Android offers "Always-on VPN" with "Block connections without VPN" in system settings, which is more reliable than anything the app can do by itself.

Whichever you use, test it by stopping the tunnel on the server and confirming the client loses connectivity entirely rather than silently falling back to your normal connection.

What this actually costs

The honest total is the droplet price plus your time. At $4 or $6 a month the server is cheaper than most commercial VPN subscriptions on monthly billing and more expensive than most on a multi-year plan, where good providers land between $1 and $3 a month.

So self-hosting is not usually the cheaper option in pure cash terms once you account for the discounts commercial providers offer on long commitments. It becomes cheaper when the droplet is doing other work anyway, which is a genuinely good reason to run one: a server hosting a side project can carry your VPN at no extra cost beyond transfer.

Watching the transfer allowance

Transfer is the one resource a VPN workload actually consumes. Because traffic is counted in both directions, streaming video through the tunnel burns allowance roughly twice as fast as intuition suggests. Video calls are similarly heavy.

DigitalOcean pools the allowance across all droplets on the account and bills overage separately, so a second droplet raises the shared ceiling. Check current overage rates on their pricing page before assuming a heavy month is cheap. Monitoring is available in the control panel, and watching it for the first month is worth the effort so you can size the droplet from evidence rather than guesswork.

The maintenance you are signing up for

This is the cost people underestimate. A commercial VPN is maintained by a company. Your droplet is maintained by you, permanently.

• Security updates. Run apt update && apt upgrade regularly, or enable unattended upgrades. An unpatched public server is a liability.
• Kernel reboots. Some updates need a restart. The tunnel returns automatically if you enabled the service, but the connection drops while it happens.
• Key rotation. When a device is lost or sold, remove its peer block. Nobody else will do this for you.
• Monitoring. If the droplet goes down while you are travelling, you have no VPN and possibly no internet at all if a kill switch is active.
• Backups. Keep your configs and keys somewhere safe so a rebuild is a ten-minute job.

Adding a second region without starting over

One droplet is one country, but nothing stops you running two. The efficient way is not to repeat this guide from scratch.

Once your first droplet is configured, take a snapshot from the DigitalOcean panel. A snapshot can be deployed into any region, so creating a second server in another country is a few clicks rather than another twenty minutes of setup. Snapshots are billed by size and the cost for a small droplet is negligible.

Two things must change on the clone. Generate a fresh server key pair so the two machines are not sharing an identity, and update each client config with the new droplet's public address and key. Reusing the server key across regions works technically but means one compromised machine exposes both, which defeats the point of separating them.

On the client side, keep one config file per region and switch between them in the WireGuard app. Only one tunnel should be active at a time. The apps handle this cleanly and it is the closest a self-hosted setup comes to the location switcher in a commercial client, though you are still choosing between two locations rather than ninety.

Snapshots are also the fastest answer to the blacklisted-IP problem described earlier. Destroy the droplet, deploy the snapshot fresh, and you have a working server on a new address in about two minutes, with no reconfiguration beyond the endpoint address in your clients.

Common failure modes and how to read them

No handshake at all. Almost always the firewall. Confirm UDP 51820 is open in the DigitalOcean firewall, and that you set UDP rather than TCP. Also check that the client endpoint has the right public address and port.

Handshake succeeds, no traffic flows. IP forwarding is off, or the masquerade rule is missing or naming the wrong interface. Verify with sysctl net.ipv4.ip_forward and sudo iptables -t nat -L POSTROUTING.

Everything works but DNS resolves nothing. The DNS line points at an unreachable resolver, or you set it to 10.8.0.1 without actually running a resolver there.

Works on Wi-Fi, fails on mobile data. Usually MTU. Some carriers use smaller packet sizes and fragmented WireGuard packets get dropped. Add MTU = 1380 to the client interface section and adjust from there.

Drops after a period of inactivity. Missing PersistentKeepalive on the client.

Some sites work, others do not. Suspect the IPv6 leak described above, or an IP reputation problem. The leak tests and the blacklist check distinguish between the two quickly.

Automated alternatives worth knowing

If the manual build is more than you want, several projects automate it and all of them support DigitalOcean as a target.

• Algo VPN provisions a hardened WireGuard server from a single command, including sensible firewall defaults. It is opinionated in a good way and handles IPv6 properly, which is its main advantage over doing this by hand.
• PiVPN is an interactive installer originally aimed at Raspberry Pi that works on any Debian or Ubuntu host. Friendly for a first attempt.
• Outline, from Jigsaw, uses Shadowsocks rather than WireGuard and is designed for censorship circumvention. Its manager app treats DigitalOcean as the default provider. Choose it if getting through a restrictive network matters more than raw throughput.

Using one of these does not change the tradeoffs discussed earlier. You still have a datacenter IP registered in your name, and you still need to verify for leaks afterwards.

Running both, which is what I would actually recommend

The two options solve different problems, and treating the choice as either-or is the mistake most of these guides make.

A droplet is excellent as your everyday tunnel on untrusted networks, for reaching your own infrastructure, and for anything needing a stable allowlisted address. A commercial provider is what you reach for when you need another country, a streaming catalogue, obfuscation on a network that blocks VPNs, or genuine separation between your identity and your traffic.

Running both costs a few dollars a month more than either alone and removes the compromises from both. If you only want one, choose based on the honest question: are you trying to secure a connection, or trying to be harder to identify? The first is the droplet. The second is not, and never was.

The verdict

A self-hosted WireGuard VPN on a DigitalOcean droplet is a genuinely good piece of infrastructure. It is fast, it is cheap, it gives you a clean dedicated address, and building it teaches you more about how tunnels work than any amount of reading. For public Wi-Fi and for keeping your browsing away from your ISP, it does the job completely.

It is not an anonymity tool, it will not get you into a foreign Netflix catalogue, and it will not help on a network that fingerprints and blocks VPN protocols. Anyone telling you otherwise is selling something.

Build it for the right reasons, verify it properly with the DNS, IPv6, and WebRTC leak tests rather than assuming, and keep a commercial subscription around for the jobs a single droplet cannot do.