System Velocity is standalone by design. What running it next to the System suite on one network actually means — and what it deliberately does not do.
SystemProxy-Velocity works fully standalone on any Velocity 3.3.0+ proxy, and this page exists to make that precise rather than vague. The plugin descriptor declares no plugin dependencies — not even optional ones. There are no plugin-messaging channels, no shared Redis keys, no shared database collections and no shared configuration values that must match anything on a backend. The only events it ever handles are chat and disconnect. Nothing about your backend stack needs to change — or be told — for the filter, the restart scheduler and the log cleaner to work.
The "System" in the name is product-line lineage, not a dependency. The plugin is named after the System-Proxy architecture it was inspired by — the same architecture the backend System plugin belongs to — and the two share an author. That is the complete relationship: brand family and authorship. Any description of data flowing between the two products would be false, so this documentation will never make one.
Many networks run both products, and the pairing is genuinely complementary — it just is not *integration*. Each side owns its own layer, with its own license and its own configuration:
| Concern | Who handles it |
|---|---|
| Proxy-side chat security | System Velocity — the five-layer pipeline filters payloads before forwarding |
| Proxy restarts and log hygiene | System Velocity — timezone-aware daily restart and the symlink-safe log cleaner |
| Backend gameplay and economy | System on each 1.8.8 server — lobby toolkit, economy, chat moderation, cosmetics, backups |
| Backend restarts and backups | System — scheduled restarts with its own countdowns, tar+gzip backups, login lock |
| Licensing | Separate licenses: EUR 5.00 per proxy for System Velocity, EUR 15.00 per server for System |
For the avoidance of doubt, stated as plainly as the table above: no shared sessions, no cross-server configuration sync, no central network config, and no data flow between the two products in either direction. Adding or removing either side never requires touching the other's configuration. If you start with System Velocity alone and later adopt System on the backends, nothing on the proxy changes; if you retire the backend suite later, the proxy side keeps working identically.
Tip:The natural rollout order is proxy-first: System Velocity is the cheapest and fastest Nerotek product to deploy (one jar, zero dependencies), and it hardens the network edge while you decide what happens on the backends.
Note:Both products are licensed separately and bind separately — the proxy carries its own per-proxy license, and each backend server carrying System carries its own per-server license.