Minecraft Fabric Server

[A Former User]

@girish Hmmm that is definitely interesting. One minecraft app where you can choose the server engine you want to use. It would have to download the JAR for each one and then just have a dropdown in the UI to select the server engine. Couple that with some conditional logic for the node server to launch the correct server and folders for each engine to have their own config and world files and it should work just fine.

It would definitely make the package a lot more versatile. At the expense of having a harder to maintain monolithic package

[girish]

@atrilahiji yes, I think we can throw them all in the same in the same Dockerfile. We thought about this when we added the second one (bedrock) but at the time it was decided that the 2 apps were totally different. One was java and another was c++ based something. I don't know about how Forge looks. For example, when looking into bundling https://www.spigotmc.org we wanted to put it in the java edition one.

If it's all very different, it's fine we can keep them as separate apps, it's not a problem!

[A Former User]

@girish I think bedrock is the only outlier here. The others are very much still Java based, from what I understand (at least Forge and Fabric are)

[girish]

@atrilahiji ah cool, don't let this stop you from packaging though. @nebulon can maybe merge the apps later.

[murgero]

@atrilahiji Bedrock and Java servers can be merged into one app if you use either one + geyserMC to connect.

[A Former User]

@murgero Interesting. Making a Minecraft omnibus app would be possible

[murgero]

@atrilahiji Yep! GeyserMC supports authentication also with Mojang servers so you have to own java to log in (disablable feature). GeyserMC with nlogin plugin would make for a decent bedrock/java server.

I would:

• use Spigot server with geyser plugin and nlogin plugin for maximum compatiblility.

[MooCloud_Matt]

@atrilahiji

One app for multiple minecraft is good, but i think that should be allow to run just 1 server at the time:

1- to limit extra complexiti on the manifest file
2- to improve performance, one docker need to have max 1 minecraft process or you will have poor performance specially for forge, fabric and vanilla that are super dependent on single tread performance.

an other think to consider is to not download the server when building the image, but download the jar just wen you have chosen your server type, so there is no need to update cloudron app for every server realise that are supported in the cloudron app.

[A Former User]

@moocloud_matt Interesting. Yeah so my idea was to have the UI let you switch which one you want to run. Only one would run at a time of course.

As for updating, that does make sense. My only concern is if it simply downloads the latest version of a given server at runtime, servers could break with unstable or buggy releases without any update or backups. Typically an update via cloudron will initiate a backup which will let you guarantee that you can return to just before the update. Depending on the backup policy, you would lose this level or granularity if the updates are at runtime.

[MooCloud_Matt]

@atrilahiji

welcome in the manage service world.
The big issue is understanding how much you want to manage for the future users.
What you say about backups is true, manage update with cloudron will provide backup, but is also true that cloudron don't let you install the version of an app that you want, but just the latest.

What i suggest if you want to still provide good quality image, with backup support is to differentiate the image/apps, but making them inter-compatible.

What that mean:

• i start with my server in vanilla
• then i want to try forge, i can just use cloudron cli to switch image maintaining the same app.
• at the restart of the app, you will have forge image, that work with your old world save.

Do do a good work on maintaining all those image, they will became a lot, multiple minecraft version, multiple server type, you should use some sort of automation we can contribute with one of our tech guy on that part.

[MooCloud_Matt]

@moocloud_matt
The main benefits on having 1 server type + 1 image combination insted of 1 for everything is the support for easy backup, update and rollback, Webui can be simple to the end user because it have just the function that he needs.
You can offer back compatibility to Minecraft Beta with no afford, and maintain there java version updated.

Development if the automation is good, will be easy because when you push a change a server type all his version will be updated automatically and rebuild.

If you update the basic java image all the server type will be updated, and all the version will be updated too.