Blessing Skin: putting Minecraft skins back on offline servers

The problem is that offline mode has nowhere to look up a skin

In offline mode a Minecraft server authenticates players locally, with no account service to ask. The consequence for skins is specific and well known to server operators: custom skins and capes disappear, because the server has no source for the texture data.

Blessing Skin is the answer to that. It is a web application where you upload, manage and share custom skins and capes, and it is open source and written in PHP, so the README says you can deploy it freely on your own web server.

The mechanism has a condition that the README states directly. Unlike modifying a resource pack, everyone in the game will see the different skins of each other, but of course they should register at the same website too. So the model is that your server and your players all point at one instance of Blessing Skin, and the server asks that instance for textures. The site is not a place where you keep a file and hand it out manually; it is the authority the server queries on behalf of a player name.

That is why the project ships a skin library for sharing online, and why the plugin list includes custom Yggdrasil API authentication, since a server that wants to serve textures from a third party needs a way to point clients at the right URL.

One account can own several player names

The account model is the second structural decision, and it follows from how Minecraft names work. A user can own multiple player names on the site, and the feature list lists that as a capability in its own right: multiple player names can be owned by one user on the website.

This matters because in offline mode a player's name is not tied to a verified account anywhere. A person may play under several names across servers, and the skin belongs to the name, not to the login. The design therefore keeps the site account as the owner of several names, each of which has its own texture, and the site can hand out a mapping from name to skin.

The management side is described as a visual page for user, player and texture management, with detailed option pages, and the front end dependency list shows why: the project uses skinview3d and skinview-utils for the three dimensional skin preview, echarts for the charts, admin-lte and bootstrap for the admin layout, and react for the interface itself.

Alongside that, the security features are the ones a public sign-up service needs: support for many secure password hash algorithms, email verification for registration, and a score system for preventing evil requests. The last one is unusual enough to be worth reading the documentation about, since it implies the service is designed to stay open to strangers while limiting how much abuse an account can generate.

A specific stack: PHP 8.1, URL rewriting, and a long extension list

Blessing Skin is a Laravel application, which the repository topics confirm, and the requirements section is short but exact. You need a web server with URL rewriting enabled, Nginx or Apache, and PHP >= 8.1.0. The extension list is longer than the PHP version requirement: OpenSSL >= 1.1.1 for TLS 1.3, PDO, Mbstring, Tokenizer, GD, XML, Ctype, JSON, fileinfo, zip and Imagick.

The README notes that in most cases these PHP extensions are already enabled, which is a fair remark for a hosting platform but not for a small VPS where a minimal PHP build is common. The two extensions worth checking first are GD and Imagick, since texture handling and image work sit at the centre of what the application does, and the mix of both suggests the code paths handle images in more than one way.

The tree confirms the shape of a modern PHP project rather than a single script. There is an app directory, bootstrap, config, database, routes, resources, public, tests, a plugins directory, a Dockerfile, an artisan entry point, composer.json and composer.lock, and a front end toolchain with webpack.config.ts, tsconfig files, postcss.config.js, yarn.lock and package.json. There is also a .devcontainer directory and a .gitpod.yml, so a development environment can be started without assembling one by hand.

The Docker build rewrites the environment file instead of asking you to

The Dockerfile in the repository is a multi-stage build, and one detail in it is genuinely useful for anyone deploying the image. After the PHP dependencies, the front end bundle and the application code are assembled, the build edits the environment file directly:

    sed 's/PLUGINS_DIR=null/PLUGINS_DIR=\/app\/storage\/plugins/' -i storage/.env && \
    sed 's/DB_CONNECTION=mysql/DB_CONNECTION=sqlite/' -i storage/.env && \
    sed 's/DB_DATABASE=blessingskin/DB_DATABASE=\/app\/storage\/database\.db/' -i storage/.env

Three things are being done in one pass. The plugin directory is pointed at a path inside the container, the database connection is switched from the MySQL default to SQLite, and the database path is rewritten to a file under storage. The earlier stages also move .env.example to .env, run php artisan key:generate to produce an application key, symlink the environment file back from storage, and create the SQLite file with touch storage/database.db.

So the container ships as a self-contained, single file database setup rather than a MySQL dependent one. The trade-off is the usual one: the image is easy to run, and a SQLite file is a poor choice for a write heavy multi user service, so a large installation is better served by the manual build path.

The README does not include the install steps themselves. It points to the installation guide at blessing.netlify.app/en/setup.html and, for building from source, to a manual build page at blessing.netlify.app/build.html.

The .env file is where the security posture is decided

