PharosVPN
§04 · for individuals

one operator · a handful of nodes · same binaries

Your own VPN, in one evening.

You don't need a team, a cluster, or a budget. The --personal preset trims the controller down to one operator, sensible defaults, and a single nearest region. The engine is the engine: the same binaries an enterprise runs.

what you get

A controller on your laptop, a node in the cloud.

  • One controller (coxswain) running on your laptop, a home server, or a tiny private box — wherever you keep your other things.
  • One or two VPN nodes (node) on cloud VMs you create yourself. Any provider; coxswain doesn't call a cloud API on your behalf.
  • The caravel client on your devices — released for macOS, Linux, and Android (iOS builds for device; OpenWRT and OPNsense have installable plugins) — fed by account sync, a QR code, or a .pharos file. Pick whichever source you prefer; the engine doesn't care.
  • The embedded relay running inside coxswain, on by default. If your controller can already reach the internet, you don't need a remote relay.
  • A self-hosted dashboard on the controller — your fleet, live sessions, and any alerts — served on localhost, with zero inbound ports.

defaults of --personal

What the preset sets for you.

Regions1, nearest
Idle nodesnone
ProtocolsAmneziaWG by default; XRay optional
Relayembedded in coxswain
Account syncon
Adminsone (you)
Audit retention30 days
Metrics retention7 days
Endpoint rotationoff — available if you turn it on

how this differs from --enterprise →

threat model · be honest

What PharosVPN protects against — and what it doesn't.

It protects

  • Network-level surveillance and DPI on the path between you and your nodes — AmneziaWG and XRay/REALITY are both designed to resist active probing.
  • Compromise of a single VPN node. A breached node cannot mint certs, impersonate coxswain, or read other nodes' configs.
  • Compromise of the relay. A breached remote relay sees only ciphertext profile bundles and traffic metadata.
  • Loss of the controller. Tunnels keep serving from disk. You can rebuild later from a backup of coxswain's SQLite + CA.

It doesn't protect

  • Compromise of your laptop while coxswain is unlocked. The CA key lives there. Treat it like an SSH key.
  • Your cloud provider learning that you run a VPN endpoint. A node on a public IP is, by definition, public.
  • Application-layer fingerprinting. The protocols obfuscate the transport, not the apps you run over it.

one VM, one command

The shortest path.

# on your laptop or a small private box
git clone https://github.com/PharosVPN/coxswain
cd coxswain && make
./cox init --personal

# create a VM on any cloud provider, then:
./cox ssh-key                      # prints coxswain's SSH public key
# add that key to the VM's authorized_keys

./cox nodes add user@my-vm.example.net
# coxswain SSHes in, installs node, signs a CSR, starts the service.
# every operation after this is mTLS gRPC — SSH was install-only.

controller commands run today · pre-alpha, expect rough edges

install guide →