A VPN data plane that moves 20+ Gbit/s from one box and still fits on a €5 VPS, with production clients for Android, iOS, Windows and Linux. License it inside your own product, or put real apps in front of servers you already run.
Most tunnels quote throughput for a whole machine. We quote it per core, because that is the number that decides your infrastructure bill. At peak the node moved 20 Gbit/s and still left a fifth of the box idle — what ran out first was the machine generating the load. The same binary runs on a five-euro VPS.
Not per box. Your bandwidth bill scales on this number, not on a marketing one.
Android, iOS, Windows, Linux — including the iOS extension memory ceiling everyone else fights.
TLS 1.3 over OpenSSL. Ours is the framing and the session handling, not the crypto.
Clients resolve a live entry point from a signed bundle. Blocking one address does not remove the service.
Entry points hold no secrets, access is per device, revocation lands at the node.
From a €5 VPS to bare metal, same binary, no separate build.
Full benchmark reports, methodology and JFR profiles are available on request under NDA.
You already have a product — parental control, MDM, mobile security, a filtering browser. It needs a tunnel, and the tunnel is not your business. Drop ours in.
VpnService lifecycle handled: backgrounding, network changes, doze, per-app rulesNEPacketTunnelProvider built to the extension memory ceiling, not against itYou run servers and sell access, and your users are stuck pasting config strings into a generic client. Give them a real app with your name on it instead.
Your people need work systems from a kitchen table in another country. The usual answer is a concentrator that trusts anyone who got inside. Here access is granted to a device, not to a network.
Zero-copy fast path, role-based QoS, active queue management. Runs on a €5 VPS or a Raspberry Pi 5.
Standard primitives, no home-grown cryptography. Framing and session management are ours; the crypto is not.
Android VpnService, iOS NEPacketTunnelProvider, Windows and Linux — same session semantics across all of them.
Node registry, live session state, instant device revocation, bans. Nodes keep serving when it is unreachable.
Purchases land in an idempotent ledger; entitlements are derived from it. Store billing, direct sales and manual grants use the same model.
Clients resolve a live entry point from a signed bundle carried over untrusted channels. Blocking one address does not remove the service.
Most tunnels assume the entry point is friendly, the network perimeter means something, and a credential issued once stays good. We assume none of it. Every one of these is a structural property, not a setting someone can forget to turn on.
A gate terminates TLS but cannot read what passes through it — the payload is sealed to the core. Seize a gate, take its disk, and you get no identities, no tokens, no user list.
Rights travel inside a short-lived device credential and are checked on every session. Being inside the network grants nothing at all.
A revoked device stops moving packets immediately — not at the next renewal, not when a cache expires, and not only in the billing system.
Policy travels inside each node's certificate rather than in host configuration, and node-to-node is denied by default. A compromised node cannot reach its neighbours.
We would rather you read this than find out during an evaluation. Dates are targets, not promises, and we will tell you if they move.
| Capability | Status | Notes |
|---|---|---|
| Data plane, four clients, control plane, entitlement | Shipping | In production, benchmarked, pre-production security audit completed internally |
| Blocking-resistant entry-point delivery | Shipping | Signed bundle over multiple independent carriers |
| White-label tenant builds | Pilot | Onboarding a first group of operators — talk to us if you run nodes |
| Open-source client and published protocol specification | Q4 2026 | Client under a copyleft licence, commercial licence available in parallel |
| Additional transports | Q4 2026 | Standard transports alongside our own, so existing server fleets work unchanged |
| SSO, second factor and audit log for corporate access | Q4 2026 | Identity provider integration and per-device access records; per-device identity is already in the data plane |
| Third-party security audit | Q1 2027 | Independent review; report published in full, including anything it finds |
| Packaged SDK — Android AAR, iOS XCFramework | Q2 2027 | Until then, integrations are done with us directly |
| Directory integration — SSO, SCIM provisioning | Q2 2027 | Until then, devices are enrolled through the control plane API |
| Exportable access audit log | Q2 2027 | Session and revocation events exist today; the export format does not |
If you need a tunnel inside a product, or you run servers and need real apps in front of them, write with a sentence about the shape of it. Technical questions reach an engineer, not a form.
[email protected]