The example environment file shipped in the repository is short and readable, and one of its keys deserves attention. PWD_METHOD sets the password hash algorithm, and the file spells out the choices: BCRYPT, ARGON2I and PHP_PASSWORD_HASH on the strong side, then MD5, SALTED2MD5, SHA256, SALTED2SHA256, SHA512 and SALTED2SHA512. The comment under it says new sites are highly recommended to use BCRYPT.

That comment is the whole security story in one line. The weak options are present because an existing site may have accounts hashed that way, and changing the method would invalidate those passwords. A new site should therefore be created with BCRYPT and not inherit the older behaviour, and the choice should be made at install time rather than discovered later.

The rest of the file is ordinary Laravel configuration, and it is instructive that it exists at all: APP_DEBUG, APP_ENV, APP_FALLBACK_LOCALE, a MySQL connection block with DB_PREFIX, the mail settings for the registration verification email, CACHE_DRIVER, SESSION_DRIVER, QUEUE_CONNECTION, a Redis block, and PLUGINS_DIR with PLUGINS_URL for the plugin system. The mail block matters more than it looks, because email verification is one of the stated security features, and a site that leaves MAIL_HOST empty cannot send it.

The plugin variables are the other pair to notice. PLUGINS_DIR is where installed plugins live and PLUGINS_URL is how they are served, and the Docker build rewrites the first of them for you, which tells you that plugins are loaded from disk at runtime rather than baked into the release.

Plugins are how the server side gets adapted

The plugin system is presented as the extension mechanism for attaching functions and customisation to the site, and the documentation for plugin development lives on its own site at bs-plugin.netlify.app, with the plugins directory present in the repository tree.

Two integrations are named in the feature list, and both exist as plugins rather than as core code. The first is integration with Authme and Discuz, which is the bridge to a server that already has a login plugin. The second is support for custom Yggdrasil API authentication, which is the mechanism for pointing a Minecraft client at a texture provider other than the default one.

This is the architectural point of the project, and it is worth being explicit about it. Blessing Skin is a web application, and it does not control your Minecraft server. A plugin is what connects the two, and that is why the plugins directory and the PLUGINS_DIR and PLUGINS_URL settings exist as first class configuration rather than an afterthought. The site can be deployed first and connected later, or connected to a server in offline mode, or used as a texture host for a server that authenticates some other way.

The alternative to the plugin route is the manual one, and the difference in approach is real. A plugin makes the server ask the site for a player's texture at the moment it needs one, so skins update without anyone touching a resource pack. The manual route, editing a resource pack and distributing it, has the limitation the README names first: everyone sees the same texture, because the pack is one file applied to the whole server. Blessing Skin exists to remove that limitation, and the plugin is the price of removal.

MIT licensed, PHP 8.1 floor, and a release gap since 2022

The licence is MIT, copyright the Blessing Skin Team from 2016 to the present, and the README carries the MIT badge. For a self hosted service that a community might want to modify, that is the permissive choice, provided the copyright notice is kept.

The runtime floor is PHP 8.1, which is the constraint most likely to affect an install, and it comes with the extension list from earlier. A host still on PHP 7.4 cannot run this code, and the README does not describe a supported older branch.

The release history needs a careful reading. The published tags are 6.0.0, released 2022-06-13, 6.0.1 on 2022-06-19 and 6.0.2 on 2022-06-23, and the version in package.json matches at 6.0.2. The last push to the repository, on the dev branch, was on 2026-10-01, and the CI badge in the README points at a workflow that runs against dev.

So the pattern is a stable line tagged in 2022 and continued development on a dev branch since. That has a practical meaning for an operator: the tags are what a release-oriented install should be built from, while the dev branch is where the recent work sits, and the documentation site is the place to find out which of the two the guide expects. The repository also carries the parts of a well run project that signal care without proving anything: a Dockerfile, a.devcontainer, a Gitpod configuration, eslint, prettier, husky, php-cs-fixer, jest for the front end tests, phpunit.xml for the PHP tests, and a codecov badge.

Editorial conclusion

Blessing Skin fits the operator of a Minecraft server running in offline mode who wants players to have distinct skins and wants to own the hosting service rather than depend on a public one. It does not fit a server already using a proper authentication plugin with a working skin URL, because the whole point is to replace that layer. Before deploying, confirm PHP 8.1 with the GD, Imagick, zip and fileinfo extensions is available, decide on the PWD_METHOD hash for new accounts rather than inheriting the example value, and read the installation guide at blessing.netlify.app/en/setup.html, since the README does not contain the install steps themselves.

Frequently asked questions

Official sources

1. bs-community/blessing-skin-server on GitHub
2. Issues
3. License: MIT
4. README
5. Releases