Compared with other cloud systems
How MuteCloud differs from CloudNet, TimoCloud and SimpleCloud, and when another system is the better choice.
CloudNet, TimoCloud and SimpleCloud have run Minecraft networks for years, and all of them do the core job: start servers from templates, connect them to a proxy and scale groups up and down. MuteCloud does that too. The differences lie in how it is built and in what comes with it out of the box.
At a glance
| MuteCloud | Typical Java cloud system | |
|---|---|---|
| Runs as | one binary, around 10 MB of RAM | a Java application with its own JVM |
| Java | brings its own runtime per group, Java 8 to 25 side by side | has to be installed, one version for the cloud |
| Console | built-in service, no screen or tmux | often a screen or tmux session |
| Configuration | TOML files the cloud never rewrites | JSON files the cloud also writes |
| Templates | layers stacked on top of each other | folders copied per group |
| Plugin and template updates | rollout server by server without downtime | restart of the affected servers |
| Attack protection | shield built in | separate service or own setup |
| Web dashboard | built in | module or third-party project |
| Migration | takes over CloudNet, TimoCloud and SimpleCloud | not applicable |
| Price | free | free |
| Source code | not public yet, planned | open source |
What that means in practice
Nothing to install. MuteCloud is a single file. It downloads the Java version each group needs and keeps it next to the cloud, so a system update can no longer swap the JDK under running servers, and a 1.8 network can run next to a current version on the same machine.
Your configuration stays yours. Groups are TOML files that you can read, comment and keep in Git. MuteCloud reads them and never writes them back, so there is no diff after every start and no setting that quietly changes.
One change, every server. Templates are layers: a plugin placed in the global layer is there for every group that uses it. A rollout first starts a replacement with the new state and only drains an old server once the new one is ready, so a group never drops below its minimum. Persistent servers are renewed in place and keep their world.
Protection and overview included. The shield filters bot waves, ping floods and login floods in front of the proxy while keeping real player IPs. Alerts go to Discord or any webhook, and the dashboard, metrics and crash dumps are part of the cloud rather than extra projects.
Switching is not a leap. mutecloud migrate --from <path> reads an existing
installation, takes over groups, templates, persistent servers and network settings and
leaves the old installation untouched. Going back means starting the old cloud again.
When another system fits better
- You need the source code today. CloudNet, TimoCloud and SimpleCloud are open source. MuteCloud is free, but its source is not public yet.
- You depend on a specific module. Networks built around a module of another cloud keep using it there; MuteCloud has its own bridge API, and plugins written against another cloud's API have to be adapted.
- Your machines run on ARM. MuteCloud currently ships for x86-64 only.
Unsure whether MuteCloud fits your network? Ask on Discord.