If you're already automating infrastructure, you don't want WireGuard setup to be the one thing that still requires SSH and manual configuration. TunnelFleet brings the same automated-provisioning approach to VPN servers.
WireGuard setup breaks automation pipelines
Most IaC tools can create VMs, but bootstrapping WireGuard correctly still requires manual steps or a custom Ansible playbook.
SSH dependencies in provisioning scripts
Any automation that requires SSH access adds complexity: key management, security group rules, wait-for-port logic.
Firewall rules are easy to get wrong
iptables/nftables rules for WireGuard NAT require attention. A wrong rule breaks routing silently.
Managing WireGuard configs at scale
As the number of servers grows, keeping WireGuard configurations consistent and correct becomes a separate maintenance burden.
TunnelFleet uses cloud-init — the standard cloud VM bootstrapping mechanism — to provision WireGuard. This is the same approach you would take writing a production-ready Ansible role, but without the maintenance overhead of building and maintaining that role yourself.
The provisioning is SSHless by design. TunnelFleet calls the cloud provider API, passes a cloud-init script as user-data, and polls for completion via the API. No SSH, no ports to wait on, no jump hosts.
Typical Ansible approach
- name: Install WireGuard
apt:
name: wireguard
state: present
- name: Generate WireGuard keys
shell: wg genkey
register: private_key
- name: Get public key
shell: echo "$PRIVATE_KEY" | wg pubkey
register: public_key
- name: Configure WireGuard interface
template:
src: wg0.conf.j2
dest: /etc/wireguard/wg0.conf
mode: 0600
- name: Enable IP forwarding
sysctl:
name: net.ipv4.ip_forward
value: "1"
sysctl_set: yes
- name: Configure UFW
ufw:
rule: allow
port: "51820"
proto: udp
# ... more tasks ...
# Requires SSH, become, and a correctly
# configured Ansible inventoryTunnelFleet approach
# Everything above happens automatically
# via TunnelFleet cloud-init.
#
# From the TunnelFleet dashboard:
# 1. Click "New Server"
# 2. Choose region + size
# 3. Click "Deploy"
#
# Or via the TunnelFleet API (coming soon):
# POST /api/v1/servers
# {
# "name": "vpn-prod-01",
# "region": "lon1",
# "size": "s-1vcpu-1gb"
# }
#
# No SSH. No Ansible inventory.
# No become_user. No wait_for_connection.
# Keys generated on-server.
# Provisioning idempotent by cloud-init.Ansible requires SSH access, an inventory, and a playbook. TunnelFleet uses cloud-init, which runs before SSH is even available. The trade-off: TunnelFleet is less flexible than a custom Ansible role, but requires zero maintenance and no SSH dependencies.
TunnelFleet is a standalone provisioning tool. It doesn't integrate directly with Terraform or Ansible at this stage. You can use TunnelFleet alongside Terraform (e.g., Terraform creates other infrastructure, TunnelFleet handles VPN servers separately).
Yes. cloud-init is standard across all major cloud providers. Currently TunnelFleet supports DigitalOcean, and as new providers are added, the same cloud-init approach will be used.
Private keys are generated on the VM during cloud-init and stored at /etc/wireguard/privatekey with 0600 permissions. They are never transmitted to TunnelFleet. Only the public key is sent back via the provisioning callback.
cloud-init provisioning, no SSH dependencies, consistent deployments every time.