Proxy / VelocityPublic build
VeloFlame
A Velocity fork that treats admission control as part of the proxy, not an add-on.
Velocity and Velocity-CTD fork focused on performance, anti-bot and native Limbo verification.
Active. Runtime version 1.4.9; public builds are distributed through ArkFlame and BuiltByBit.
Checked version 1.4.9
Evidence checked 2026-10-30
The problem
Velocity networks inherit the same front-door problem as BungeeCord, but the modern proxy also carries more state: login sessions, compression, limbo handoffs and plugin integrations. Bolting checks onto the side makes the hot path harder to reason about.
What I built
- Worked on the VeloFlame fork's early packet limiter, limbo admission and firewall modules.
- Added packet-size and decompression guards at the frame/compression layer, before normal packet handling.
- Built an event-loop-bound limbo takeover that can verify a connection before it reaches a backend.
- Kept host firewall work asynchronous and best effort, with a Java-side cache as the fallback.
Architecture and trade-offs
Early limits at the frame layer
The frame decoder validates a packet before it becomes a normal object. The compression decoder checks both the claimed uncompressed size and the actual inflated size, which closes the obvious decompression-bomb gap.
Per-state windows
Counters switch by protocol state and track packet count, bytes and decompressed bytes separately. A handshake limit is not the same budget as a play-state limit, so the defaults differ.
Limbo takeover before login completes
The login handler can divert a connection into limbo before the backend sees it. Admission is queue-bound and event-loop aware; the code rejects off-loop calls instead of quietly touching state from the wrong thread.
Firewall with a TTL
Blocked addresses live in an expiring cache. The optional ipset path is disabled automatically when proxy protocol or an invalid set name makes it unsafe, and shell work runs off the hot path.