Drasl replaces Mojang's API server for your Minecraft network

What the project is, in one line

Drasl is an alternative API server for Minecraft that handles authentication, skins and capes, and the point of it is stated immediately: you can use it to host Minecraft servers that are completely independent from Mojang's infrastructure. It is designed to be easy to host yourself, and a reference instance is hosted at drasl.unmojang.org, which currently requires a Minecraft account to register. The background section explains why anyone would want this. You have always been able to host your own Minecraft server, but unless you run it in offline mode, authentication and skins are still handled by Mojang's API servers. The project is compatible with both authlib-injector and the vanilla Yggdrasil protocol, and it includes a minimalist web front end for registering and managing accounts. The licence is GPL-3.0 and the last push was on 2026-10-15.

The reasons a community gives for running its own

The README lists the motivations, and they are more varied than just privacy. One is having the benefits of offline servers without losing skins, encrypted connections or account security, which is the trade the vanilla offline mode forces on you. Another is creating additional accounts so that a single user can have multiple players logged in at once, whether that is a camera account spectating your own character for content creation or a bot, with the project linking to a bot library, automating things like AFKing, crafting or building map art. Others are having skins with transparency or at high resolution, which the README notes would also require a modded client, playing on a network where Mojang's servers are inaccessible, keeping activity private from Mojang, and serving access tokens that last longer so you hit Invalid session errors less often, which the README says is particularly annoying with modpacks that take a long time to restart. There is also opting out of chat reporting, and having a backup authentication system in case Mojang's servers go down. On privacy, the README is specific about what Mojang knows, including which servers you are active on, when you log on and who else is on those servers, and it notes that since 1.18 telemetry cannot be disabled without a mod.

The compatibility matrix, which is the real constraint

This is the part to read carefully, because Drasl only helps if the client and the server are on the right side of it. On the launcher side, launchers that support authlib-injector work, and two are named, Fjord Launcher and HMCL, with the note that Fjord Launcher supports authlib-injector accounts on all versions of Minecraft. On the server side there are three ways in. A vanilla Minecraft server running version 1.16 or later, with JVM arguments. A Minecraft server on all versions of Minecraft, with Loki, which is another project by the same organisation. Or a Minecraft server running version 1.7.10 or later with authlib-injector. The features list restates it, that all versions of Minecraft from Classic to the present are supported when using Fjord Launcher. So the support matrix runs along two axes, and the combination of an old launcher and an old server without authlib-injector is the case Drasl does not reach.

Installing it with Docker on Linux

The quick setup is six steps, all in the terminal. Clone the repository, then copy the example docker directory into place with `sudo cp -RTi ./drasl/example/docker /srv/drasl`, change into /srv/drasl, fill in `config/config.toml` according to one of the examples in doc/recipes.md, run `docker compose up -d`, and finally set up an HTTPS reverse proxy, using something like Caddy or nginx, pointing to localhost:25585. The cp step uses -RTi, which copies the directory tree into the target, treats the target as a directory, and asks before overwriting, so a second run will not silently clobber a configuration. The alternative to Docker is documented separately in doc/installation.md, and there is an example systemd unit in the example directory alongside the docker and docker-caddy directories and a config-example.toml.

The options that change how the server behaves

The configuration surface is where the interesting behaviour lives, and each option is documented separately in doc/configuration.md. You can use offline UUIDs, which the README calls useful for migrating from online-mode=false servers. You can link one or more OpenID Connect identity providers through the RegistrationOIDC option. You can allow multiple players per user with MaxPlayerCount, which is the server-side half of the multiple-accounts use case. You can proxy requests to fallback API servers, and this is what lets you configure your Minecraft server to accept users logged in with either a Mojang account or a Drasl account. You can disable access token and public key expiry, which removes the Invalid session and Invalid signature for profile public key errors. You can sign player public keys to support chat signing with enforce-secure-profile=true. You can allow high-resolution skins through SkinSizeLimit. And you can allow registering from an existing account on another API server, that is Mojang's, through the ImportExistingPlayer options, with an optional requirement of a skin challenge to verify ownership of the existing account, which is useful if you want to keep your UUID.

How it is built: one binary, no runtime dependencies

The hosting story is a single Go binary plus a few static assets with no runtime dependencies, and the build system is set up so that everything is compiled in. If you use Nix with flakes, the README says to simply run nix build, and otherwise you install the build dependencies yourself, with Go 1.24 or later required:

sudo apt install make golang gcc nodejs npm    # Debian
sudo dnf install make golang gcc nodejs npm    # Fedora
sudo pacman -S make go gcc nodejs n

The Go module is unmojang.org/drasl and go.mod requires Go 1.25.0, so the two version statements differ slightly and the module file is the stricter of the pair. The dependency list is the interesting part, because it is small and each entry has a job: labstack/echo for the web framework, gorm with a SQLite driver for the database, golang-jwt for tokens, zitadel/oidc for the OpenID Connect side, BurntSushi/toml for the configuration file, leonelquinteros/gotext for translations, jxskiss/base62 for short identifiers, dgraph-io/ristretto as a cache, and blake3 for hashing. The frontend side is small too, with esbuild and the skinview3d renderer for the 3D skin preview, upng-js for images, and a mapbox check for browser support. The Makefile builds with -buildmode=pie and hardened CGO flags, and a separate swag target generates the API schema from api.go.

Where Drasl is the wrong choice

Three cases. The first is a server that is content with offline mode, because Drasl is a lot of machinery to answer a question that a single server property answers for free, and the failure mode of a misconfigured authentication server is players who cannot log in. The second is a player base that will not change launcher, because Drasl needs the client side of the equation, and asking every player to install an alternative launcher or a mod is an adoption cost the project cannot absorb for you. The third is a network that wants to keep Mojang compatibility, where the fallback API server option is the closest fit, and there you are running two authentication systems at once, which is more complexity than a small community wants. Against running a private authlib-injector service such as the one the authlib-injector project provides, the difference in approach is that Drasl is a complete Mojang API implementation with its own account management, skin and cape storage and a web interface, and it is a Go program with a single binary, where the alternative is a component you place in front of a Mojang-compatible backend.

Editorial conclusion

Drasl is a good fit for a server operator who wants players to keep skins and account security without Mojang's servers in the loop, and for a community that needs to run on a network where Mojang is unreachable. It is a poor fit for a server that just wants offline mode, since the whole point of Drasl is to give you the benefits of online mode without the dependency, and it is a poor fit for a player base that expects every launcher to just work, because the launcher side needs authlib-injector support or a specific client. Check three things before you plan a deployment: that the launcher your players use supports authlib-injector, since Fjord Launcher and HMCL are named and Fjord supports all versions of Minecraft, that the server side can accept Drasl accounts, which needs version 1.16 or later with JVM arguments, or Loki on any version, or version 1.7.10 and later with authlib-injector on the server, and that you are prepared to terminate TLS in front of it, since the quick setup expects an HTTPS reverse proxy such as Caddy or nginx pointed at localhost:25585.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. unmojang/drasl on GitHub