Absolutely feasible! Setting up a WireGuard VPN on a Hetzner server is a great project — it's exactly what Jeremy suggested as homework, and WireGuard is known for being relatively straightforward compared to older VPN solutions.

To help you effectively, a few questions:

1. Hetzner account — Do you already have one, or do you need to sign up? (They do require ID verification, which can take a bit)

2. SSH keys — Do you have an SSH key pair ready, or is that new territory for you?

3. Experience level — How comfortable are you with Linux command line basics? (No wrong answer — just helps me calibrate how much detail to provide)

4. Approach preference — Would you like to set up the server programmatically from SolveIt like Jeremy did in the lesson, or would you prefer using Hetzner's web dashboard to create the server and then configure WireGuard from there?

Let me know where you're at and we'll take it step by step!

Perfect, thanks for the honest answers! This is totally doable — we'll go step by step together.

Let's start with Step 1: Getting a Hetzner account and API key.

Head to console.hetzner.cloud and sign up for an account. They'll ask for some basic info and may require ID verification (this can take anywhere from minutes to a day depending on their queue).

Once you're logged in, you'll need to create an API token so SolveIt can talk to Hetzner programmatically. Here's where to find it:

1. In the Hetzner Cloud Console, look for "Security" in the left sidebar
2. Click on "API tokens"
3. Click "Generate API token"
4. Give it a name (like "solveit") and select Read & Write permissions
5. Copy the token immediately — they only show it once!

Once you have the token, add it as a secret in SolveIt:

• Go to your SolveIt dialog list (click the SolveIt logo)
• On the right side, you'll see a "Secrets" section
• Add a new secret with name HETZNER and paste your API token as the value

Let me know when you've got that done (or if you hit any snags along the way), and we'll move on to SSH keys!

Excellent! Now let's tackle Step 2: SSH keys.

SSH keys let you securely connect to your server without a password. Let's first check if you already have one on your SolveIt instance.

Run this in a code cell:

!cat ~/.ssh/id_*.pub

This will show any existing public keys. What do you see — does it print out a key (a long string starting with ssh-rsa or ssh-ed25519), or does it say "No such file or directory"?

Perfect! You already have an SSH key set up (ssh-ed25519). That makes things easier.

Now we need to add this key to your Hetzner account so you can access servers you create. Here's how:

1. Copy that entire key (the line starting with ssh-ed25519)
2. Go back to the Hetzner Cloud Console
3. In the left sidebar, click "Security" again
4. This time click "SSH keys"
5. Click "Add SSH key"
6. Paste your key and give it a name (like "solveit")

Once you've added it, we'll be ready to start writing the Python code to create your server!

Let me know when that's done.

Yes, exactly right! You want the entire line starting with ssh-ed25519 all the way through to the end. What you have in that screenshot looks perfect.

The format is: ssh-ed25519 [long string of characters] [comment]

Go ahead and click the button to add it, and you should be all set!

Great question! Here's the roadmap from where we are now:

What we've done ✓

1. Created Hetzner account + API token
2. Set up SSH key and added it to Hetzner

What's left

3. Install Python packages — Get the hcloud library so we can talk to Hetzner from SolveIt

4. Write cloud-init config — This is a script that automatically sets up your server when it's created (installs software, configures firewall, etc.)

5. Create the server — A few lines of Python to spin up your €5/month machine

6. Wait & connect — Verify the server is running and you can SSH into it

7. Install WireGuard — Set up the VPN software on your new server

8. Configure WireGuard — Generate keys and create the VPN configuration

9. Connect a device — Set up your phone/laptop to use your new VPN

Steps 3–6 will closely follow what Jeremy did in the lesson. Steps 7–9 are the "interesting" part where you'll learn about WireGuard specifically.

Does that look manageable? Ready to move on to step 3?

Yes, exactly! Let's install the hcloud library so we can control Hetzner from Python.

Run this in a code cell:

!pip install hcloud

Once that finishes, let me know and we'll move on to importing it and connecting to your Hetzner account!

