Sign in Sign up

Platform

Virtual Private Networks

Every brintOS organization gets its own private network. Any machine launched by an org member can join it at boot — it gets a stable private address, an internal DNS name, and a direct line to every other machine on the network, whether that machine is running in the next cubicle or on another continent. No public IPs, no port forwarding, no VPN client to install: the network is part of the machine.

The problem: your VMs can't see each other

A brintOS machine runs inside a browser tab, and browser tabs are islands. Two machines booted by two teammates — or two tabs on the same laptop — have no route to each other. That is fine when a machine is a solo workstation, and useless the moment you want a database VM and an app VM, a client and a server, a build farm, or anything else that looks like more than one computer.

The org VPN dissolves the islands. It is an encrypted layer-3 overlay scoped to your organization: every member machine that joins it appears on one flat private network, exactly as if they were plugged into the same switch. From inside a machine there is nothing to learn — it's Linux networking. ip addr shows the VPN interface, ping db.acme.internal answers, psql -h db.acme.internal connects.

How a machine joins

  • Automatic at boot. If your machine belongs to an organization with the VPN enabled, it comes up with a vpn0 interface already configured — address assigned, routes installed, DNS search domain set. There is no daemon to start and no credential to paste; membership is derived from the same org roles that govern who can launch the machine in the first place.
  • Stable identity. Each machine gets a stable private IPv4 (from the org's 100.96.0.0/11-style pool) and IPv6 ULA, plus an internal DNS name of the form <machine>.<org>.internal. Relaunch the machine tomorrow, from a different browser on a different continent, and it keeps its address and name.
  • Per-session keys. Every tab session runs its own WireGuard-style keypair, minted at boot and discarded at shutdown. The org control plane distributes public keys and endpoints; private keys never leave the tab.

What you build with it

  • Multi-VM clusters. A three-node database rig, a message-queue topology, a Kubernetes-the-hard-way class — boot each node as its own machine, and they find each other by name. The cluster survives snapshots: fork the whole set and the fork gets its own addresses on the same org network.
  • Client-server development. Run the backend in one machine and hit it from a teammate's machine — or from the same person's second tab — over the VPN, with real sockets and real latency instead of a mock.
  • Shared team services. Keep a long-lived machine running your package mirror, license server, or staging database, reachable by every org member's machine at a fixed internal name — and by nothing outside the org.
  • Pair debugging on live machines. SSH from your machine into a colleague's (with their access grant) over the private network. No public exposure, no tunnel gymnastics; the reachability is scoped to the org and to the ACLs you set.

How packets move

The wire path is the same substrate as Network-as-a-service: the kernel's packets leave the tab over WebTransport (HTTP/3) with a WebSocket fallback, framed per IETF MASQUE connect-ip. The difference is where they go. Public NIC traffic exits to the internet through a regional terminator; VPN traffic is switched between org machines and never exits at all.

  • Relayed by default. Each org network is anchored to a mesh of brintOS relays (the same edge POPs the NIC uses, fronted by anycast). Two machines in the same region switch packets through one relay hop; cross-region traffic rides the cloud backbone between relays. Relays forward ciphertext — the machine-to-machine encryption terminates only in the tabs.
  • Direct where possible. When two machines' browsers can reach each other (same LAN, or NAT traversal succeeds), the tunnel upgrades to a direct browser-to-browser path and the relay drops out of the loop. Same-office teammates get single-digit millisecond RTTs between their VMs.
  • Internal DNS, no MITM. *.<org>.internal resolves against the org control plane over the machine's stub resolver. Traffic between machines is end-to-end encrypted between the two kernels' sessions; unlike the free HTTPS fetch tier, there is no CA to install and nothing in the middle to trust.

Access control

Membership follows the org, and reachability follows policy. By default every member machine can reach every other member machine — the same-switch model. Org admins can tighten that with network ACLs: tag machines (prod, staging, ci) and write allow rules between tags and ports, so the staging database accepts 5432 from staging machines and nothing else. Rules are enforced at both ends of every tunnel — a packet a rule forbids is dropped before it leaves the sending tab. Removing a member from the org revokes their machines' keys immediately; there is no lingering credential to rotate.

What it costs, where it runs

The org VPN is included in Team and Enterprise plans — every machine an org member launches can join, with no per-machine charge. Relay bandwidth between your machines is metered under the same egress allowance as the paid NIC; direct browser-to-browser traffic is free, since it never touches us. On Enterprise, the relay mesh and the control plane can run inside your own VPC, so org traffic — relayed or not — never crosses brintOS infrastructure at all.

The point

A machine you can share like a repo is good. A network of them you can share like a repo is a different thing entirely: a whole environment — services, topology, and all — that a new teammate joins by accepting an org invite and clicking Launch. The browser keeps every machine sandboxed from the world; the org VPN is the one deliberate hole, and it points only at your team.