{"id":28265323,"url":"https://github.com/codingkoopa/yamdi","last_synced_at":"2026-05-03T10:36:59.988Z","repository":{"id":121059340,"uuid":"274231577","full_name":"CodingKoopa/yamdi","owner":"CodingKoopa","description":"An advanced Docker setup for running Minecraft servers with Spigot and Paper. Mirror of: https://gitlab.com/CodingKoopa/yamdi","archived":false,"fork":false,"pushed_at":"2025-11-14T07:30:35.000Z","size":3642,"stargazers_count":2,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-05-03T10:36:50.315Z","etag":null,"topics":["bash","docker","minecraft","paper","spigot"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/CodingKoopa.png","metadata":{"files":{"readme":"Readme.md","changelog":null,"contributing":"Contributing.md","funding":null,"license":"License.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2020-06-22T20:07:38.000Z","updated_at":"2025-11-14T07:30:39.000Z","dependencies_parsed_at":null,"dependency_job_id":"bf03055d-b4e3-4659-95fb-5ffdbf46573d","html_url":"https://github.com/CodingKoopa/yamdi","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/CodingKoopa/yamdi","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CodingKoopa%2Fyamdi","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CodingKoopa%2Fyamdi/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CodingKoopa%2Fyamdi/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CodingKoopa%2Fyamdi/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/CodingKoopa","download_url":"https://codeload.github.com/CodingKoopa/yamdi/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CodingKoopa%2Fyamdi/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32566444,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-03T06:36:36.687Z","status":"ssl_error","status_checked_at":"2026-05-03T06:36:09.306Z","response_time":103,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["bash","docker","minecraft","paper","spigot"],"created_at":"2025-05-20T10:13:53.474Z","updated_at":"2026-05-03T10:36:59.982Z","avatar_url":"https://github.com/CodingKoopa.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Yet Another Minecraft Docker Image\n**Yet Another Minecraft Docker Image** (YAMDI) is a Docker image for running server software for *Minecraft: Java Edition*, such as Spigot and Paper, that aims to do everything securely and tactfully. Each part of YAMDI is designed to take full advantage of the features and optimizations that Docker can bring. The code is written for high readability and modifiability without making any sacrifices. YAMDI is a technical product for technical users who wish to understand the systems they run, and who like to tinker with them. If this doesn't sound like you, you may have a better time with the [`itzg/docker-minecraft-server`](https://github.com/itzg/docker-minecraft-server) image that is more geared towards being friendly for end-users.\n\nThe difference between this image and `itzg/docker-minecraft-server` is best exemplified in the handling of server configuration files. YAMDI encourages you to bind mount a version controlled server configuration directory into Docker, and uses Git to deploy it and print the changes as the server quits. `itzg/docker-minecraft-server`, on the other hand, offers the user the choices of either directly copying your configuration files into the container, or use some of the convenience environment variables provided to set server properties during startup. YAMDI makes it easier for you to manage your files in a VCS, but perhaps you do or don't care about that. The intent of this comparison is not at all to diminish the hard work that goes into that image, but to highlight how they are simply for different audiences.\n\n## Usage\n\n### How to use this Manual\nThere are two official ways to start a Docker container that will be explored in this manual:\n- The [Docker CLI](https://docs.docker.com/engine/reference/run/), which is configured using commands alone. This entails creating a `docker` command that will be invoked in order to start the server.\n- The [Docker Compose CLI](https://docs.docker.com/compose/reference/), which is configured using Compose files, which use [YAML](https://yaml.org/). This entails creating a Compose file that will be used by `docker-compose`.\n\nDocker Compose's configuration format and additional organizational tools often make it a good choice, but the startup process Docker CLI too can be automated by keeping the commands in a script. Although both of these options use the underlying Docker Engine, when it comes to starting the container, you only use one or the other to start YAMDI.\n\n#### Using Docker CLI\nThe Docker CLI comes with any installation of Docker. If you have not yet installed it to your computer and/or server, see [Docker's guide](https://docs.docker.com/get-docker/) to do so.\n\nTo get started, make a copy of the sample script in the YAMDI directory:\n```sh\ncp start.sample.sh start.sh\n```\n\nNow, to understand how to read the example snippets found throughout this documentation, let's use an example:\n\n---\n```sh\ndocker run --env YAMDI_SERVER_TYPE=\"paper\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_SERVER_TYPE: \"paper\"\n```\n---\nThe first code block is what applies to you - you don't need to worry about the YAML configuration at the bottom. The `docker run` signifies the command that's being run, and the `--env YAMDI_SERVER_TYPE=paper` signifies the argument that this is showing you to run. Most importantly, the `...` signifies that **this command is not meant to be run as-is!** These snippets do not stand on their own - you must integrate them into your script.\n\nThe Docker commands can get really long! For this reason, it's useful to break them up into multiple lines by escaping the newline:\n```sh\ndocker run yamdi/yamdi:latest \\\n  --env YAMDI_SERVER_TYPE=\"paper\"\n```\nThe backslash \"cancels out\" the newline, making it look like all the same line to the shell.\n\nIf you don't include the backslash, bad things will happen. For instance:\n```sh\ndocker run yamdi/yamdi:latest\n  --env YAMDI_SERVER_TYPE=\"paper\"\n```\nThe shell sees this as two separate commands that it will try and run, which is undesired.\n\n### Using Docker Compose CLI\nIn order to use Docker Compose, you must install both the [main Docker engine and CLI](https://docs.docker.com/get-docker/), as well as the separate [Docker Compose program](https://docs.docker.com/compose/install/).\n\nTo get started, make a copy of the sample configuration in the YAMDI directory:\n```sh\ncp docker-compose-sample.yml docker-compose.yml\n```\n\nNow, to understand how to read the example snippets found throughout this documentation, let's use an example from later in this document:\n\n---\n```sh\ndocker run --env YAMDI_SERVER_TYPE=\"paper\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_SERVER_TYPE: \"paper\"\n```\n---\nIn most cases, second code block is what applies to you - you don't need to worry about the command at the top unless it's for `docker-compose`. This is a YAML \"snippet\" that you would merge with your existing configuration. For example, starting with a more functional Compose file:\n```yaml\nversion: \"3.9\"\nservices:\n  yamdi:\n    image: yamdi/yamdi:latest\n    # \u003cThis is where the \"environment\" key goes!\u003e\n```\n\n### Starting the Server\n\n#### Choosing an Image\nThere are a couple of options for the YAMDI image to use:\n- Use a prebuilt image with a preselected common Java base image.\n- Build YAMDI yourself with whichever Java base image you want.\n\nFor more info on the variety of Java installations that can be used, see [Java Distributions](JavaDistributions.md).\n\n##### Prebuilt YAMDI\nYAMDI's [Continuous Integration (CI)](https://docs.gitlab.com/ee/ci/) provides prebuilt YAMDI images, updated when there is a new commit, as well as on a nightly basis for updates.\n\nThe images are pushed to [Docker Hub](https://hub.docker.com/r/yamdi/yamdi), with the following tags (currently very limited due to upstream changes):\n\n| Tags     | Distributor      | Java | JVM     | Type | OS     | Architecture                              |\n| -------- | ---------------- | ---- | ------- | ---- | ------ | ----------------------------------------- |\n| `latest` | Eclipse Adoptium | 17   | Hotspot | JRE  | Ubuntu | `linux/amd64`, `linux/arm64`, `linux/arm` |\n\nIf unsure, start with the `latest` image, as that tag corresponds with a safe default. Be careful with the Alpine Linux images: Although the smaller image size and more slim image contents make them a tempting pick, there may be performance implications to using it on a production Minecraft server.\n\nMulti arch support is provided where the base images provide it, for `amd64` (`x86_64`), `arm32v7` (`arm`), and `arm64v8` (`arm64`, `aarch64`). This spread has been selected to cover desktop servers as well as Raspberry Pi devices, but feel free to [make your case](https://gitlab.com/CodingKoopa/yamdi/-/issues/new) for another architecture you want to use.\n\nIf you need to use a YAMDI build from a specific date (noting that that same tag may be pushed to more than once if there is a new commit on that day), every one of the tags above has a variant with the date appended in `-YYYYMMDD` format. For instance, for the `latest-ubuntu` tag, there is a `latest-ubuntu-20210630` tag and a `latest-ubuntu-20210701` tag and so on. This should only be used temporarily, if a new YAMDI build breaks functionality for you, as images tagged with older dates **will not be updated with security fixes**.\n\nIf using the Docker CLI to launch YAMDI, the container is started using the `docker run`.\n```sh\ndocker run yamdi/yamdi:latest ...\n```\n\nIf using Docker Compose to launch YAMDI, the container is started using `docker-compose up`. If there is more than one service defined in the Compose file, you can use `docker-compose up yamdi` to only start YAMDI.\n```sh\ndocker-compose up\n```\n```yml\nservices:\n  yamdi:\n    image: yamdi/yamdi:latest\n```\n\n##### Building YAMDI\n\n###### Obtaining the Source Code\nIn order to build a YAMDI image, you need a copy of this repository. If you don't have one, you can clone it with Git:\n```sh\ngit clone https://gitlab.com/CodingKoopa/yamdi.git\n```\nOr, perhaps you're in a more limited environment that doesn't have Git:\n```sh\ncurl -O https://gitlab.com/CodingKoopa/yamdi/-/archive/master/yamdi-master.tar.gz\ntar xzf yamdi-master.tar.gz\n```\nOr, maybe you prefer wget:\n```sh\nwget https://gitlab.com/CodingKoopa/yamdi/-/archive/master/yamdi-master.tar.gz\ntar xzf yamdi-master.tar.gz\n```\n\n###### Building the Image\nIf using the Docker CLI to launch YAMDI, the image is built using  `docker build`.\n```sh\ndocker build -t yamdi .\n```\n\nThen, the image is then ran using `docker run`.\n```sh\ndocker run yamdi ...\n```\n\nIf using Docker Compose to launch YAMDI, the image is built using `docker-compose build`, or `docker-compose up --build` to do so while starting the container.\n```sh\ndocker-compose build\n```\n```yaml\nservices:\n  yamdi:\n    build:\n      context: .\n      image: yamdi\n```\n\nThen, the image is then ran using `docker-compose up`. If there is more than one service defined in the Compose file, you can use `docker-compose up yamdi` to only start YAMDI.\n```sh\ndocker-compose up\n```\n(There is no YAML snippet that pertains to this step.)\n\n###### Specifying Base Image\n\nThe Dockerfile is designed to adapt to whatever base image you give it. You can specify what base image you want to use by setting the `YAMDI_BASE_IMAGE` build-time variable to the full tag referring to the Java image you want to use. The vast array of Java images available is documented in [Java Distributions](JavaDistributions.md).\n```sh\ndocker build --build-arg YAMDI_BASE_IMAGE=\"adoptopenjdk/openjdk17:jre\" ...\n```\n```yaml\nservices:\n  yamdi:\n    build:\n      args:\n      - YAMDI_BASE_IMAGE=\"adoptopenjdk/openjdk17:jre\"\n```\n\n### Server Type\nThe type of server can be specified by setting the `YAMDI_SERVER_TYPE` environment variable. Currently supported values are `paper` (default) and `spigot`, case sensitive.\n```sh\ndocker run --env YAMDI_SERVER_TYPE=\"paper\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_SERVER_TYPE: \"paper\"\n```\n\n### Server Version\nThe target Minecraft version, can be adjusted by setting the `YAMDI_MINECRAFT_VERSION` variable either to `latest` (default) or a specific game version. Setting this to a specific version is **strongly recommended**, because of server software being buggy in the beginning, and plugin support not being guaranteed. You should aim for the most recent version that is considered to be stable on your server software. To use [Minecraft 1.8.9](https://minecraft.fandom.com/wiki/Java_Edition_1.8.9) - to give an example of a popular but older update, so this documentation doesn't become outdated:\n```sh\ndocker run --env YAMDI_MINECRAFT_VERSION=\"1.8.9\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_MINECRAFT_VERSION: \"1.8.9\"\n```\n\n### Paper Version\nFor Paper, `YAMDI_PAPER_BUILD` (a build for a particular revision of Paper) can be set in the same way. To use build 500 of the branch for this Minecraft version:\n```sh\ndocker run --env YAMDI_PAPER_BUILD=\"500\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_PAPER_BUILD: \"500\"\n```\n\n### Server Data\nYAMDI exposes three volumes:\n- `/opt/yamdi/user/server`, the server installation. This contains the server `JAR`, some world-specific configurations, and world data.\n- `/opt/yamdi/server-config-host`, the server configuration. This contains server-related configurations.\n- `/opt/yamdi/server-plugins-host`, the server plugins. This contains plugins that are to be loaded by the server, and their own configurations.\n\n#### Server Installation\nThe server installation volume, `/opt/yamdi/user/server` must be mounted in order for server data to persist. YAMDI enforces this by having a file in `/opt/yamdi/user/server/`, which will not be present if `/opt/yamdi/user/server` becomes a mountpoint directly. Unfortunately, [Docker's default behavior with an empty volume is to copy the file into the volume](https://docs.docker.com/storage/#tips-for-using-bind-mounts-or-volumes), which causes a false positive. We specify the `nocopy` volume option to disable this behavior.\n\nTo use a named volume to hold server data:\n```sh\ndocker run --mount type=volume,source=mc_server_data,target=/opt/yamdi/user/server,volume-nocopy=true ...\n```\n```yml\nservices:\n  yamdi:\n    volumes:\n      - type: volume\n        source: mc_server_data\n        target: /opt/yamdi/user/server\n        volume:\n          nocopy: true\n\nvolumes:\n  mc_server_data:\n```\n\nAlternatively, rather than using Docker's volume system, you could create a directory (`mc-data`) and use it as a bind mount:\n```sh\ndocker run --mount type=bind,source=\"$(pwd)/mc-data\",target=/opt/yamdi/user/server ...\n```\n```yml\nservices:\n  yamdi:\n    volumes:\n      - type: bind\n        source: ./mc-data\n        target: /opt/yamdi/user/server\n```\nThis not recommended because of potential permission conflicts that can occur.\n\n#### Server Configuration and Server Plugins\nUnlike the server installation, the volumes for the server configurations and plugins are optional - if you'd like, you could just use that volume to edit server configuration files and update plugins. However, this presents the following shortcomings:\n- The Docker volume's underlying files are in an inconvenient location to edit manually, unless you are using a bind mount.\n- With user namespace remapping, the underlying files will not be editable by nonroot users.\n- There's no way to put the configuration files of interest alone in a version control system.\n\nThe `/opt/yamdi/server-config-host` and `/opt/yamdi/server-plugins-host` mount points allow for isolating the server configuration and plugins so that they may be managed separately with relative ease. If they are mounted, then YAMDI will use Git to deploy them to `/opt/yamdi/user/server`.\n\nTo accomplish this, every startup, for each of the two mount points, YAMDI does the following:\n- Copy the contents of the host directory bind mount, because Git requires rw access to the files, which is not guaranteed for the YAMDI user if user namespace remapping is being used.\n- In YAMDI's copy of the directory, establish a Git repository.\n- In the Git repository, create an initial commit that adds all of the files.\n- Use the `git checkout` deploy technique from [here](https://gitolite.com/deploy.html) to establish a bare repository in `/opt/yamdi/user/server` and deploy the files to it.\n- Display a condensed `git diff`, to indicate what changes are being made to the pre-existing `/opt/yamdi/user/server`. If it's detected that this is the first run, this will not be printed as it would be overwhelming.\n- YAMDI allows the server to run before further action.\n- During shutdown, display a `git diff`, to indicate what changes the server software has made, such as adding an option added in an update.\n- A patch is produced with the changes made by the server software.\n\nGiven these details, there are multiple consequences that should be understood:\n- Files in `/opt/yamdi/user/server` that are not in the host directory will be left as-is.\n- Files in `/opt/yamdi/user/server` that have changed versions in the host directory will be updated.\n- Files in `/opt/yamdi/user/server` that have been deleted in the host directory will **not** be deleted. This is a limitation of how YAMDI's temporary Git directory works, in that it only tracks file creations. To remedy this, `JAR`s in the server plugin directory will be removed before the import process, to avoid any duplicate plugins of different versions.\n- Permissions of files in the host directory will not be retained. The purpose/desirableness of this is that it makes the files safe for YAMDI to write to.\n- As a result of YAMDI is using its own Git directory, it will neither not collide with any preexisting Git repository, nor require any Git setup on your part.\n\nTo use this, firstly, create the directories to hold the files on the host:\n```sh\nmkdir mc-config mc-plugins\n```\n\nTODO: Wizard to setup template.\n\nThen, to bind mount them to the container:\n```sh\ndocker run --mount type=bind,source=\"$(pwd)/mc-config\",target=/opt/server-config-host --mount type=bind,source=\"$(pwd)/mc-plugins\",target=/opt/server-plugins-host ...\n```\n```yml\nservices:\n  yamdi:\n    volumes:\n      - type: bind\n        source: ./mc-config\n        target: /opt/yamdi/server-config-host\n      - type: bind\n        source: ./mc-plugins\n        target: /opt/yamdi/server-plugins-host\n```\n\n##### Using the Git Patch\nThe changes made by the server to the configuration files can be written back like so:\n```sh\n#!/bin/bash\nset -e\nVOLUME_PATH=$(docker volume inspect --format '{{ .Mountpoint }}' mc_server_data)\nsudo cp \"$VOLUME_PATH\"/{config,plugins}.patch .\n(\n  cd mc-config\n  patch -p1 \u003c../config.patch\n)\n(\n  cd mc-plugins\n  patch -p1 \u003c../plugins.patch\n)\nrm -f {config,plugins}.patch\n```\n\n#### Ignore `server.properties`\nThe `server.properties` configuration file is internally stored as a [`Map`](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/Map.html), therefore it does not have any ordering. As a result, the order of the file is random, and as such brings up false positives when put in a Git repository. This behavior can be disabled by setting `YAMDI_IGNORE_SERVER_PROPERTY_CHANGES` to false, although this shouldn't be done unless you have good reason to.\n\n### Server Ports\nThe Minecraft Server port can be opened by exposing port `25565`.\n```sh\ndocker run --expose 25565 ...\n```\n```yml\nservices:\n  yamdi:\n    ports:\n      - \"25565:25565\"\n```\n\n### JVM Configuration\n\n#### General Options\nThe options passed to the Java Virtual Machine can be adjusted by setting the `YAMDI_JVM_OPTS` environment variable. This will be passed to both BuildTools and the server. For instance, if you are\nusing a OpenJ9 image, and will be running YAMDI in a virtual machine (e.g. if your cloud provider uses virtualization), you may want to use [`-Xtune:virtualized`](https://www.eclipse.org/openj9/docs/xtunevirtualized/):\n```sh\ndocker run --env YAMDI_JVM_OPTS=\"-Xtune:virtualized\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_JVM_OPTS: \"-Xtune:virtualized\"\n```\n\n#### Memory Options\nThe amount of memory allotted to the JVM should be set using the `YAMDI_GAME_MEMORY_AMOUNT` variable:\n```sh\ndocker run --env YAMDI_GAME_MEMORY_AMOUNT=\"1G\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_GAME_MEMORY_AMOUNT: \"1G\"\n```\n\nYou can also set the minimum and maximum memory amounts separately, using the `YAMDI_GAME_MEMORY_AMOUNT_MIN` and `YAMDI_GAME_MEMORY_AMOUNT_MAX` variables, which have a higher precedence than `YAMDI_GAME_MEMORY_AMOUNT`\n\n##### BuildTools Memory Options\nThe amount of memory alloted to the JVM while running BuildTools can be set using the `YAMDI_BUILDTOOLS_MEMORY_AMOUNT` variable:\n```sh\ndocker run --env YAMDI_BUILDTOOLS_MEMORY_AMOUNT=\"800M\" --env YAMDI_GAME_MEMORY_AMOUNT=\"1G\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_BUILDTOOLS_MEMORY_AMOUNT: \"800M\"\n      YAMDI_GAME_MEMORY_AMOUNT: \"1G\"\n```\nHere, the device only has 2GB of RAM available. BuildTools needs at least approximately 700 MB of RAM. However, if 1 GB is used for BuildTools, the same amount is also used for the child Java processes that BuildTools spawns, effectively doubling the amount of RAM that Java uses overall. Therefore, on limited machines, it is wise to use as little RAM for BuildTools as possible. Since it will be probably be desired for more RAM to be used for the server itself, two separate variables are provided.\n\nYou can also use `YAMDI_BUILDTOOLS_MEMORY_AMOUNT_MIN` and `YAMDI_BUILDTOOLS_MEMORY_AMOUNT_MAX` in the same way as their analogues for the game process.\n\nIf unspecified, the BuildTools variables will default\n\n#### Experimental Options\nBy default, for HotSpot images, YAMDI applies experimental JVM options [suggested by Aiker](https://mcflags.emc.gs/) for performance. For OpenJ9 images, [Tux's JVM options](https://steinborn.me/posts/tuning-minecraft-openj9/) are used. This behavior can be disabled by setting `YAMDI_USE_SUGGESTED_JVM_OPTS` to false, although this shouldn't be done unless you have good reason to.\n\n```sh\ndocker run --env YAMDI_USE_SUGGESTED_JVM_OPTS=\"false\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_USE_SUGGESTED_JVM_OPTS: \"false\"\n```\n\n### Sending Commands to the Server\nYAMDI comes with an helper script to send commands to the server while it is running in another container.\n```sh\ndocker exec yamdi cmd $COMMAND\n```\n```sh\ndocker-compose exec yamdi cmd $COMMAND\n```\nA command that can be used here (see `help` for more commands) is `version`.\n```sh\ndocker exec yamdi cmd version\n```\n```sh\ndocker-compose exec yamdi cmd version\n```\nThis should print something like `This server is running CraftBukkit version git-Spigot-f09662d-7c395d4 (MC: 1.13.2) (Implementing API version 1.13.2-R0.1-SNAPSHOT)`.\n\n### Shutting the Server Down\nYAMDI properly traps the SIGINT and SIGTERM signals (sent when running `docker stop` / `docker-compose down` / `docker-compose stop` or sending `Ctrl` + `C` in a `docker-compose` session), and properly shuts down the server (saving worlds, shutting down plugins, etc.) when they are received.\n\nConversely, when the server shuts down on its own accord, the exit code of YAMDI will be equivalent to the exit code of the Java process, therefore YAMDI is compatible with Docker restart techniques:\n```sh\ndocker run --restart on-failure ...\n```\n```yml\nservices:\n  yamdi:\n    restart: on-failure\n```\n\n**Warning**: Although the server tends to be able to save and completely shutdown within Docker's 10-second grace period, in production, it's **highly** recommended to boost this grace period to avoid corruption in any case where the save takes longer than usual:\n```sh\ndocker stop -t 300\n```\n```yml\nservices:\n  yamdi:\n    stop_grace_period: 5m\n```\nIt's important to mention that, when `Ctrl` + `C` is sent in a `docker-compose` session, the log feed will always prematurely end. This gives the effect that the server has been stopped before it's gotten the chance to save, when really it's still running in the background.\n\n### File Cleaning\nYAMDI can be made to clean unneeded files by setting the `YAMDI_CLEAN_FILES` variable. This purges crash dumps, crash logs. Plugin `.jar` files directly in `/plugins` WILL be deleted regardless of this option. Plugin files nested deeper than that (such as in `.paper-remapped` or `LuckPerms/libs`) will be left alone because remapping every boot is time-consuming.\n```sh\ndocker run --env YAMDI_CLEAN_FILES=\"true\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_CLEAN_FILES: \"true\"\n```\n\n### Debug Mode\nYAMDI can be made to print debug messages from itself by setting the `YAMDI_DEBUG` variable.\n```sh\ndocker run --env YAMDI_DEBUG=\"true\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_DEBUG: \"true\"\n```\n\n### Trace Mode\nYAMDI can be made to print every command it runs by setting the `YAMDI_TRACE` variable.\n```sh\ndocker run --env YAMDI_TRACE=\"true\" ...\n```\n```yml\nservices:\n  yamdi:\n    environment:\n      YAMDI_TRACE: \"true\"\n```\n\n## Credits\nYAMDI was started from [`docker-spigot`](https://github.com/AshDevFr/docker-spigot/) by AshDevFr, before everything was rewritten over time.\n\nThanks to [nimmis](https://github.com/nimmis/docker-spigot) and [itzg](https://github.com/itzg/docker-minecraft-server) for their work with running Spigot in Docker.\n\nThanks to [electronicboy](https://github.com/electronicboy/parchment-docker) for their work with running Paper in Docker.\n\nThanks to [Aikar](https://aikar.co/2018/07/02/tuning-the-jvm-g1gc-garbage-collector-flags-for-minecraft/) and [Tux](https://steinborn.me/posts/tuning-minecraft-openj9/) for their work with optimizing Spigot and Paper.\n\nThanks to [Flame Sage](https://github.com/chris062689) and [Byteflux](https://github.com/Byteflux) for their help and guidance.\n\n## License\nThis project is licensed under the MIT license.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcodingkoopa%2Fyamdi","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcodingkoopa%2Fyamdi","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcodingkoopa%2Fyamdi/lists"}