Requirement already satisfied: hcloud in /app/data/.local/lib/python3.12/site-packages (2.12.0)
Requirement already satisfied: python-dateutil>=2.7.5 in /usr/local/lib/python3.12/site-packages (from hcloud) (2.9.0.post0)
Requirement already satisfied: requests>=2.20 in /usr/local/lib/python3.12/site-packages (from hcloud) (2.32.5)
Requirement already satisfied: six>=1.5 in /usr/local/lib/python3.12/site-packages (from python-dateutil>=2.7.5->hcloud) (1.17.0)
Requirement already satisfied: charset_normalizer<4,>=2 in /usr/local/lib/python3.12/site-packages (from requests>=2.20->hcloud) (3.4.4)
Requirement already satisfied: idna<4,>=2.5 in /usr/local/lib/python3.12/site-packages (from requests>=2.20->hcloud) (3.11)
Requirement already satisfied: urllib3<3,>=1.21.1 in /usr/local/lib/python3.12/site-packages (from requests>=2.20->hcloud) (2.6.2)
Requirement already satisfied: certifi>=2017.4.17 in /usr/local/lib/python3.12/site-packages (from requests>=2.20->hcloud) (2025.11.12)

Yes, the instructor's cloud-init config is a great starting point! It sets up all the essentials: firewall, automatic updates, useful tools, and SSH access.

You'll just need to customize a couple of things:

1. Hostname — Pick a name for your server (can be anything you like, e.g., nathan-vpn)
2. SSH key — Use your key instead of Jeremy's

Before we write the code, let's first connect to Hetzner and grab your SSH key. Run this:

import os
from hcloud import Client

client = Client(token=os.environ['HETZNER'])

Then let's see what SSH keys are registered in your account:

client.ssh_keys.get_all()

What do you see? There should be at least the key you just added.

[<hcloud.ssh_keys.client.BoundSSHKey object at 0x7734ed4b2ed0>]

Perfect! Now let's get the actual key object so we can use it. Run this:

sshkey = client.ssh_keys.get_all()[0]
sshkey.name

This will show you the name of your SSH key. What does it say?

Great! Now let's set up the cloud-init configuration. First, pick a hostname for your server — this can be anything you like. For example: nathan-vpn.example.com or just my-vpn-server.

What would you like to name your server?

Perfect! nathan-vpn is a great choice — simple and descriptive.

Now let's create the cloud-init configuration. This is the script that will automatically set up your server when it boots for the first time.

Run this to create the config (it's based on Jeremy's setup):

hostname = 'nathan-vpn'

cinit = f'''hostname: {hostname}
preserve_hostname: false
package_update: true
users:
- name: ubuntu
  shell: /bin/bash
  ssh_authorized_keys:
  - {sshkey.public_key}
  sudo:
  - ALL=(ALL) NOPASSWD:ALL
apt:
  sources:
    apt-fast:
      source: ppa:apt-fast/stable
runcmd:
- |
  echo "export EDITOR=/usr/bin/vim
  export TERM=xterm-256color" >> /home/ubuntu/.bashrc
  export DEBIAN_FRONTEND=noninteractive
  echo 'apt-fast apt-fast/maxdownloads string 10' | debconf-set-selections
  echo 'apt-fast apt-fast/dlflag boolean true' | debconf-set-selections
  echo 'apt-fast apt-fast/aptmanager string apt-get' | debconf-set-selections
  apt-get install -y --no-install-recommends apt-fast aria2
  apt-fast -y upgrade
  apt-fast -y install unattended-upgrades vim-nox ripgrep software-properties-common build-essential git curl tmux htop openssh-client
  ufw --force reset
  ufw default deny incoming
  ufw default allow outgoing
  ufw allow 22/tcp
  ufw allow 80/tcp
  ufw allow 443/tcp
  ufw --force enable
- |
  cat > /home/ubuntu/.ssh/config << EOF
  Host *
  SetEnv TERM=xterm-256color
  ServerAliveInterval 60
  ServerAliveCountMax 30
  StrictHostKeyChecking no
  AddKeysToAgent yes
  ForwardAgent yes
  GSSAPIAuthentication no
  EOF
  chmod 600 /home/ubuntu/.ssh/config
  chown ubuntu:ubuntu /home/ubuntu/.ssh/config'''

