Professional Hytale Plugin Development in 2026: Maven, Nitrado Query & CI/CD Publishing

For most of Hytale's early modding life, writing a plugin meant a lot of guesswork: hand-wired classpaths, copied JARs, and a build that only worked on your machine. That changed when Hytale went Shared Source on June 23, 2026, publishing the server source code, protocol, and assets on GitHub. Almost overnight, a real professional toolchain became possible. If you have already shipped a "hello world" mod and want to level up, this guide walks through modern Hytale plugin development in 2026: pulling a proper Hytale Maven dependency, exposing a Hytale server query API with Nitrado's open-source plugins, and wiring up Hytale plugin CI/CD that publishes to CurseForge and Modtale with one click. Why a professional setup matters If you have only ever built a plugin by dropping a compiled JAR into a mods folder, a "professional setup" can sound like overkill. It is not. A reproducible build declared through a dependency manager means anyone can clone your repo and compile it without hunting down loose files. Versioned artifacts mean you can pin your plugin to a specific server build and know exactly what you shipped. And an automated pipeline means a release is a git tag away instead of a manual afternoon of exporting, zipping, and uploading. This is the leap from hobby modding to something maintainable. It is also what makes collaboration realistic: contributors can open pull requests against a build that just works, and your CI can verify everything compiles against the current server before anything reaches players. If you are brand new to the API side of things, start with our Hytale modding and server plugin development guide first, then come back here to industrialize your workflow. And for the backstory on why all of this is suddenly possible, read how Hytale went Shared Source. The official Hytale Maven repository The cornerstone of modern Hytale plugin development is the official Maven repository, which hosts the server artifact you compile against. There are two repositories to know: Use https://maven.hytale.com/release for stable server builds and https://maven.hytale.com/pre-release for the weekly pre-release branch. The coordinates are the same across both: the groupId is com.hypixel.hytale and the artifactId is Server. In practice, you add the appropriate repository to your build tool and declare a dependency on com.hypixel.hytale:Server at the version matching the server you are targeting. The repository keeps roughly the last few releases available, so plan to track versions rather than assume an old one sticks around forever. The choice between release and pre-release is a real decision. Building against pre-release lets you support the latest weekly drops (see our coverage of the Update 6 Part 7 pre-release) but exposes you to breaking API changes. Building against release is more stable but lags behind. Many maintainers keep two build profiles. For the full, current walkthrough of configuring your environment and adding the dependency, follow the official docs at hytalemodding.dev. Treat those docs as the source of truth for exact version strings, which change every week. Nitrado's Webserver plugin: serving HTTP from your server Once your build is sorted, the next tier of professional tooling is Nitrado's open-source plugin toolkit. The foundation is hytale-plugin-webserver, a base plugin whose whole job is to let other plugins serve HTTP content from the game server. Think live maps, webhook receivers, player-data endpoints, or dashboards; instead of every plugin bundling its own web stack, they share this one. Architecturally this is the right pattern. The Webserver plugin owns the HTTP layer, handles the ports and routing, and exposes a clean way for dependent plugins to register their own routes. That keeps your plugin focused on its actual feature while still being reachable over the web. If you have integrated with HytaleCharts before, the model will feel familiar; it is the same thinking behind our own server API and webhook integrations. Nitrado's Query plugin and the server query API Built directly on top of the Webserver plugin is hytale-plugin-query, which is where the Hytale server query API comes to life. Once installed, it exposes structured JSON about your server, universe, and players at GET /Nitrado/Query. Any monitoring tool, status page, or bot can hit that endpoint and get a machine-readable snapshot of what is happening on your server. This matters enormously for server owners who care about visibility. A standardized query endpoint means uptime monitors, Discord bots, and listing sites can all read the same reliable data without scraping. It pairs naturally with heartbeat-style monitoring: the Query plugin answers "what is the live state right now" over HTTP, complementing the periodic pings and heartbeats that platforms like HytaleCharts already use to track online status and player counts. Because it depends on the Webserver plugin, you install both together, and you get a proper, documented Hytale server query API instead of a bespoke one-off. One-click CI/CD with hytale-plugin-workflows Here is where Hytale plugin CI/CD stops being a nice-to-have and becomes a genuine time saver. Nitrado publishes hytale-plugin-workflows, a set of reusable GitHub Actions designed specifically for Hytale plugins. The idea is that your release process becomes almost entirely automated. The workflows build your plugin from semantic version git tags, so pushing a tag like v1.2.0 kicks off a release. Even better, they can automatically rebuild your plugin when a new server version lands on maven.hytale.com, which is a huge deal given the weekly pre-release cadence; your plugin can be re-verified against the latest server without you lifting a finger. And when it is time to ship, the workflows can publish your artifact to Maven, CurseForge, and Modtale in one flow. Critically, that publish step sits behind a manual approval gate, so nothing goes public until a human clicks approve. You get automation without losing control over what actually reaches players. The practical upshot: define your Hytale plugin build setup once, tag a release, review the automated build, approve it, and it is live across every store you target. That is the difference between shipping updates in minutes versus dreading the release ritual. If your plugin sends notifications, this pairs well with a solid webhook and notifications setup so your community hears about each release automatically. Where to publish: CurseForge and Modtale With a pipeline in place, the last question is where your plugin lands. CurseForge remains the largest and most familiar destination, hosting thousands of Hytale mods and reaching a broad audience out of the box. When people ask how to publish a Hytale plugin to CurseForge, the short answer in 2026 is: let the Nitrado workflows do it as one of their targets. The newer option worth knowing is Modtale, an open-source (AGPLv3) mod, world, and asset repository that the Nitrado workflows treat as a first-class publish target right alongside CurseForge. Modtale's standout feature is Warden, a malware scanner that inspects uploaded JARs, an important safeguard given that plugins run arbitrary code on servers and clients. You can find the project at github.com/Modtale/modtale. Publishing to both CurseForge and Modtale widens your reach and gives security-conscious server owners a scanned source to trust. A quick word on client-side UI modding Server-side plugins are only half the ecosystem. If your project has a client-facing element, the UI tooling has matured too. Libraries like HyUI provide a Java UI framework with a declarative, HTML/CSS-like markup language for building interfaces, and companion mods exist to let multiple mods' HUDs coexist without stepping on each other. You will not need this for a pure server plugin, but it is worth knowing the front-end side of Hytale modding is keeping pace with the back-end tooling described above. Putting it all together The 2026 stack for serious Hytale plugin development is finally coherent. Compile against the official Maven repository at maven.hytale.com using com.hypixel.hytale:Server. Layer in Nitrado's Webserver and Query plugins to expose a proper Hytale server query API at GET /Nitrado/Query. Automate everything with the hytale-plugin-workflows GitHub Actions so a semver tag builds, verifies, and (after your approval) publishes to CurseForge and Modtale. That is a real professional pipeline, and Shared Source is what made it possible. Once your plugin is polished and your server is running it, the final step is getting players in the door. List your Hytale server on HytaleCharts to put it in front of people actively searching for somewhere to play, and let your shiny new query endpoint keep your listing's status and player count accurate. Build it properly, ship it automatically, and grow it here.