Asia VPNAsiaVPNGet app
All posts

Run Your Own OpenVPN Server on a DigitalOcean Droplet

4 min read

Running your own VPN server is genuinely easy now. One script does the whole thing: certificate authority, server config, firewall rules, and a ready-to-use client profile. On a DigitalOcean droplet you can be connected in about ten minutes.

Whether you should is a separate question, and this guide answers that too - at the end, because the answer depends on what the setup actually gives you.

What you need

  • A DigitalOcean account (referral link - free credit for you, a kickback for us if you stay)
  • An SSH key added to it (password login on a public-facing box is asking for trouble)
  • A terminal

1. Create the droplet

In the DigitalOcean control panel, create a droplet with:

  • Image: Ubuntu 24.04 LTS
  • Plan: Basic → Regular → the cheapest tier. OpenVPN is not CPU-hungry for a handful of clients, and 512 MB of RAM is plenty. Bandwidth, not RAM, is what you will run out of.
  • Region: wherever you want to appear to be. This is the one choice that actually matters for performance - pick the region closest to you, not to the sites you visit, unless you are specifically after geo-unblocking.
  • Authentication: SSH key.

Note the droplet's public IPv4 address, then connect:

ssh root@YOUR_DROPLET_IP

2. Run the install script

angristan/openvpn-install is the script most people use. It supports Debian, Ubuntu, Fedora, CentOS Stream, Rocky, AlmaLinux, Arch and a few others, and it needs systemd plus the TUN module - both present on a stock DigitalOcean droplet.

curl -O https://raw.githubusercontent.com/angristan/openvpn-install/master/openvpn-install.sh
chmod +x openvpn-install.sh
./openvpn-install.sh interactive

Read the script before you run it. This is a general rule for anything you pipe onto a root shell, and it applies here even though this particular script is well-known and widely audited.

The interactive menu asks a handful of questions. The defaults are sensible; these are the three worth thinking about:

Protocol - UDP or TCP. Take UDP. It is faster and it is the right answer unless you are on a network that blocks it.

Port. The default is 1194/UDP. If you expect to connect from hotel or corporate Wi-Fi, 443/TCP is the port that survives restrictive firewalls, because blocking it would break the whole web. You pay for that in speed.

DNS. Whatever you pick here is what your clients will resolve through. The script offers Cloudflare, Quad9, AdGuard and others, plus the option to run a self-hosted Unbound resolver. Self-hosted Unbound is the only choice where the DNS queries do not leave your machine.

When it finishes, a .ovpn file lands in /root/. That single file contains everything the client needs, including the keys.

Or skip the menu

The script also has a non-interactive CLI, which is what you want if you are rebuilding this box more than once:

./openvpn-install.sh install --port 443 --protocol tcp --dns quad9

The project warns that CLI flags are not covered by a stability guarantee, so if you are baking this into automation, pin to a specific commit rather than tracking master.

3. Get the profile onto your device

From your own machine, not the droplet:

scp root@YOUR_DROPLET_IP:/root/client.ovpn .

Then import it:

  • Android: OpenVPN for Android
  • iOS: OpenVPN Connect
  • macOS: Tunnelblick or Viscosity
  • Windows: the official OpenVPN community client
  • Linux: openvpn --config client.ovpn

Treat the .ovpn file like a password. Anyone holding it can connect as you. Do not email it to yourself and do not drop it in a cloud drive.

4. Add and remove people

Every device should get its own profile. That way revoking one does not lock out the others:

./openvpn-install.sh client add laptop
./openvpn-install.sh client add phone --password   # encrypts the private key
./openvpn-install.sh client list
./openvpn-install.sh client revoke old-phone       # disconnects immediately

Revocation takes effect straight away through the OpenVPN management interface - the revoked client is dropped mid-session rather than surviving until it reconnects.

5. Lock the box down

The script handles OpenVPN's own firewall rules. The rest of the droplet is still your problem:

# If you enable DigitalOcean Cloud Firewall, open the VPN port you chose
# (1194/UDP by default) AND the SSH port - or you will lock yourself out.

apt update && apt upgrade -y
systemctl status openvpn-server@server   # confirm the service is running

Turn off password authentication for SSH if the droplet was not created with a key, and set up unattended upgrades. A VPN server that never gets patched is a worse deal than no VPN at all.

That is the short version. The full list - including the two Ubuntu traps that silently undo the sshd_config you just edited - is in Hardening a Public VPS.

What this actually gets you

This is the part most tutorials skip.

You get: a machine you control, in a region you chose, with no third party logging your traffic. Your ISP sees one encrypted connection to one IP. If you want a VPN to reach a home lab or to have a stable IP for some allowlist, this is exactly the right tool.

You do not get anonymity. Quite the opposite. A commercial VPN puts you in a pool of thousands of users behind one IP address - that crowd is the privacy mechanism. Your droplet has a single IP used by you alone, registered to your DigitalOcean account, paid with your card. Every site you visit sees one consistent identifier that resolves to a datacentre range. From a fingerprinting point of view that is more identifying than your home connection, not less. What a VPN is and is not covers why the crowd matters.

You do not get geo-unblocking that lasts. Streaming services block datacentre IP ranges wholesale, and DigitalOcean's ranges have been on those lists for years.

You trade one trust relationship for another. Instead of trusting a VPN provider, you trust DigitalOcean - who can see the same traffic at the hypervisor level, and who has your billing details.

So: self-host when you want control over a machine that is yours. Use a commercial VPN when you want to blend into a crowd on mobile, on public Wi-Fi, or across many exit locations. They solve different problems, and running your own server does not make you invisible.


Cover photo by Taylor Vick on Unsplash.

Keep reading