FAQ

Questions, answered.

What FORGE OS bonds, how it stays secure, and what it takes to run it in the field. If your question isn't here, reach out.

What exactly is FORGE OS?
A bonded, encrypted software-defined router. It combines every available internet link at a site into one resilient, secure connection back to your network, deployed and run by the people already on site, not a visiting engineer.
Which links can it bond?
Any mix of Starlink / LEO, LTE / 5G, fiber or cable, and GEO satellite. You can add or drop carriers without redesigning the network; FORGE uses whatever is available at each site.
What happens when a link drops?
Nothing you'll notice. MPTCP bonds the links into one session, so traffic keeps flowing on the survivors: it degrades gracefully instead of dropping, and re-adds a link automatically when it returns.
Do we need a network engineer on site?
No. FORGE is built for a non-technical operator: plain-English status, one honest signal per site, and guided setup. If something is wrong, the operator can localize it and hand your NOC exactly what they need for a fast fix.
How secure is it?
Every tunnel is TLS 1.3, mutually authenticated, AES-256-GCM, enforced, never optional. Data-path cryptography executes in a FIPS 140-3 validated module (CMVP #5247). Isolation is fail-closed (lose the tunnel and the site stops forwarding), an allowlist gates every transiting packet, and revocation is instant. Product-level certification and DISA STIG mapping are on the roadmap.
Why TLS over TCP instead of WireGuard or IPsec?
Three reasons, in order. Bonding: the aggregation engine is Multipath TCP, and MPTCP is TCP: kernel-native subflows that add, drop, and retransmit across each other simply don't exist over UDP or ESP. Certification: TLS 1.3 through a FIPS 140-3 validated module is approvable cryptography; WireGuard's cipher suite is not FIPS-approved and can't be. Reach: CGNAT cellular, filtered guest wifi, and government firewalls routinely drop ESP and unfamiliar UDP, and pass TLS everywhere, because it looks like the traffic the whole internet runs on. As for the classic "TCP-over-TCP meltdown" objection: that's a single-path failure mode. When one subflow takes loss, MPTCP retransmits on the surviving paths and BBR congestion control holds throughput, and our published performance numbers are measured over exactly this transport.
Is this just Tailscale, or a mesh VPN?
Different question entirely. Mesh VPNs connect devices: a client on every endpoint, joinability coordinated through a cloud control plane. FORGE connects sites: a routing appliance at the network edge, nothing installed on end devices, and the control plane is your own hub on your own hardware, with no cloud in the join path at all. And underneath, FORGE does something no mesh VPN can: it bonds every WAN at the site into one session-surviving connection; WireGuard-based meshes are single-path by protocol. You could run a mesh VPN through a FORGE site and neither would notice the other.
Does the UI stop operators from making mistakes?
Both reveal and prevent, deliberately split. The status model reveals loudly: a site that's up but not mission-ready shows amber with the reason in plain language, so every action starts from a truthful picture. Irreversible or self-severing changes are consequence-gated: the confirmation tells you exactly what you're about to break before it lets you. Roles are hard-enforced (a viewer changes nothing; nothing joins without NOC approval), and because configuration is generated from a constrained model rather than freeform, most classic bad changes can't even be expressed. What FORGE won't do is refuse operator commands mid-incident because it thinks it knows better; a box that fights its operator gets bypassed with a console cable. Truthful picture always; hard stops only where there's no second chance.
Does FORGE OS ever need to reach the internet, or you?
No. Licensing is validated on the box against a signed fingerprint: no activation server, no license heartbeat, no telemetry leaving your network, no update reaching back to us. FORGE OS installs, enrolls, bonds, and routes indefinitely on a network with no way out, which is why it fits air-gapped and classified-adjacent environments where cloud-managed products stop working.
How are sites deployed and enrolled?
Low-touch enrollment: a spoke powers up, authenticates to the HUB, and waits in the NOC's approval queue. An operator approves it once, and configuration arrives automatically, with no manual tunnel setup or key handling in the field. Nothing joins your network without a human at the NOC saying yes.
What does the HUB manage centrally?
The FORGE HUB pushes enterprise services (NTP, DNS, authentication, syslog, and SNMP) down to every spoke automatically and keeps them in sync. Operators never hand-configure enterprise service connections.
How does it fit our NOC?
One HUB gives your NOC a single, honest view of every site: live throughput, per-site diagnostic bundles, and an offline geographic Fleet Map served from signed, customer-installed map packs (no external mapping service ever sees your fleet). Because status is truthful (amber for "up but not ready"), the NOC spends its time on real problems instead of chasing false greens.
What performance should we expect?
On our WAN-emulation rig, FORGE bonds real link mixes at roughly 78-87% of the links' combined ceiling with low added latency. Past ~500 ms of path skew (e.g. GEO), it correctly parks the slow link as hot standby rather than dragging the aggregate down.
Can we license or embed FORGE OS?
Yes. FORGE is available for OEM sub-licensing. Ship it inside your own hardware or managed service, under your brand. Talk to us about terms.
How do we get started?
Request a demo or book a pilot. Send us your sites, links, and constraints and we'll come back with a configuration and the expected impact, usually within a day.
Still have a question?
Send it over, or walk the live console and see the answers for yourself.
Ask us Explore UI