# Oraxen: custom items, blocks and paintings defined in yaml for Paper servers > Oraxen is a paid Minecraft plugin that turns yaml configuration and a resource pack into custom items, blocks, paintings, discs and glyphs on Paper and Folia. The code sits in a public repository under a custom licence that forbids redistribution of built artifacts. **oraxen/oraxen** — Oraxen is a minecraft plugin that allows to easily use Minecraft 1.14 features in order to create new items with custom textures. It handles the resourcepack generation, upload (using Polymath) and has an extensible API. - Repository: https://github.com/oraxen/oraxen - Website: https://docs.oraxen.com/ - Stars: 750 · Forks: 437 - Language: Java - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/oraxen-oraxen ## A configuration driven plugin for custom server content Oraxen is a Minecraft plugin aimed at server owners, administrators and developers who want content that vanilla does not ship: custom items, blocks, glyphs, paintings, music discs and armour. The plugin description frames it as a way to use Minecraft 1.14 features in order to create new items with custom textures, and it handles resource pack generation, upload using Polymath, and exposes an extensible API. What the plugin does not do is require you to write Java for each addition. The documented approach is configuration files plus a resource pack setup, so a server owner defines a block, a painting or a disc in yaml and Oraxen assembles the rest. Support covers Paper and its forks plus Folia, from version 1.20.1 through 26.3, which is a wide range but not an open ended one, and a server outside that window is out of scope. The audience therefore splits in two. Server administrators use the yaml surface directly. Plugin developers use the API to add behaviour the configuration does not express. Both groups inherit the same constraint, which is that Oraxen is a commercial product rather than a free plugin. ## Where the resource pack files live and why the path matters Every texture and sound that Oraxen adds has to exist in the resource pack that the server sends to clients, and the configuration refers to those files by path. The painting example states that the asset id oraxen:example references the file plugins/Oraxen/pack/assets/oraxen/textures/painting/example.png, and the sound example points at plugins/Oraxen/pack/sounds/discs/example.ogg. Those two references make the arrangement concrete: the pack directory lives under the plugin folder in the server directory, and the identifier used in yaml is a namespaced key rather than a file path. The split between the two matters when something breaks. A yaml file can be perfectly correct while the client still shows the default texture, because the pack was not regenerated, or was generated but not sent, or was sent and the client rejected it. The documentation links separate tutorials for paintings and for sounds and discs, and the hot reloading support for custom paintings is one of the features singled out, which is the practical answer to iterating on a pack. The plugin also generates and uploads the pack, and it can do so for a range of server versions, which is where the version support work sits. ## Defining a custom painting across two yaml files A painting needs two pieces of configuration, and the split is worth understanding before editing anything. The first file describes the item a player receives, including its material, its display name and the painting variant component. ```yaml example-painting: material: PAINTING itemname: "Example Painting" Components: painting_variant: "oraxen:example" ``` The second file describes the painting itself, keyed by the same namespaced id and pointing at the texture file in the pack. ```yaml paintings: oraxen:example: author: the_jan_craft title: Example Painting asset_id: oraxen:example # References plugins/Oraxen/pack/assets/oraxen/textures/painting/example.png width: 1 height: 1 ``` The `painting_variant` value in the first file and the key in the second have to agree, and the `asset_id` has to resolve to the file in the pack directory. Nothing here is generated from a GUI, so the failure mode of a broken painting is a missing or wrong texture rather than an error dialog, and the documentation points to a tutorial page for the full walkthrough. ## Music discs and sounds carry their own jukebox metadata Discs and custom sounds follow the same two file pattern, with the sound file holding the metadata that the client cannot infer. ```yaml example-disc: material: MUSIC_DISC_13 itemname: "Example Disc" Pack: model: discs/example Components: jukebox_playable: show_in_tooltip: true song_key: "oraxen:example" ``` The sound definition names the ogg file, the category, the subtitle and the jukebox entry that the disc points at through `song_key`. ```yaml sounds: - id: oraxen:example category: records sound: discs/example.ogg # References plugins/Oraxen/pack/sounds/discs/example.ogg stream: true subtitle: "Example Song" jukebox: description: "Example Song" duration: 20s ``` The `stream` flag is the interesting setting for a server with many players, since it tells the client to stream the sound rather than expect it to be loaded in full. The `duration` value is written as a time literal, and the `description` uses the same colour markup seen in the item names, so a disc shows a formatted line in the tooltip and in the jukebox. Custom music discs are also the feature the documentation marks as planned for hot reloading, so today the reload story is stronger for paintings and blocks than for discs. ## Blocks carry the most configuration and the most edge cases A block definition in Oraxen is where the plugin's declarative model shows its reach, and where the edge cases accumulate. The head of such a definition looks like this: ```yaml example-block: itemname: 'Cool block' Mechanics: block: type: FULL # FULL, STRING, CHORUS, STAIR, SLAB, DOOR, TRAPDOOR, GRATE, BULB light: 15 block-sounds: break-sound: block.wood.break place-sound: block.wood.place ``` The `type` value selects the block shape from a fixed list, and `light` sets the emitted light level. Below that sit `placeable` rules that control whether a block can be placed on a floor, a wall or a roof, with an `allow` and a `disallow` list of vanilla block ids, and `custom-variation` for visual variety. The `appearance` section can point at a texture model under the pack. Behaviour is expressed the same way, through an `events` list that runs actions on a click, with a `command` action and a `message` action, and an `executor` that chooses between CONSOLE, PLAYER and OP-PLAYER. Breaking rules use a `when` list keyed by tool, with a fallthrough `else` branch, and each branch can set hardness, drops with a probability, silk touch behaviour, fortune scaling and durability changes. That is a lot of surface for a config file, and the documented example runs to more than forty lines for a single block, which tells you the YAML is a small language rather than a settings screen. ## MultiVersionPacks decides which client sees which pack Custom content is only visible to clients whose resource pack format matches the server, and this is the hard constraint of the whole approach. The documentation lists built-in ViaVersion support for versions 1.21.4 through 26.3, with optional advanced support for versions 1.20 through 26.3 through MultiVersionPacks. Those two ranges describe the coverage precisely. The built-in path covers the newer range, while MultiVersionPacks extends support backwards to 1.20 and is described as optional and advanced. A server operator running 1.20.1 therefore depends on that optional layer, and the difference between the two is the difference between a pack that works and a pack that a fraction of the player base cannot read. Version reach is also a maintenance question rather than a feature list, because every new Minecraft release that changes the pack format moves the boundary. The stated supported window, 1.20.1 through 26.3, is the contract to check before committing to the plugin for a long lived server. ## A paid plugin with a custom licence on a public repository The licensing here is the part that catches people out. The README states that Oraxen is a paid plugin and that a licence must be purchased from SpigotMC or BuiltByBit in order to use it. Public forks are permitted for the purpose of contributing pull requests, provided the licence is complied with, and redistribution of compiled builds or source code, modified or unmodified, is prohibited except as the licence allows. The full text lives in LICENSE.md, and GitHub classifies the repository as using a custom licence it cannot categorise. The repository is otherwise open in the ways contributors expect. It carries a `src/` tree, a `build.gradle.kts`, `gradle.properties`, `settings.gradle.kts`, a `gradle/` wrapper, a `mise.toml`, an `nms/` directory, a `schemas/` directory and a `scripts/` directory, alongside `.github/`, `CONTRIBUTORS.md` and `AGENTS.md`. The presence of a `schemas/` directory and a `build.gradle.kts` means the yaml files in the configuration are described to an editor, which is a genuine convenience when a block definition runs to forty lines. The practical boundary is this: reading the code and proposing a pull request is allowed, running the plugin requires a purchase, and passing the result on to others is not. A server owner who wants to modify Oraxen for their own network and nothing else is inside the licence; a team that plans to fork it into a shared build is not. ## Release cadence and what the version numbers track The repository is not archived, and the last push was on 2026-10-20, so the code moved the day before this review. The published versions tell the rest of the story: v1.220.1 on 2026-10-14, v1.219.1 on 2026-09-18 and v1.219.0 on 2026-09-15. Those numbers are worth reading as a compatibility signal rather than a marketing version. Oraxen tracks the Minecraft versions it supports, and the supported range in the documentation runs from 1.20.1 through 26.3, so a plugin release in the 1.220 range corresponds to a particular set of client formats. When a new Minecraft version lands, the plugin version that supports it is the thing to look for, and a server owner running an old client mix will care more about the MultiVersionPacks coverage than about the release date. Upgrading is therefore a compatibility decision, not a routine pull. The `nms/` directory in the repository points to version specific code, and the difference between a server on 1.20.1 and one on a newer release is the difference between relying on the optional advanced path and relying on the built-in one. ## Conclusion Oraxen suits server owners who want custom content on Paper or Folia without writing a plugin, and plugin developers who want to extend it through its API. It is the wrong tool for a free or redistributable build, because the licence requires a purchase from SpigotMC or BuiltByBit and forbids passing on compiled builds or source. Before buying, check that your server version falls inside the supported range of 1.20.1 through 26.3, confirm which resource pack upload path applies to your setup, and read LICENSE.md, since GitHub reports the licence as a custom one rather than a standard open source licence. ## FAQ ### What does the Oraxen plugin do for Minecraft server owners? It lets server owners create custom content, including items, blocks, paintings, music discs and glyphs, through yaml configuration files and a resource pack setup, and it generates and uploads the pack. It supports Paper and its forks plus Folia. ### Which Minecraft versions does Oraxen support? The supported range is 1.20.1 through 26.3 on Paper, its forks and Folia. Built-in ViaVersion support covers versions 1.21.4 through 26.3, and optional advanced support for versions 1.20 through 26.3 comes through MultiVersionPacks. ### Is Oraxen free to use on a Minecraft server? No. Oraxen is a paid plugin and you must purchase a licence from SpigotMC or BuiltByBit to use it. The full terms are in LICENSE.md, and GitHub reports the licence as a custom one that it cannot classify. ### Can I redistribute or fork the Oraxen code? Public forks are permitted for contributing pull requests, provided the licence is complied with. Redistributing compiled builds or source code, modified or unmodified, is not permitted except as the licence allows. ### Where do Oraxen resource pack files go on the server? Under the plugin folder, for example plugins/Oraxen/pack/assets/oraxen/textures/painting/example.png for a painting texture and plugins/Oraxen/pack/sounds/discs/example.ogg for a sound. The yaml configuration refers to those files through namespaced identifiers such as oraxen:example rather than through file paths. ## Sources - [Issues](https://github.com/oraxen/oraxen/issues) - [oraxen/oraxen on GitHub](https://github.com/oraxen/oraxen) - [Project website](https://docs.oraxen.com/) - [README](https://github.com/oraxen/oraxen/blob/master/README.md) - [Releases](https://github.com/oraxen/oraxen/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oraxen-oraxen