How to Set Up Your Own WireGuard VPN Server

To set up your own VPN server: launch a small cloud instance, install WireGuard, enable IP forwarding with NAT, and import the generated config on your devices. The whole thing takes about a minute if you script it. I built a tool that does exactly that, and this is how it works plus what broke along the way.

The tool is wireguard-anywhere, open source under MIT. It provisions the cloud instance, generates every key locally, writes your client configs and deletes the server again when you are done.

Why run your own

A commercial VPN moves your trust from an internet provider you can audit to a company you cannot. Running your own moves it to a machine you control, in a region you pick, with private keys that never leave your laptop.

What it does not do is make you anonymous. Traffic leaving the server is attributable to the cloud account paying for it. This hides you from the cafe wifi and from your ISP, not from a court order. Anyone selling it as anonymity is selling something.

What you need

• An account with AWS, Google Cloud or Azure, and its CLI installed
• openssl 3.x and jq
• Optionally qrencode, which turns the config into a QR code for your phone

You do not need WireGuard installed on your own machine. Keys are derived with OpenSSL X25519, which is verified in continuous integration against the RFC 7748 test vector and against wg pubkey itself.

Step 1: Get the tool

git clone https://github.com/shihabshahrier/wireguard-anywhere.git
cd wireguard-anywhere
./vpn.sh doctor

doctor checks every prerequisite and tells you what is missing.

Step 2: Authenticate with your cloud

aws configure --profile myvpn

Step 3: Launch a server

./vpn.sh up aws us-west-2 --profile myvpn --clients laptop,phone

Pick the region physically closest to you. Latency decides how a VPN feels; bandwidth almost never does. A server 200 ms away feels slow no matter how much throughput it has.

Measured on a fresh instance, the server goes from launch to serving traffic in 63 seconds.

Step 4: Connect your devices

./vpn.sh qr aws us-west-2 phone

Open the WireGuard app, tap the plus button, choose Scan from QR code, and toggle it on. On a laptop, import .vpn/clients/aws-us-west-2/laptop.conf instead.

Confirm it worked at ifconfig.me. It should show the server address, not yours.

Step 5: Delete it when you are done

./vpn.sh down aws us-west-2

This is the step most guides leave out, and it is the one that decides your bill.

Verifying it actually works

A running instance proves nothing. It tells you a hypervisor started a virtual machine; it says nothing about whether your software is on it. I learned this the hard way, three rebuilt instances in.

Three checks, in increasing order of confidence:

Check	What it proves
Instance state is running	Almost nothing
NetworkIn shows 38 to 40 MB	The bootstrap script ran and installed packages
wg show wg0 dump handshake field is non-zero	A client actually completed a handshake

The byte counters are the real proof. If inbound and outbound are roughly symmetric, the server is relaying traffic. Lopsided numbers mean it was downloading something, not tunnelling for you.

What it costs

Short version: about $0.42 a month at two hours a day, or $5.00 left running, using AWS Lightsail. Lightsail bundles the public IPv4 address and 1 TB of transfer into a flat price; the equivalent EC2 instance is $11.88 once the hourly address charge and disk are counted.

Because billing is hourly and you can only use one region at a time, the number of regions you keep does not drive the cost. Connected hours do. Ten regions on demand cost the same as one.

New cloud accounts run it free for a while: Azure gives 12 months of a free instance, AWS up to 6 months of credits, Google Cloud $300 for 90 days. Oracle Cloud Always Free is the only tier with enough bandwidth to run it indefinitely, at 10 TB a month.

I wrote up the full cost arithmetic separately, with the figures read from the pricing APIs rather than a marketing page: What a Personal WireGuard VPN Costs on AWS.

The bug that cost three instances

This is the part worth remembering if you script your own.

Lightsail hands user data to the cloud-init script handler rather than the config handler, and it concatenates its own bootstrap with yours into a single file. So a #cloud-config YAML payload gets executed line by line by dash, and package_update: is treated as a command that does not exist.

Worse, because your file is no longer first, its shebang becomes a comment in the middle of someone else's script. A single bash-only construct then aborts the entire run at line one:

part-001: 19: package_update:: not found
part-001: 55: set: Illegal option -o pipefail

Every symptom points the wrong way. The instance boots, reaches the running state, and reports healthy. Nothing is installed on it. The fix is to write the payload as strict POSIX sh, with no set -o pipefail and no process substitution, and to keep a dash -n check in CI so it cannot come back.

Can an agent do this for me

Yes. The repo ships an AGENTS.md with the full operating procedure, including how to verify a server really works rather than assuming it does. Point Claude Code, Codex or Cursor at the repo and it can provision, verify and tear down without supervision.