Bare-metal runtime
Boots through PXE and runs without Windows, Linux or another conventional OS underneath it.
Discord, from a machine that never booted an operating system.
Discord-PXE is a PXE-booted x86-64 runtime that brings networking, TLS, WebSockets and the Discord Gateway into a bare-metal environment built largely in assembly.
Boots through PXE and runs without Windows, Linux or another conventional OS underneath it.
Networking, TLS, WebSockets and Discord Gateway handling live inside the runtime.
Independent shard contexts are being developed so one physical node can own multiple Gateway sessions.
A small controller assigns shard leases across PXE machines and tracks node capacity.
What is Discord-PXE?
The project starts at PXE boot, loads its own runtime, switches into x86-64 long mode and takes responsibility for the pieces a normal application would inherit from an operating system.
That includes the network path needed to reach Discord: TCP, cryptography and TLS, WebSockets, Gateway state, heartbeats and session handling.
PXE runtime loaded
x86-64 long mode online
network stack ready
[SHARD 0] TCP connected
[SHARD 0] TLS authenticated
[SHARD 0] Gateway READY
[SHARD 1] TCP connected
[SHARD 1] TLS authenticated
[SHARD 1] Gateway READY
shardteststatus
PASS: isolated shard contexts online
Why I built it
Discord-PXE is an experiment in removing layers. Instead of asking what Discord code looks like inside a normal application, the project asks what has to exist before that application is even possible.
Architecture direction
The working single-shard runtime is preserved while TCP, TLS, WebSocket and Gateway state are moved into reusable contexts. The immediate hardware milestone is two isolated live shards on one PXE machine before scaling farther.
Scaling model
The current architecture includes a 128-slot local shard context pool and a controller that can distribute shard leases between machines according to their declared capacity.
128 slots is the local architecture target, not a claim that 128 simultaneous live Gateway sessions have already been hardware-proven.
Runtime path
Current status
The known-good single-shard runtime is preserved on a baseline branch. Development on main is focused on isolated shard state, two-shard hardware acceptance, lease-aware multi-node planning and eventually scaling the same model beyond the first proven contexts.
View on GitHub ↗