Fortochka
Private VPN
A Service Run
by Hand
A private VPN for friends and family works fine until it grows past a handful of people. Every new device meant an SSH session, a shell script, a config file mailed by hand. Nobody knew how much traffic anyone had used, an expired subscription was something you remembered or forgot, and when someone said "it stopped working" the only way to find out why was to log into the server and read the interface state yourself.
A Boss and
Its Workers
Rather than one script that does everything, the service is split in two. On every VPN node runs an agent: a small HTTP service exposing exactly six operations, listening only inside a management-only WireGuard tunnel — from the outside its port does not exist. Separately runs the boss: the database, the scheduler, and the Telegram bot people actually talk to. The boss initiates all communication; agents only answer. Crucially, the boss is not in the traffic path — if it dies, the VPN keeps carrying packets and only accounting stops.
Tests
183 boss · 77 agent
Agent operations
the entire contract
Traffic through the boss
control plane only
Nodes managed
production and lab
The agent has no public surface
It binds only to the tunnel address, so scanning the server finds nothing on its port — verified from outside. Its six operations are the whole API: list peers, create, enable, disable, stats, diagnose. The auth token is compared with a constant-time function rather than plain equality, because string comparison leaks its answer through timing.
Failure of the control plane is not failure of the service
The boss holds the database and drives everything, but no packet passes through it. Take it offline and existing tunnels keep working; only accounting and notifications pause. The same principle decides what happens to a silent agent: no fresh data means nobody gets disconnected for exceeding a quota — the admin gets a warning instead, because acting on missing data is worse than acting late.
Accounting that survives a restart
WireGuard counters reset whenever the interface restarts, which would read as a user suddenly spending negative traffic. Usage is therefore accumulated against a stored baseline rather than read directly, and a counter that moved backwards is recognised as a restart rather than an anomaly.
Running
The service runs for a small group of real people across two nodes. The site is public; the service itself is not open for sign-ups, and the code stays private because it describes a live deployment.
Questions
about the architecture?
Happy to walk through why the agent lives behind a tunnel, what happens when it goes quiet, and why the traffic counters needed a baseline instead of a plain read.