This sets up your server with essential tools, a firewall, and automatic updates. Ready to create the server next?

Absolutely! Let's walk through it section by section. I'll start with the first part:

hostname: nathan-vpn
preserve_hostname: false
package_update: true

This is actually YAML (a configuration format), not Bash yet. These lines tell cloud-init:

• Set the server's hostname to nathan-vpn
• preserve_hostname: false means it's okay to change the hostname if needed
• package_update: true means run apt update to refresh the list of available software

users:
- name: ubuntu
  shell: /bin/bash
  ssh_authorized_keys:
  - {sshkey.public_key}
  sudo:
  - ALL=(ALL) NOPASSWD:ALL

This creates a user called ubuntu who:

• Uses Bash as their shell (/bin/bash)
• Can log in using your SSH key (no password needed)
• Has passwordless sudo access (can run admin commands without typing a password)

Does this make sense so far? Want me to continue to the apt and runcmd sections where the actual Bash commands live?

Great question! Here's how it works:

It's the same key — just stored in multiple places.

1. When you ran cat ~/.ssh/id_*.pub earlier, you saw your public key stored on SolveIt
2. You then copied that same public key to Hetzner's console
3. Now, sshkey.public_key retrieves it from Hetzner and puts it in the cloud-init config

When the server boots, it will have your public key in its authorized_keys file. Your private key stays on SolveIt (in ~/.ssh/id_ed25519).

When you SSH from SolveIt to your server, SolveIt proves it has the matching private key, and the server says "yep, you're allowed in!"

Think of it like:

• Public key = a lock (you can put copies of it everywhere)
• Private key = the only key that opens those locks (keep it safe in one place)

Does that clear it up?

Exactly right! You have two options:

1. Add it to Hetzner — Upload your local PC's public key to Hetzner's SSH keys section, then reference both keys when creating the server

2. Add it directly to cloud-init — You could list multiple keys under ssh_authorized_keys:

ssh_authorized_keys:
- ssh-ed25519 AAAA... (SolveIt key)
- ssh-ed25519 BBBB... (local PC key)

You can also add keys later by SSHing into the server and editing ~/.ssh/authorized_keys directly.

Ready to continue with the cloud-init walkthrough, or shall we move on to creating the server?

Let's continue! Next is the apt section:

apt:
  sources:
    apt-fast:
      source: ppa:apt-fast/stable

This adds a PPA (Personal Package Archive) — a third-party software repository — for apt-fast. apt-fast is a faster version of apt that downloads packages in parallel using aria2.

Now we get to the runcmd section — this is where the Bash commands live. The | symbol means "everything indented below this is a multi-line string":

echo "export EDITOR=/usr/bin/vim
export TERM=xterm-256color" >> /home/ubuntu/.bashrc

• echo "..." prints text
• >> /home/ubuntu/.bashrc appends that text to the .bashrc file (which runs every time you open a terminal)
• This sets vim as the default text editor and configures the terminal color support

export DEBIAN_FRONTEND=noninteractive

