Creating configuration

First, it's important to know that Enji is designed to work exclusively with GitHub. All configuration files are stored in a GitHub repository.

A complete project configuration consists of several components:

• Project – basic information and settings
  • Name
  • Description
  • Origin
  • Tokens
• Variables – user-defined placeholders
• Core – server binary configuration
• Plugins – plugin sources and configs
• hitori
  • Modules

Let's create a configuration that demonstrates all these features.

Project

First, we need to define what our project is (its name and description), where it's stored, and how it should be launched.

For this example, our configuration will be stored on the main branch of the example/enji-config repository, specifically in the project.yml file.

project:
  # Origin contains information about where this config is stored
  origin:
    repo: "example/enji-config"   # GitHub repository
    branch: "main"                 # Branch name
    path: project.yml              # Path to the config file
  name: "Example project"          # Name of the project
  description: "Example project for enji wiki"
  jvm_args: "-Xmx4G -Xms1G"        # JVM arguments for running the project
  auto_update: true                 # Whether enji should update on every startup
  tokens:                           # Optional: tokens users must provide during installation
    - github

Variables

Variables act as placeholders in your configuration files (for example, in plugin configs). Users set these values during installation, and enji automatically replaces the placeholders with the provided values.

variables:
  server_port:                       # Variable name
    description: "Server port to use."  # Description shown to users
    regex: "^([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])$"  # Optional: regex pattern for validation
    default: 25565                    # Optional: default value if user doesn't specify one

Core

The core is essentially your server binary. Currently, only a few core types are supported.

Paper & Purpur

Paper and Purpur configurations are almost identical, with the only difference being the brand field.

core:
  brand: "paper"                      # Or "purpur", depending on your needs
  minecraft_version: "1.21.11"        # Minecraft version
  build: "%latest%"                   # Build ID or "%latest%" for automatic resolution

Velocity

Velocity doesn't depend on a specific Minecraft version, so it uses a version field instead of minecraft_version.

core:
  brand: "velocity"
  version: "3.5.0-SNAPSHOT"
  build: "%latest%"

Plugins

Plugins are downloaded and placed into the plugins/ folder. There are two ways to configure plugin downloads.

We'll install the CommandAPI plugin as an example, since it's a requirement for hitori (covered in the next section).

Using GitHub Releases

plugins:
  CommandAPI:                          # Plugin name
    source:
      type: github 
      repo: CommandAPI/CommandAPI       # GitHub repository
      tag: 11.1.0                       # Release tag name
      asset: CommandAPI-11.1.0-Paper.jar # Asset to download
    configs:                             # Plugin configs for later setup
      - plugins/CommandAPI/config.yml

Using Direct URI

plugins:
  CommandAPI:                          # Plugin name
    source:
      type: direct
      uri: https://github.com/CommandAPI/CommandAPI/releases/download/11.1.0/CommandAPI-11.1.0-Paper.jar
    configs:                             # Plugin configs for later setup
      - plugins/CommandAPI/config.yml

hitori

hitori is a Minecraft server-side development framework that works as a simple plugin. hitori configuration is straightforward. For this example, we'll download one public module called ux.

hitori:
  version: "%latest%"                   # Release tag or "%latest%" for the newest release
  modules:
    hitori:ux:                           # Module name
      source:                             # Source works the same as plugin sources
        type: github
        repo: modoruru/hitori-ux
        tag: 1.0
        asset: ux-1.0.jar
      configs:
        - plugins/hitori/hitori_ux/config.yml

Project Configuration Files

enji also maintains all configuration files for your project (like the basic server.properties or plugin configurations). These files must be located next to your main configuration file, preserving their relative paths. For example, if your project file is at project/example.yml, then your server.properties should be in the same folder: project/server.properties.

As mentioned in the Variables section, all variables will be replaced in configuration files. For example, let's use our previously defined server_port variable in server.properties:

...
server-port=${enji:server_port}
...

Default Configurations

Some configurations are tracked automatically.

Core

Paper and Purpur automatically track these configs:

• server.properties
• bukkit.yml
• spigot.yml
• config/paper-global.yml
• config/paper-world-defaults.yml
• purpur.yml (Purpur only)

hitori

hitori tracks only one configuration: plugins/hitori/config/config.yml.

Conclusion

The final file structure looks like this:

• project.yml
• server.properties

And here's the complete project file:

project:
  origin:
    repo: "example/enji-config"
    branch: "main"
    path: project.yml
  name: "Example project"
  description: "Example project for Enji wiki"
  jvm_args: "-Xmx4G -Xms1G"
  auto_update: true

core:
  brand: "paper"
  minecraft_version: "1.21.11"
  build: "%latest%"

plugins:
  CommandAPI:
    source:
      type: github 
      repo: CommandAPI/CommandAPI
      tag: 11.1.0
      asset: CommandAPI-11.1.0-Paper.jar

hitori:
  version: "%latest%"
  modules:
    hitori:ux:
      source:
        type: github
        repo: modoruru/hitori-ux
        tag: 1.0
        asset: ux-1.0.jar

Note that we haven't declared configs for the CommandAPI plugin or the UX module. Since we didn't set them up, they won't be processed by enji.