Hytale Goes Shared Source: Hypixel Studios Releases the Full Server Source Code, Network Protocol, and All Assets on GitHub — What It Means for Server Owners and Modders

Every so often a single announcement reshapes what is possible for a community, and on June 23, 2026, Hytale got one. In a post on X, Hypixel Studios announced Hytale Shared Source: the studio is releasing the full Hytale server source code, the network protocol, and all of the game's assets publicly on GitHub. Not a curated SDK, not a stripped-down sample project — the real server source, the actual protocol, and the complete asset library, including content that was built but never shipped in the game. For everyone who runs a server or writes mods, this is the kind of news that changes your workflow for years. It closes the door on a frustrating era of guesswork and opens a far more honest one. Here is exactly what was announced, how access works, and — most importantly — what it practically means if you operate a Hytale server or build plugins and mods. What Hytale Shared Source Actually Is The headline is simple: Hypixel Studios is publishing the Hytale server source code, the network protocol, and every Hytale asset to GitHub. The asset release is notable on its own — it explicitly includes assets that never made it into the live game, the kind of cut content and unused resources that communities normally only learn about through leaks or datamining. The word to keep in mind is "Shared" rather than "Open." This is Hytale open source in the practical sense that the code is readable, cloneable, and downloadable, but it is governed by a license and a program you opt into — not a permissive free-for-all. The closest reference point, and the one Hypixel Studios chose deliberately, is the way Epic Games distributes the Unreal Engine source. How Access Works: The Unreal-Style License Gate Access to Hytale source code on GitHub is modeled directly after Epic Games' Unreal Engine source model. The flow looks like this: you need a valid Hytale game license, you accept the program's terms, and in return you receive an invite to Hypixel Studios' GitHub organization. Once you are in, you can view, clone, and download the repository like any other GitHub project you have access to. You sign up through the official access portal at accounts.hytale.com/shared-source. That license gate is the whole reason this can be called "Shared Source" with a straight face: the code is genuinely available to the people who own the game, but it stays inside a defined program with terms attached rather than being mirrored freely across the open internet. The Workflow: Branch Per Version, CI/CD, and a Maven Sources JAR This is where it gets interesting for anyone who actually builds against Hytale. The source will not be a one-time dump that drifts out of date — it stays current. Updates ship with every release and pre-release, with a dedicated branch per version, pushed automatically through the studio's CI/CD pipeline. In practice that means when a new pre-release lands, the corresponding branch shows up on GitHub without anyone having to manually package and upload it. A branch-per-version layout is exactly what server developers want. If you maintain a plugin across multiple game versions, you can check out the precise branch your server is running and read the code that actually matches your deployment, rather than reverse-engineering whatever HytaleServer.jar happens to be installed. When the protocol changes between versions — something our Update 6 protocol breaking-changes guide covered in detail — you will be able to diff the relevant branches and see precisely what moved. On top of GitHub, Hypixel Studios plans to publish a sources JAR to Maven. That is a small line with a big payoff: pulling the sources artifact into your build means your IDE can attach real source to the classes you call, so instead of staring at decompiled method names you navigate the genuine, commented code with full IDE jump-to-definition. For plugin developers that is the difference between hoping you understand an API and reading it. Why Stripped Commits Matter One detail is easy to skim past but worth understanding: individual commits and author data are stripped from the public history. You get the source as it stands per version, but not the granular commit-by-commit trail or the names attached to each change. Hypixel Studios gave two reasons. First, privacy — keeping individual team members' authorship out of public view. Second, workflow noise: the studio uses a trunk-based development style, which produces a lot of churn on its main line, and exposing all of that raw history would bury the useful signal under thousands of internal commits. Stripping it keeps the public repository clean and focused on what each released version contains, while protecting how the team works day to day. For modders this is a fair trade — you lose archaeology you never really needed and keep the thing that matters, the actual code per version. No Pull Requests Yet — The Contributor Roadmap If you were already drafting a PR, hold on. Hypixel Studios will not accept pull requests at launch. The reasons are practical: reviewing community contributions takes real capacity the team does not yet have to spare, and they are openly wary of submission volume "in the age of AI," where a flood of low-effort or machine-generated PRs could swamp a small review team. The plan is a staged rollout rather than a permanent closed door. The roadmap they described: start with invite-only contributors drawn from select community members, promote the trusted ones to maintainers who can push PRs, and eventually open contributions to everyone alongside a published code of conduct. So contribution is coming — it is just being phased in carefully instead of switched on overnight. For now, treat Shared Source as something you read and learn from, not something you submit changes to. Ending the Decompilation Gray Zone The framing Hypixel Studios chose says a lot about who this is for. They explicitly positioned Shared Source as ending the community's "decompilation gray zone." Until now, serious Hytale modding source code work meant decompiling the server JAR — running tools that reconstruct approximate source from compiled bytecode, then working against names and structures that may or may not match the original. Our modding API and plugin development guide and the deep-dive on ECS components, systems, and codecs both had to navigate around exactly that obstacle. Decompilation worked, but it lived in a legal and ethical gray area, and it produced a worse developer experience: lost variable names, mangled generics, missing comments, and constant uncertainty about whether what you were reading was what the server actually did. Shared Source replaces all of that with two things at once — a genuinely better developer experience, and legal clarity. You are reading sanctioned source under a real program, not skirting a EULA with a decompiler. What This Means Practically for Server Owners and Modders Strip away the announcement language and here is what changes on the ground. Legitimacy. The single biggest shift. Plugin and mod development moves out of the gray zone and into a sanctioned program. If you have hesitated to build or publish a mod because you were uneasy about decompiling the JAR, that hesitation is gone. You can study the real Hytale server source code with the studio's blessing. Easier plugin development. Reading the actual API — with real names, real comments, and real structure — beats inferring behavior from decompiled output every time. The Maven sources JAR means your IDE attaches that source automatically, so writing against Hytale's systems becomes a normal coding experience instead of detective work. Studying real server behavior. When your server misbehaves, you will be able to open the exact branch for your version and read how the server is supposed to handle the case. Understanding the Hytale protocol directly from source — instead of sniffing packets and guessing — makes building proxies, query tools, and integrations dramatically more reliable. IDE navigation of source. Jump-to-definition into Hytale's own classes, follow a method call all the way down, and read the comments the engineers actually wrote. For anyone maintaining a plugin across versions, the branch-per-version layout means you are always reading code that matches what you ship. Asset access. The full asset library, including never-shipped content, is a creative goldmine for resource packs, custom content, and reference work — all available without datamining. Get Set Up, Then Get Listed If you build for Hytale, the first move is simple: head to accounts.hytale.com/shared-source, confirm your Hytale license, accept the program terms, and claim your invite to the GitHub organization. From there, clone the branch that matches your server version, wire the Maven sources JAR into your IDE, and start reading the code you have been guessing at for years. Keep an eye on our latest pre-release patch notes as well, since each new version now means a fresh source branch to diff. And once your server is dialed in with cleaner plugins and a deeper understanding of how Hytale actually runs, put it where players can find it. Add your server to the Hytale server list on Hytale Charts to climb the rankings, collect votes, and grow your community. The Shared Source era rewards the server owners who do the work — make sure yours is on the list.