MuteCloud
A free cloud system for Minecraft networks, written in Rust. One binary runs proxies and game servers from Minecraft 1.8 to current.
Available now, free
MuteCloud is available since October 2026 and is actively supported at least until October 2027. Install it with one command, the setup takes about three minutes. Questions, feedback and feature requests are welcome on Discord. Want a hand with your setup or your move from another cloud? Tell us about your network.
MuteCloud runs a Minecraft network from a single binary. No database, no Java to install, no pile of config files: one command downloads it, a short setup asks a few questions, and a few minutes later proxy and lobby are running. It starts proxies and game servers as ordinary processes, brings its own Java runtime for every group, and keeps the whole setup in readable TOML files. The same binary grows with your network, from a single small server to several machines in one cluster, with a built-in shield against bot attacks and signed updates. It runs the RAZ network, ten servers on two machines, every day.
At a glance
| Type | Cloud system for Minecraft networks |
| Written in | Rust |
| Install | one command |
| Needs | nothing preinstalled, no Java, no screen, no sudo |
| Footprint | around 10 MB of RAM for the cloud itself |
| Supports | Paper, Purpur, Folia, Leaf, Pufferfish, PandaSpigot, Fabric, Vanilla, Velocity, BungeeCord, Minecraft 1.8 through current |
Design principles
Configuration remains under your control. Groups are TOML documents. MuteCloud reads them and never rewrites them, which allows them to be kept under version control.
Java runtimes are managed per group. A BedWars group on 1.8.8 receives Java 8 while a lobby on 26.2 receives Java 25, concurrently on the same machine. Package updates of the host system cannot replace the JDK beneath a running server.
Templates are layers rather than copies. A plugin update is placed in layers/global
and applies to every group referencing that layer, instead of being copied into each
template individually.
Crashes are preserved. Console history, exit code and crash report are written to
dumps/ before the working directory is cleaned up.
The control plane is a service, not a terminal session. MuteCloud does not rely on screen or tmux. The command line communicates with the daemon over WebSocket and remains available even when a server console is blocked.
The proxy has a shield built in. Connection, ping and login floods are filtered in front
of Velocity before they reach it, switched on with shield on. See
Shield.
Getting started
New here? The comparison shows what sets MuteCloud apart, and the FAQ answers price, platforms and support.
- Requirements and sizing with a calculator for your network
- Installation sets up the first network
- Migration takes over CloudNet, TimoCloud and SimpleCloud
- Groups describe what runs and how much of it
- Templates put files into every server, in layers
- Commands for everyday work
Concepts
| Term | Meaning |
|---|---|
| Node | a machine running MuteCloud |
| Group | a rule for what servers exist, such as Lobby or BedWars |
| Server | one running process from a group, such as Lobby-1 |
| Template | a layer of files copied into every server |
| Bridge | the plugin connecting a server to the cloud |
| Leader | the node making the decisions in a cluster |
Community
Every network that runs on MuteCloud is a reason to keep building it. If you use it, come by on Discord and show your server; feedback of any kind helps, and feature requests are read and many of them end up in the cloud.