The Native Freelang Architecture

BrowserBox v20 uses a native backend compiled from Freelang. Freelang is an ahead-of-time systems language designed to keep program behavior, authority, and resource ownership explicit and inspectable. It produces a standalone machine-code executable; the main BrowserBox request, control, session, and rendering server does not run inside Node.js.

The customer command layer remains bbx on macOS and Linux and PowerShell bbx on Windows. The commands, configuration directory, login links, policy files, and update workflow in this guide are unchanged by the backend implementation. BrowserBox selects the supported backend as part of the signed release; customers do not need a runtime backend switch.

Freelang gives the BrowserBox backend a smaller and more explicit execution surface:

• Arrays, byte buffers, strings, object fields, and runtime values carry checked bounds, sizes, shapes, or type tags. Freelang source has no general pointer arithmetic, raw pointer casts, or user-facing in-process foreign-function interface.

• Managed heap objects use a non-moving collector. References remain stable while unreachable storage is reclaimed and reused. Allocation failures and corrupt runtime invariants stop at explicit checks instead of continuing with undefined memory access.

• Expected operating-system and network failures travel through declared chaos outcomes. Broken program invariants use a separate fatal path, so ordinary connection failure is not confused with memory or state corruption.

• Complicated host capabilities are kept behind narrow process boundaries. Chrome remains a separate browser process; TLS, WebRTC, document, audio, and other platform facilities use supervised components with bounded protocols and explicit lifecycle ownership.

• Release artifacts are stripped and tied to signed manifests and exact build provenance. This reduces dependency and inspection surface and makes unexpected replacement detectable during install and update.

These properties reduce common memory-corruption, dependency, and lifecycle risks. They are engineering guarantees at specific boundaries, not a claim that BrowserBox, Chrome, an operating system, or a sidecar can contain no defect. Logic errors remain possible, and external components retain their own security models. BrowserBox therefore keeps policy enforcement, bounded input handling, process isolation, release verification, and regression gates in addition to the language-level checks.

The compiler used to build BrowserBox is implemented with a separate bootstrap toolchain, but that toolchain is not shipped as the BrowserBox server runtime. Full machine setup may still provision Node.js for remaining auxiliary install or service tasks. This does not put the main Freelang backend inside a Node.js process or restore the former server dependency tree.