Migrating from CloudNet, TimoCloud and SimpleCloud
Move an existing CloudNet 4, TimoCloud or SimpleCloud network to MuteCloud with one command, without touching the old installation.
MuteCloud reads an installation of CloudNet 4, TimoCloud 5 or 6, or self-hosted SimpleCloud 3 and takes it over without touching it. The command detects on its own which system it is looking at.
./mutecloud migrate --from /opt/cloudnet --dry-run
./mutecloud migrate --from /opt/cloudnet--dry-run reports what would be taken over without changing anything. The migration reads
only; the existing installation remains intact and operational.
CloudNet
| CloudNet | MuteCloud |
|---|---|
local/tasks/*.json | groups under groups/ |
local/groups/*.json | additional templates per group |
local/templates/... | templates under layers/ |
local/services/... | working directories of persistent servers under static/ |
| SyncProxy config | MOTD, tab list and maintenance in network.toml |
| Bridge config | fallback group, i.e. fallback |
Ports are spread apart so nothing collides, the forwarding mode between proxy and servers is chosen from the oldest version in the network, and a custom server jar survives when CloudNet used one.
TimoCloud
--from points to the folder containing core and base, or directly to core.
| TimoCloud | MuteCloud |
|---|---|
core/configs/serverGroups.json | server groups under groups/ |
core/configs/proxyGroups.json | proxy group, MOTD and player count in network.toml |
core/templates/server/Global, proxy/Global | templates global-server and global-proxy |
core/templates/server/<Group>_<Map> | template <group>-<map>, the first one is active |
base/static/server/<Group> | persistent server <Group>-1 under static/ |
bases.json or the base's ram | memory pool |
fallbackGroup of the TimoCloud plugin | fallback group |
The Java parameters TimoCloud sets on its own are left out, custom ones are carried over. A BungeeCord proxy becomes Velocity.
The fields of a server group map as follows:
| TimoCloud | MuteCloud |
|---|---|
online-amount | scale.min and scale.keep_free |
max-amount | scale.max, four times online-amount if there is no limit |
ram | memory |
static | persistent, i.e. a persistent server |
javaParameters | jvm_flags |
For proxy groups the number of proxies is max-players divided by players-per-proxy, but
at least min-amount. The MOTD and player count of the first proxy group then apply to the
whole network; further proxy groups keep their settings but not their MOTD.
If a group has several maps, i.e. templates such as BedWars_Desert and BedWars_Ice,
TimoCloud rotates through them. MuteCloud takes all of them over as separate templates, but
enables only the first and lists the others. Which map runs is then decided by the group's
layers list.
The fallback group comes from the TimoCloud plugin on the proxy. If it is not set there, a
group named Lobby or Hub is used. If the groups ran on several bases, MuteCloud starts
all of them on this node for now; for several machines there is the
cluster.
SimpleCloud
This means self-hosted SimpleCloud 3 with groups/*.yml. The current platform at
simplecloud.app keeps groups online; the command says so and aborts. SimpleCloud 2 is
detected as well, but not taken over.
| SimpleCloud | MuteCloud |
|---|---|
groups/<name>.yml | group, version from server-url or minecraft-version |
template-id: static | persistent server, working directory from running/static/ |
templates/every, every_<type>, every_<software>, templates/<name> | templates, the most general one wins as in SimpleCloud |
max-players of the proxy | player count in network.toml |
The fields of a group map as follows:
| SimpleCloud | MuteCloud |
|---|---|
min-online-count | scale.min, at least 1 for proxies |
max-online-count | scale.max |
max-memory, otherwise min-memory | memory |
start-port | start of port_range |
server-software or server-url | server software |
Paper, Purpur, Folia, Leaf, Pufferfish, Velocity, Waterfall and BungeeCord are recognised
as such. Spigot becomes Paper of the same version, a BungeeCord proxy becomes Velocity. If
server-url points to anything else, MuteCloud keeps downloading the jar from there.
The fallback group is the group named Lobby or Hub. If there is none, the run says so,
and you set it with groups <name> set fallback true.
What is not carried over
The plugins of the previous cloud are left out when the templates are copied: the CloudNet
bridge, TimoCloud.jar and SimpleCloud's plugins such as connection-paper, sign-paper
or cloud-api-velocity. Server jars that MuteCloud downloads itself are left out too, and
for TimoCloud also BungeeCord.jar and proxy.jar. Your own plugins and worlds come along
completely.
Anything the run cannot take over unambiguously is listed as a note at the end, for example
a version it does not recognise, a persistent server without a working directory, or ports
it had to move. The notes appear with --dry-run as well and are the actual checklist for
the migration.
After the migration
- Go through
groups, check memory and limits - Stop the previous cloud before starting MuteCloud, otherwise both systems compete for the same ports
- Watch
serviceuntil everything saysläuft
Rolling back consists of stopping MuteCloud and starting the previous cloud again. Nothing was removed.
Terminology
| CloudNet | MuteCloud |
|---|---|
| Task | group |
| Template | template, here in layers |
| Node | node |
| Module | built in or an addon, see addon |
cloudnet.json | mutecloud.toml |