Kaizen NetworkSoftware

OriginGate / Changelog

OriginGate 1.1.0

2026-11-06

Upgrading from 1.0.0

Replace the JAR and restart. Your config.yml and messages.yml keep working unchanged and behave as before: every new setting is optional and off when missing, and missing new messages use the bundled text. One exception: with SQLite storage on a system outside Linux (x86_64 and aarch64, glibc and musl), Windows (x86_64 and aarch64), and macOS (x86_64 and aarch64) (for example 32-bit, ARMv7, or FreeBSD), lookups are no longer saved, only kept in memory until a restart, and an error at startup says so; switch to MySQL or MariaDB there. To use the new features, copy the new settings from the default config. On an offline-mode server, a new startup warning appears if you set bypass.players or bypass.permissions, and a backend behind BungeeCord IP forwarding gets one startup line; see offline mode and proxies. One change can kick a player that 1.0.0 let in: on IPv6, an address whose /64 neighbour was flagged is now turned away from memory without its own lookup. Saved ip-api lookups have no hosting flag until they are looked up again; run origingate cache clear all if you turn on the hosting rule with ip-api.

Added

  • hosting rule: kicks hosting and datacenter networks, where many VPNs and bots run without being flagged. Uses proxycheck.io's network type, or ip-api's hosting flag, which is now requested. Off by default. See providers.
  • deny-networks rule: kicks networks you list by AS number or by text in the provider, organisation, or VPN operator name. Off by default.
  • lookup.max-lookups-per-minute: a limit on provider lookups, so a bot flood cannot use up a provider's daily quota. Off by default; turn it on with on-budget-exceeded: deny when bot waves use up your lookups. Logins over it follow the new optional lookup.on-budget-exceeded (allow or deny), or on-lookup-failure when that is not set. See flood protection.
  • Staff with origingate.alerts get one chat message when a lookup provider is paused (a refused key, a rate limit, or a used-up daily quota), fails 3 lookups in a row, or has one of several API keys refused, and when the lookup budget is reached, plus one message when that is over (for the budget, after a full minute without a login over it). A reload keeps this state. New alerts.lookup-problem and alerts.lookup-recovered in messages.yml.
  • origingate status (permission origingate.command.status): lookups since start by source, the cache hit rate, failures, dropped lookups, the budget, and each provider's state, requests today, and paused API keys.
  • Offline-mode notices where anyone can claim any name: a warning at startup and reload when you set bypass.players or bypass.permissions (the shipped per-rule bypass permissions do not count), and caution="anyone can claim this name in offline mode" on the log line and staff alert whenever a rule's bypass permission lets someone in (global bypasses are covered by the startup warning). A backend behind BungeeCord IP forwarding gets one startup line, since a reachable backend port lets anyone fake their address. Velocity modern forwarding from an online-mode proxy counts as safe.

Changed

  • New installs wait at most 2500 ms for a lookup (wait-millis), down from 5000. New installs only: an existing config.yml keeps its value.
  • A lookup still queued when every login waiting for it has stopped waiting is dropped without asking a provider, so a burst of logins no longer spends quota on answers nobody uses. This happens only while the queue is backed up, also for lookups Bukkit starts in the background with nobody waiting; in normal traffic the late lookup still runs and fills the cache, as in 1.0.0.
  • An IPv6 answer that a rule acts on now also covers the rest of its /64, so a player switching addresses inside a flagged /64 is turned away from memory without a new lookup. This can kick a player whose own address was never looked up, which 1.0.0 would have looked up on its own. Clean answers stay per address, since hosts may split one /64 between customers, and an address's own saved answer always comes before its /64's. When an address's own lookup cannot complete (queue full, timeout, budget, providers failing), the /64 answer decides instead of on-lookup-failure. Teredo and well-known NAT64 addresses are never shared.
  • The plugin JARs include SQLite only for Linux (x86_64 and aarch64, glibc and musl), Windows (x86_64 and aarch64), and macOS (x86_64 and aarch64), which takes every JAR from about 14 MB to under 8 MB, below Hangar's 10 MB limit per file. On any other system, OriginGate keeps checking connections with lookups kept in memory only, and logs an error at startup that names the supported systems and points to MySQL or MariaDB. See compatibility.
  • Releases on Hangar: the three JARs together are over Hangar's 15 MB limit per upload, so the largest is listed as a link to its GitHub release download and the others are uploaded.
  • MySQL and MariaDB storage is tested against a real MariaDB 11.4 server, and GitHub Actions runs that test against a MariaDB container.
  • The Modrinth listing names Purpur for the Bukkit JAR and Waterfall for the BungeeCord JAR.

Fixed

  • A SQLite file that cannot be opened (damaged, locked, or in a folder that cannot be written) no longer leaves OriginGate running without checks: it keeps checking connections with lookups kept in memory only, logs an error, and tries the file again on origingate reload. A mistake in config.yml still stops the checks until it is fixed, as before.
  • Velocity: a bypass-notice that cannot be rendered no longer stops the staff alert for that bypass.