Xprem VPN gives a service running on your laptop a public HTTPS address —
updates.example.com, with a real certificate — by routing it through an AWS
load balancer and a WireGuard tunnel you control.
It runs entirely in your AWS account. Nothing is hosted for you, no traffic passes through anyone else's servers, and there is no account to sign up for. The menu bar switch is the only thing that decides whether the world can reach you.
client ──TLS──▶ NLB :443 ──▶ 10.100.0.2:3000
│
VPC route 10.100.0.0/24
▼
gateway instance (Elastic IP)
│ WireGuard
▼
your Mac 10.100.0.2 ──▶ your service :3000
Some things are better served from a machine you can see. A staging build, an update feed, a demo, a service whose data should not leave the building. What those have in common is that they want a real hostname and a real certificate — and that they should not be reachable at three in the morning when nobody is watching.
Your own domain, your own ACM certificate, a Route53 record. Not a random subdomain that changes every restart.
The tunnel is a switch, not a daemon that quietly holds the door open. Disconnect and the hostname stops answering.
Your Mac dials out. Nothing has to change on your router, and a new IP address from your ISP re-pins itself.
No middleman, no per-seat pricing, no rate limit. The only cost is the AWS resources, itemised below.
Register more than one workstation and the load balancer spreads across them. Adding one does not interrupt the others.
The gateway is an Auto Scaling group of one. A failed instance is replaced, keeps the same address and the same identity.
An AWS Network Load Balancer holds your certificate and terminates TLS. Behind it, a small gateway instance forwards to a private address that lives on your Mac, reached over WireGuard. The tunnel dials outward, so your network needs no changes.
It needs a fixed public IP address, because AWS answers the IKE negotiation rather than starting it — and a laptop behind a residential NAT does not have one. AWS does support a certificate-based gateway with no address for exactly this case, but it requires an ACM Private CA at roughly USD 400/month, more than everything here combined. WireGuard inverts the direction and costs nothing extra.
The package carries its own WireGuard. macOS has no in-kernel implementation, so the
data plane is wireguard-go — MIT-licensed, built from a pinned and
checksummed release, shipped inside the installer and signed with the same identity.
No Homebrew, no AWS CLI, no Node, no Python.
wg-quick? On macOS it is a bash script that needs
bash 4, which macOS has not shipped since 2007 for licensing reasons. Rather than drag
in a second installer, everything it did is implemented directly against wireguard-go's
documented UAPI socket. The config file written to /etc/wireguard/wg0.conf
is still wg-quick's format, so the standard tools can drive the same tunnel if you have
them.
Moving a tunnel needs root. Rather than a background daemon with broad powers, the app
gets one sudoers rule scoped to two exact command lines — raise this
interface, drop this interface — pointing at a root-owned helper in
/Library/PrivilegedHelperTools, a directory no package manager takes
ownership of. Your WireGuard private key is generated on your Mac and never leaves it.
About ten minutes, most of it AWS building the load balancer. The installer stops at the first thing that fails and names it, rather than reporting success on a half-built tunnel.
| A Mac | macOS 13 or later, Apple silicon or Intel |
| An administrator account | one password prompt, covering three files |
| An AWS account | the resources cost roughly USD 26/month |
| A domain in Route53 | in that account, as a public hosted zone |
| A service to publish | running on your Mac, on a known port |
10.100.0.2 — not 127.0.0.1. A
service bound to loopback is invisible to it, and the only symptom is a health check
that never passes. With Docker that means -p 3000:3000, not
-p 127.0.0.1:3000:3000.
In IAM, create a policy from the published least-privilege deploy policy, attach it to a new user, and create an access key. A dedicated key, not an administrator one. If you already have a working AWS CLI profile, skip this.
You need a public Route53 zone for the domain you will serve from. The installer finds it on its own; it only has to exist.
Signed and notarized. It places the app, a command-line tool, the privileged helper and the tunnel, then opens the setup window by itself.
Credentials, the hostname to serve, your service's port, and — optionally — an address to email when the gateway fails and whether the tunnel should come back after a reboot.
It covers the tunnel configuration, your private key, and the narrow sudoers rule. Nothing else asks again.
The last stage checks every hop in the order traffic travels: tunnel up, gateway answers, load balancer healthy, hostname returns 200. A clean run means it is live right now.
wiregard-mini-vpn install --domain updates.example.com --port 3000
wiregard-mini-vpn status
wiregard-mini-vpn peersXprem VPN itself is free software and costs nothing. What you pay is AWS, billed to your own account, and you can see every resource it creates in the published CloudFormation template before you run it.
| Resource | Why it is there | USD / month |
|---|---|---|
| Network Load Balancer | Holds the certificate, terminates TLS, gives the hostname something stable to point at | ~16.00 |
t4g.micro gateway |
Terminates the WireGuard tunnel and forwards into the VPC | ~6.00 |
| Elastic IP | The fixed address your Mac dials, so a replacement gateway keeps the same endpoint | ~3.60 |
| Route53, ACM, SSM, CloudWatch | DNS record, certificate, peer registry, alarms | ~0.50 |
| Total | plus load balancer capacity units and data transfer | ~26 |
Alarms and their notification topic are only created if you give an address to notify.
Nothing is created that you did not ask for, and uninstall removes all of
it, including the parameters the gateway wrote for itself.
GPL-3.0-or-later Xprem VPN is free software. You may use it, read it, change it, and pass it on — and anyone you give a binary to has the same rights, including the right to the source.
| Run it for anything | Commercial use included. There is no seat count, no licence key, and nothing phones home. |
| Read every line | Including the part that runs as root and the template that spends your money. |
| Change it | And ship your changes, under the same licence. |
| No warranty | As with all free software. It is tested, but it is yours to run. |
Third-party components are listed in full in the repository. wireguard-go is
MIT, Sparkle is MIT, the AWS SDK is Apache-2.0, and the golang.org/x
libraries are BSD — all compatible with GPLv3. Notably Apache-2.0 is compatible with
GPLv3 and not GPLv2, which is part of why version 3 was the only sensible choice.
This is a small project with a clear shape and a lot of obvious next steps. If any of these are interesting, they are genuinely open — not a wishlist someone is quietly already doing.
The AWS side is platform-neutral and the tunnel logic is ordinary Go. What is missing is the platform-specific interface handling and a front end.
The load balancer is most of the cost. A design that keeps the static address and the certificate without it would change the economics.
Step one is still "create an IAM policy". That is a reasonable ask for an engineer and a wall for everyone else.
When it misbehaves on someone else's machine there is no single command that collects what a maintainer would need to see.
CI checks everything except the part that actually deploys. A throwaway-account test would have caught more than one bug earlier.
Bug reports are contributions. What you did, what happened, and the output of
wiregard-mini-vpn status is plenty to start from.
Email xpremvpn@maragato.ca, or
open an issue or pull request on
GitHub.
make check is the gate — vet, formatting, tests, and CloudFormation
linting over both templates. If that passes, the change is in good shape.