Tells apt not to ask interactive questions during installation (important since there's no human to answer them!)

Want me to continue with the apt-fast configuration lines next?

You're right, I jumped ahead too fast. Let me back up.

What is apt?

apt is Ubuntu/Debian's package manager — it's how you install, update, and remove software on Linux. Think of it like an app store you use from the command line. For example:

• apt install vim installs the vim text editor
• apt update refreshes the list of available software
• apt upgrade updates all your installed software to the latest versions

About the multi-line string confusion

I explained that poorly! You're right that each line is an individual command. The | just means "treat the following indented lines as one block of text." When cloud-init runs it, each line still executes as a separate command, one after another — like if you typed them into a terminal yourself, pressing Enter after each one.

So it's a multi-line string that contains multiple commands, not one giant command.

What is Debian?

Debian is a Linux distribution. Ubuntu is actually based on Debian, so they share a lot of tools — including apt. When you see DEBIAN_FRONTEND, it's referring to how apt interacts with users.

Want me to explain what "noninteractive" means in that context before we continue?

Excellent observation — you've spotted something important!

Look closely at this:

echo "export EDITOR=/usr/bin/vim
export TERM=xterm-256color" >> /home/ubuntu/.bashrc

This is actually one command. The clue is the quotation marks. The echo command starts, then the " opens, and everything until the closing " is the text being echoed — including the line break. So this single echo command writes two lines of text to the file.

Compare that to:

export DEBIAN_FRONTEND=noninteractive

This is a new command because it's not inside anyone else's quotes — it starts fresh with export.

The rule: Look for where quotes open and close. Text inside quotes (even across multiple lines) is part of one command. A new command starts when you're outside quotes and see a new command word like export, apt-get, echo, cat, etc.

Does that help clarify the difference?

Exactly right! You've nailed it.

In Bash:

• Double quotes "..." allow special characters (like newlines) to be interpreted
• Single quotes '...' treat everything literally as plain text

So when the instructor wanted to write two lines into .bashrc, double quotes let them include an actual line break. The debconf-set-selections commands use single quotes because they just need plain text strings — no special interpretation needed.

Ready to continue with the next chunk of commands?

Next are these three lines:

echo 'apt-fast apt-fast/maxdownloads string 10' | debconf-set-selections
echo 'apt-fast apt-fast/dlflag boolean true' | debconf-set-selections
echo 'apt-fast apt-fast/aptmanager string apt-get' | debconf-set-selections

These pre-configure apt-fast before it's installed. Normally when you install apt-fast, it asks you questions like "how many simultaneous downloads?" But since we set DEBIAN_FRONTEND=noninteractive, there's no one to answer!

So debconf-set-selections lets us provide the answers in advance:

• Max 10 simultaneous downloads
• Enable the download flag
• Use apt-get as the underlying package manager

The | (pipe) takes the output of echo and feeds it as input to debconf-set-selections.

Next:

apt-get install -y --no-install-recommends apt-fast aria2

• apt-get install installs packages
• -y means "yes to all prompts" (again, no human to answer)
• --no-install-recommends keeps things minimal by skipping optional extras
• apt-fast aria2 are the two packages being installed (aria2 is the download accelerator that apt-fast uses)

Shall I continue with the upgrade and main software installation lines?

Next:

apt-fast -y upgrade

This updates all existing software to the latest versions. Using apt-fast instead of apt makes it faster since we just installed it.

apt-fast -y install unattended-upgrades vim-nox ripgrep software-properties-common build-essential git curl tmux htop openssh-client

This installs a bunch of useful tools:

• unattended-upgrades — automatically installs security updates
• vim-nox — the vim text editor (without GUI support, smaller)
• ripgrep — a super fast search tool
• software-properties-common — lets you add PPAs
• build-essential — compilers and tools needed to build software
• git — version control
• curl — download files from the web
• tmux — lets you run multiple terminal sessions
• htop — a nice system monitor
• openssh-client — so your server can SSH to other machines

Want me to continue with the firewall (ufw) section next?

Next is the firewall configuration using ufw (Uncomplicated Firewall):

ufw --force reset

Resets any existing firewall rules to start fresh. --force skips the "are you sure?" prompt.

ufw default deny incoming
ufw default allow outgoing

These set the defaults:

• Block all incoming connections (unless we specifically allow them)
• Allow all outgoing connections (your server can reach the internet)

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp

These punch holes in the firewall for specific ports:

• Port 22 — SSH (so you can connect to your server)
• Port 80 — HTTP (regular web traffic)
• Port 443 — HTTPS (secure web traffic)

ufw --force enable

Turns on the firewall with these rules.

One thing we'll need to add later for WireGuard is a port for VPN traffic (usually 51820). But we can do that after the server is running.

Shall I continue with the final SSH config section?

Ah, good eye! I actually simplified the cloud-init config and left out the UV installation section that was in the instructor's version. Here's what that section looks like:

- |
  sudo -u ubuntu -H bash << EOF
  curl -LsSf https://astral.sh/uv/install.sh | sh
  EOF

Let me break this down:

• sudo -u ubuntu -H bash — runs the following commands as the ubuntu user (not root)
• << EOF ... EOF — this is called a "here document." Everything between the two EOF markers is treated as input
• curl -LsSf https://astral.sh/uv/install.sh — downloads the UV installation script
• | sh — pipes (feeds) that script directly to sh to run it

UV is a very fast Python package installer made by Astral. It's a modern replacement for pip.

Would you like me to add this to your cloud-init config, or are you happy to skip it for now? You can always install UV later if you need it.

The final section sets up SSH configuration for the ubuntu user:

- |
  cat > /home/ubuntu/.ssh/config << EOF
  Host *
  SetEnv TERM=xterm-256color
  ServerAliveInterval 60
  ServerAliveCountMax 30
  StrictHostKeyChecking no
  AddKeysToAgent yes
  ForwardAgent yes
  GSSAPIAuthentication no
  EOF
  chmod 600 /home/ubuntu/.ssh/config
  chown ubuntu:ubuntu /home/ubuntu/.ssh/config

First, cat > /home/ubuntu/.ssh/config << EOF writes everything until EOF into the file .ssh/config. This configures how SSH behaves when your server connects to other machines:

• Host * — apply these settings to all hosts
• SetEnv TERM=xterm-256color — sets terminal colors
• ServerAliveInterval 60 — send a keepalive every 60 seconds so connections don't drop
• ServerAliveCountMax 30 — try 30 times before giving up
• StrictHostKeyChecking no — don't ask "are you sure?" when connecting to new servers
• AddKeysToAgent yes — remember SSH keys
• ForwardAgent yes — lets you use your local SSH keys through the server (useful for git)
• GSSAPIAuthentication no — disables a slow authentication method

Then the last two lines — want to guess what chmod 600 and chown do?

You're right on both counts!

chmod 600

chmod changes file permissions. 600 means:

• Owner can read and write (6)
• Group can do nothing (0)
• Others can do nothing (0)

SSH is picky about this — it refuses to use config files that others can read, for security.

chown ubuntu:ubuntu

chown changes ownership. The format is user:group. Since we ran these commands as root, the file would be owned by root. This changes it to be owned by the ubuntu user.

About the GitHub config

The instructor's version includes:

Host github.com
User git
Port 22
Hostname github.com
TCPKeepAlive yes

This makes it easier to use git with GitHub from your server. If you plan to clone repos or push code from your VPN server, it's handy to include. But for just running WireGuard, you won't need it.

Would you like to add it, or skip it for now?

Good thinking — it's a useful default to have!

Root vs regular user:

root is the superuser account on Linux — it can do anything without restrictions. Think of it like the administrator account on Windows.

A regular user (like ubuntu) has limited permissions. They can:

• Read/write their own files
• Run most programs
• But can't install software, change system settings, or access other users' files

Why it matters:

Running as root is dangerous — one typo could break your system. So best practice is:

• Do normal work as a regular user
• Only use sudo (which temporarily gives you root powers) when you need to do admin tasks

In cloud-init, some commands run as root (like installing packages), but we use sudo -u ubuntu when we want things owned by the regular user.

Ready to actually create your server now, or any other questions first?

I've compared your script with the instructor's version. It looks great — everything matches!

What you have:

• ✓ Hostname set to nathan-vpn
• ✓ Your SSH key
• ✓ apt-fast setup
• ✓ Same package list (including extras like grep, sed, cron, sqlite3)
• ✓ Firewall rules
• ✓ UV installation
• ✓ SSH config with GitHub block

The only difference is the hostname (yours is nathan-vpn, instructor's was mytest.fast.ai), which is intentional.

Ready to create the server?

Great! First, we need to format the cloud-init config properly. The instructor used a validation function, but let's keep it simple:

c = f"#cloud-config\n{cinit}"

This just adds the required #cloud-config header.

Next, choose your datacenter. The instructor used Ashburn, Virginia. Let's see what's available:

loc = client.locations.get_by_name('ash')
loc.description

Run these and let me know what you see!

The validation function checks that your cloud-init config is valid before you try to create the server.

It does this by:

1. Downloading the official cloud-init schema (a definition of what fields are allowed)
2. Parsing your YAML config
3. Checking that your config matches the schema

This catches typos early. For example, if you accidentally wrote perserve_hostname instead of preserve_hostname, the validator would tell you "unexpected field" rather than you finding out later when the server doesn't work as expected.

Would you like to add the validation step, or are you comfortable skipping it since we've reviewed the config together?

Yes! Since it ran without any errors, your cloud-init config is valid. If there were problems, it would have raised a ValidationError.

Now let's create the formatted config and choose your datacenter:

c = f"#cloud-config\n{cinit}"
loc = client.locations.get_by_name('ash')
loc.description

Run this and let me know what location it shows!

'{\n  "$schema": "http://json-schema.org/draft-04/schema#",\n  "$id": "https://raw.githubusercontent.com/canonical/cloud-init/main/cloudinit/config/schemas/versions.schema.cloud-config.json",\n  "oneOf": [\n    {\n      "allOf": [\n        {\n          "properties": {\n            "version": {\n              "enum": [\n                "v1"\n              ]\n            }\n          }\n        },\n        {\n          "$ref": "https://raw.githubusercontent.com/canonical/cloud-init/main/cloudinit/config/schemas/schema-cloud-config-v1.json"\n        }\n      ]\n    }\n  ]\n}\n'

{'$schema': 'http://json-schema.org/draft-04/schema#',
 '$id': 'https://raw.githubusercontent.com/canonical/cloud-init/main/cloudinit/config/schemas/versions.schema.cloud-config.json',
 'oneOf': [{'allOf': [{'properties': {'version': {'enum': ['v1']}}},
    {'$ref': 'https://raw.githubusercontent.com/canonical/cloud-init/main/cloudinit/config/schemas/schema-cloud-config-v1.json'}]}]}

Good question!

yaml.load() parses a YAML string and converts it into a Python object (usually a dictionary).

The Loader parameter tells it how to do the parsing. There are several options:

• FullLoader — the safe default; loads standard YAML without allowing arbitrary Python code execution
• SafeLoader — even more restrictive
• UnsafeLoader — allows YAML to execute Python code (dangerous!)

In older versions of PyYAML, you could just write yaml.load(d) without specifying a loader, but that was risky. Now it requires you to be explicit about which loader to use.

So yaml.load(d, Loader=yaml.FullLoader) is saying: "Parse this YAML string safely."

Want to see what it produces? Try running:

yaml.load(cinit, Loader=yaml.FullLoader)

You'll see your cloud-init config converted to a Python dictionary!

The schema you fetched is actually just a "wrapper" that points to the real schema. See this part?

{'$ref': 'https://raw.githubusercontent.com/canonical/cloud-init/main/cloudinit/config/schemas/schema-cloud-config-v1.json'}

The $ref means "the actual rules are over here." Let's fetch the real schema:

real_schema = xget('https://raw.githubusercontent.com/canonical/cloud-init/main/cloudinit/config/schemas/schema-cloud-config-v1.json').text
json.loads(real_schema)

Warning: it's big — cloud-init has lots of possible options! But you'll see things like which fields are allowed, what types they should be (string, boolean, list), etc.

'Ashburn, VA'

No problem — we can check directly with the API! Run this:

for loc in client.locations.get_all():
    print(f"{loc.name}: {loc.description}")

This will list all available Hetzner Cloud locations.

fsn1: Falkenstein DC Park 1
nbg1: Nuremberg DC Park 1
hel1: Helsinki DC Park 1
ash: Ashburn, VA
hil: Hillsboro, OR
sin: Singapore

Good thinking! This is an important consideration for a VPN. Let me search for current information on this.Your instincts are valid! Here's what I found:

The Five Eyes issue:

* The Five Eyes (FVEY) is a surveillance agreement between the USA, the UK, Canada, Australia, and New Zealand. All five countries have signed the multilateral UK - USA Agreement, a treaty for joint cooperation in signals intelligence.

So the US, Canada, UK, Australia, and New Zealand share surveillance data with each other. * Some of the worst countries for VPNs to be based are members of the Five Eyes, 9 Eyes, and 14 Eyes surveillance alliance. These countries work together to snoop on each other's citizens and are extremely proactive in passing intrusive surveillance laws.

Better options for privacy:

* Switzerland is an EU country that is known for its robust consumer privacy laws. The country has no mandatory data retention directives that apply to VPNs and never enforced the EU's Data Retention Directive. This allows VPNs based in Switzerland to maintain rock-solid no-logging policies.

* Romania is often overlooked, but it ranks highly among VPN-friendly countries due to its privacy laws and strong support for internet freedom. Romania has no data retention requirements and offers a secure environment for VPN providers to operate without government interference.

The trade-off:

Hillsboro, Oregon (US) = lowest latency for you, but Five Eyes jurisdiction. Helsinki, Finland = EU with GDPR, but higher latency and still 14 Eyes. Singapore = outside Five Eyes, decent privacy laws, but farther away.

Hetzner's German locations (Falkenstein, Nuremberg) are in 14 Eyes territory too.

For a personal VPN where you control the server and don't log anything yourself, the jurisdiction matters less than for a commercial VPN service. The main risk would be government seizure of the server. For casual privacy use, Hillsboro is probably fine. For higher threat models, consider a different provider with Swiss or Romanian servers.

What's your comfort level?

Good choice! Hillsboro will give you the best latency, and for a personal VPN where you control everything, it's perfectly reasonable.

Let's set up the location and create your server:

loc = client.locations.get_by_name('hil')
loc.description

Run that to confirm, then we'll create the server!

'Hillsboro, OR'

Now let's create the server! We need to specify:

• The SSH key
• The location (Hillsboro)
• The hostname
• The server type (cpx11 is the cheapest at ~€5/month)
• The operating system image (Ubuntu 24.04)
• The cloud-init config

from hcloud.images import Image
from hcloud.server_types import ServerType

svr_r = client.servers.create(
    ssh_keys=[sshkey], 
    location=loc, 
    name=hostname, 
    server_type=ServerType(name="cpx11"),
    image=Image(name="ubuntu-24.04"), 
    user_data=c
)

Run this and let me know what happens! It should return almost instantly, but the server will take a minute or two to fully boot and run cloud-init.

Great question — let's make sure you're not overpaying or underpowered. Let me research this.Great news — WireGuard is incredibly lightweight! Here's what I found:

WireGuard Resource Requirements:

* "The most recent free version of WireGuard is significantly more resource-efficient, requiring no more than 512MB of RAM and one virtual CPU." * "Working fine for me in 64MB VPS using Nyr's script." Some users report * "Works fine on 128mb ram, 2gb storage."

* * "A one core processor and 1G of memory should be enough, unless you are intending to have a whole lot of connections."

* * "VPN performance is much more processor-dependent vs RAM driven... The encryption and I/O are the main bottlenecks."

Hetzner Pricing (US locations like Hillsboro):

My Recommendation:

The CPX11 (€4.49/month, ~$5 USD) is overkill for a personal VPN with 1-2 users doing browsing and streaming. WireGuard barely uses any resources. The main consideration is the 1TB traffic limit — if you're streaming a lot of video through the VPN, you might hit that.

Rough math: 1TB = about 333 hours of HD streaming (at ~3GB/hour). For two people, that's still plenty for casual use.

Want to stick with CPX11, or does 2TB traffic on CPX21 sound safer for your streaming habits?

Not a dumb question at all — it's important to know before you invest the time!

Yes, WireGuard is very easy to use on all of those:

• Windows 11 — There's an official WireGuard app you can download from wireguard.com
• iPhone/iPad — Official WireGuard app in the App Store

The setup process is the same across devices: you either scan a QR code or import a small config file, and then it's just a toggle switch to connect/disconnect.

We'll generate those config files (and a QR code for your phone) as part of the setup later.

Ready to create the server now?

Perfect! Run this to create your server:

from hcloud.images import Image
from hcloud.server_types import ServerType

svr_r = client.servers.create(
    ssh_keys=[sshkey], 
    location=loc, 
    name=hostname, 
    server_type=ServerType(name="cpx11"),
    image=Image(name="ubuntu-24.04"), 
    user_data=c
)

Let me know what you get back!