Philosophy

Simplicity is key. So is frugality.

Technically achieving low entropy not only reduces material costs, but also minimizes labor input, allowing more focus to be placed on server infrastructure.

Before beginning any deployment, repeat your philosophy three times, until the next operational goal is clear.

Existing hardware

The resources currently involved in the operation of this server project are: an Alibaba Cloud lightweight application server, a 16-core 16GB VPS provided by XyunCloud, and my HomeLab.

Key specifications are as follows:

Alibaba Cloud Lightweight Application Server: Located in Guangzhou and HongKong, with a peak bandwidth of 200Mbps. In multi-threaded tests, the throughput averages around 200Mbps, while single-threaded SFTP transfer speeds are 30Mbps. Dual-core CPU, 1GB of RAM.

Main Server: 16-core processor, 16GB of RAM, with a base frequency of 2.4GHz.

HomeLab: A variety of devices, mostly for personal use, with flexible deployment as needed.

Networking

Since the 1.17 update, the network quality of a Minecraft server has surpassed the impact of JVM memory size on the gaming experience, becoming the decisive factor. Improving network quality has thus become a key focus.

My solution is straightforward and somewhat brute-force: run a router system on an Alibaba Cloud server, and then forward data through layer-3 of routing. This is, in fact, more aggressive than using FRP. Due to the nature of UDP packets, Minecraft BE game traffic cannot be easily routed through FRP. The time and effort spent on debugging and repeated tests are better spent directly running a router system on an Alibaba Cloud server.

Previously, I ran Velocity as a proxy on the Alibaba Cloud server and used FRP to map the remote Minecraft service to the cloud server. But:

• Geyser requires a large amount of memory to run, but to reduce costs, I opted for an Alibaba Cloud server with 1GB of RAM. As the number of Bedrock Edition (BE) players increases, the game process is killed by the kernel due to exceeding available memory.
• FRP is often detected and blocked by the source server’s operator. This type of blockage differs from the “GFW blockage” and is actually a QoS-based blocking to prevent PCDN (Note: PCDN refers to Peer-to-Peer Content Delivery Network, which is a decentralized method of distributing content by leveraging user devices as nodes, often causing bandwidth and server load issues).

The result for players is intermittent disconnections—sometimes it’s Velocity dropping the connection, other times it’s the FRP service going offline.

Ultimately, I switched to using the iKuai router system and connected the various service nodes via OpenVPN. Everything is running smoothly and remains quite stable.

Moreover, distributing the workload is crucial (i.e., load balancing). This is why I use Velocity instead of directly exposing the Minecraft service to the public network. EdenBlocks has three sub-servers: the Demo Preview server, the Main server, and the Shop server.

Main Server

Upon Hetao_yz‘s recommendation, I chose the newly emerging Folia server.

Setting aside the excitement of trying something new, the VPS I received is a 16-core old Xeon with a slightly “underwhelming” clock speed. I quickly realized that this server is inherently well-suited for running Folia, which is optimized for multi-core asynchronous operations.

The plugin ecosystem for Folia is quite limited. Fortunately, the main server of EdenBlocks is a survival server, so it doesn’t require a flashy plugin ecosystem.

Below is the current list of plugins running on the EdenBlocks main server:

CoreProtect, HuskSync, floodgate, LuckPerms, PlugManX, ViaBackwards, ViaRewind, ViaVersion

As seen, these are all basic administrative plugins, including version compatibility features. In fact, the current plugins, combined with the vanilla features, fully meet the daily management needs.

Databases

The database software is limited by IO performance and runs on the HomeLab. Connectivity is established via OpenVPN for seamless communication.

Player data synchronization requires Redis and MySQL, with behavioral logs also stored in MySQL to optimize server performance. Therefore, a dedicated database server was set up for centralized management.

Shop System

The EdenBlocks shop is not designed for profit; it serves as a replacement for the complex redstone-powered “resource generation” system.

For most players, the barrier to entry for creating redstone-based resource generators is very high. Without relying on projection mod, only a few players are capable of building such machines independently. To prevent uneven development due to this high entry threshold, the shop sub-server was established for resource exchange.

The shop operates on a separate server, where players use iron blocks to earn basic currency and purchase items. This is all implemented using vanilla datapacks.

Thus, the shop is essentially a datapack development project. In fact, it offers more flexibility than plugin-based shops, as you have the freedom to modify NBT data to create more complex effects.

Demonstration

This server primarily relies on shell scripts to implement most functions and is essentially a mirror of the main server.

The demo server uses the following plugins:

ChatDisable, floodgate, GFly, LuckPerms, PlugManX, SimpleScore, Vault, ViaBackwards, ViaRewind, ViaVersion

A scoreboard has been added to display the server address and official website. Additionally, the game server is configured to not save player data, ensuring that players spawn at the initial coordinates upon entering the server.

Future plans

Once the first phase of the project is running steadily, we plan to open up the opportunity for more players with independent servers to join, allowing them to use their own computing power to create their own gameplay experiences.

In principle, as long as the server’s uptime is maintained, joining will be considered. We have also considered renting out the current server infrastructure, but for now, this doesn’t seem necessary.

The EdenBlocks management team maintains an open and collaborative attitude, sharing insights from our technical maintenance, with the hope of helping other Minecraft server administrators or offering self-reflection on EB Staff. In any case, please stay tuned for our future updates when significant technical changes occur.