Worlds and backups
Keep several worlds with their own modpacks, switch between them, back up and schedule backups, regenerate the map, or import a modpack.
Backing up
AdminBack up now on the server's World page zips every world folder (on Paper, the Nether and End folders too) while the server keeps running, and the pack beside it: mods or plugins, config, defaultconfigs, kubejs, scripts, datapacks and globalpacks. Give it a name if you like; the pencil renames any backup. Saving pauses for the length of the backup, and Madsi refuses to start one when the disk hasn't room for it. Backups are kept on the server's own disk, in .madsi/backups; Madsi never stores them. Madsi's own jar and config/madsi.json are never put in a backup. A plugin or mod database (SQLite or H2, such as CoreProtect's or LuckPerms') goes in only from a copy taken while it held still; one that keeps changing for the whole backup, or any file the server keeps locked (on Windows, LuckPerms' H2 database while it runs), is left out rather than saved half-written, the backup says so, and restoring it keeps today's copy of that file. On Paper, a world container (settings.world-container in bukkit.yml, or --world-container) is followed: backups, restores, new maps and world switches take the world from that folder and put it back there.
Download streams a backup's world from the server to your browser, zipped on the way if it's a folder. Mods and configs, a world's serverconfig folder included, never leave the server, since configs can hold passwords. Delete removes a backup from the server's disk.
For regular backups, add a Back up the world task on the Schedules page. Backups are never deleted on their own unless you turn on Delete old automatic backups and choose how many to keep. That counts scheduled backups only; named, pinned and manual backups always stay. When the disk is too full for the next scheduled backup, the oldest of the live world's is deleted first, though never the last one. The copy of the world taken before a regenerate or restore is pinned, so it stays until you delete it yourself. A server you keep on save-off stays on save-off after a backup.
Restoring and regenerating
AdminRestore on a backup that kept its pack asks what to bring back: World only keeps today's mods and configs (if the backup's save folder has another name than today's, the server opens the one it brought back), while World and pack also puts back the backup's mods, configs and world settings (MOTD, game mode, difficulty and the like). Madsi's own jar and config stay as they are either way. World and pack needs the Mods and Guarded config permissions as well as Worlds, since the backup's pack can bring back other proxy and login settings. On a Windows server only the world can be restored, as the running server keeps its mods open; to get its pack, make a new world from the backup and switch to it, which needs the Madsi launcher.
Regenerate map makes a fresh map and keeps the mods. Pick a random seed or type one, and the world type (default, large biomes, amplified or superflat), game mode, difficulty, hardcore and whether structures generate. Nothing happens until the server next restarts: once it has stopped, and before any world loads, Madsi moves the current world into backups and writes the settings, and the server makes the new map as it starts. A restore works the same way. Until the restart, Cancel takes it back.
On a paid plan, Restart now carries it out straight away (players get a one-minute warning). Otherwise restart the server from your host. After a new world, the Stats page offers to start a fresh stats season.
Importing a modpack
AdminDrop a Modrinth .mrpack onto Modpack on the World page. Madsi reads it, refuses one made for another Minecraft version or loader, and shows the plan: the files it downloads from Modrinth (each checked against its SHA-512), the config files it copies, and what it skips. A pack only writes into mods, config, defaultconfigs, kubejs, scripts, datapacks and globalpacks, and never touches Madsi's own jar or config. Importing needs the Mods and Worlds permissions; a pack that writes a proxy forwarding config, a forwarding secret, a permission or login plugin's data, or anything into kubejs or scripts also needs Guarded config.
- Replace the current mods moves every mod but Madsi into .madsi/removed-mods (on Fabric, Fabric API stays too unless the pack brings its own, since Madsi needs it), then puts the pack's in
- Add to the current mods puts the pack's mods beside yours; a mod the pack brings replaces your copy
- Either way, a config the pack ships replaces yours, and yours is kept in .madsi/removed-mods
Jars inside a pack that don't come from Modrinth, and files Modrinth hosts for a project its moderators haven't reviewed, have nothing vouching for them. Only the server owner can add them, one by one; everyone else's import skips them. When Modrinth doesn't answer, the pack can't be imported until it does. Files a pack hosts outside Modrinth are skipped.
On Windows the running server keeps its mods open, so a pack that replaces or updates mods can't go into the live server. The refusal offers New world from this pack, which opens New world with A modpack picked; switch to that world once it's made.
The server downloads everything straight away and swaps it in as it next stops, so nothing changes until the restart. Tick Also regenerate the map to begin a fresh map with the new mods. Fabric and NeoForge only; it needs both the Mods and Worlds permissions, plus Guarded config when the pack writes a proxy forwarding config or secret or a permission or login plugin's data, or, on a server behind a forwarding proxy, replaces the mods without bringing a Modrinth build of a forwarding mod for its loader, or writes over the server's forwarding mod jar.
Several worlds
AdminA server can keep several worlds, each with its own map, mods, configs and settings: say a horror world and a vanilla one. Worlds on the World page lists them; the others wait on the server's own disk in .madsi/worlds. New world makes one beside the live world, from a fresh map (seed, world type, game mode, difficulty, hardcore, structures), a copy of a world's map, or a backup, with no mods, a copy of a world's mods and configs, or the backup's. Anything but a copy of the live world's mods and configs needs the Mods permission as well as Worlds, and Guarded config too when the new world's proxy forwarding config, Paper proxy settings or permission or login plugin data would differ from the live world's, or it would lack a proxy forwarding mod the live world runs. A copy taken from the live world leaves out a plugin or mod database still being written or locked by the running server, and the World page lists what it left out.
Switch makes another world live at the next restart: once the server has stopped, the live world and its pack move into .madsi/worlds and the other's move into place, with its own server.properties settings. Madsi's own jar and its config stay where they are, so the server comes back linked, and a Fabric world without Fabric API gets it, since Madsi needs it. A switch interrupted by a crash finishes at the next start, and one that can't finish puts everything back. Switching to a world whose proxy forwarding config, config/paper-global.yml or permission or login plugin data differs from the live world's in any way, or that lacks a proxy forwarding mod the live world runs, needs Guarded config as well as Worlds, and so does any switch while Edit config files is off, since Madsi can't compare them then. The gear on a world edits its settings; a live world's apply at the next restart.
- The box icon on a world that isn't live opens its mods (add from Modrinth, update, turn off, delete), its config files as text, and a .mrpack drop zone; changes land at once, ready for when it goes live. Adding, updating or turning a mod back on there needs the Worlds permission as well as Mods. With Install mod updates off, or
allowModInstall: falseinconfig/madsi.json, none of the mod or .mrpack changes go through, nor does restoring a backup's mods and configs, a new world with a backup's or another world's pack, or moving a world that isn't live to another version with its mods; the config files follow Edit config files instead - Stats follow the world being played, and switching back brings a world's totals back. Unless you're the owner, a switch (on the World page or with
/world switch), regenerating the live world's map (also a modpack import's new map) or restoring a backup over the live world is refused when a stat role rule on the server hands out a role at or above your own highest Discord role, or one a Team page mapping turns into Madsi permissions you couldn't grant - Backups show the world they came from; one from another world makes a new world instead of restoring over the live one
- Each server keeps up to 2 worlds on Free, 5 on Basic and 20 on Pro; after a downgrade the extra ones are kept but can't be switched to
- On Pterodactyl, two switches leave Madsi's backups and the worlds not being played out of the host's own backups
Other loaders and versions
AdminUnder Loader and version in New world, Choose picks Fabric, NeoForge or Paper, a Minecraft version from 1.21.9 to 26.2, and a build (betas are marked; the newest stable one is the default). Madsi downloads that server and a Madsi build to match while it makes the world. A copied map or pack has to come from a world on the same loader and version. New world from this on a backup made on another loader or version picks that backup's own loader and version for you, so the new world opens on what made it.
Switching to a world on another loader, version or build needs the Madsi launcher, set up once by the server owner. Madsi keeps the file your host starts (server.jar, or NeoForge's args file) in .madsi/launch/original and puts its launcher in its place, so the host starts the server exactly as before, and the launcher starts whichever world is live. Remove puts the original back, unless your host has put a newer jar in its place since, which stays. A run.sh you edited keeps your lines and loses only the launcher's.
- A switched-to world that fails to start twice in a row is rolled back to the previous one, with a Switched world didn't start event and the log on the World page
- Minecraft 26.x needs Java 25; on an older host Java, Madsi downloads Java 25 from Adoptium and runs that world on it, as long as the start flags don't reserve all the memory up front
- On Windows, every switch goes through the launcher, which starts the server jar your host keeps, so replacing that jar to update the server works as before
- If a host reinstall puts its own jar back, the World page asks to set the launcher up again
- When the launcher writes run.sh (or run.bat) for NeoForge, it keeps the Java flags from your host's own script, such as -Xmx. If you edit the script after that, Madsi keeps your lines and only changes the line naming NeoForge's args file; a switch that needs that line is refused when it's gone
- Hosts that re-download their server jar on every start (the itzg Docker image) can't keep the launcher in place
Moving a world to another version
AdminChange loader or version (the circular arrows on a world) copies a world to another loader, Minecraft version or build. Madsi looks each mod or plugin up on Modrinth by its file and swaps it for its build on the target, with anything it needs; you decide whether the ones with no build carry over as they are. Between Paper and a modded loader the pack starts empty, and the Nether and End move between Paper's and vanilla's layout. It needs the Mods permission as well as Worlds, and Guarded config too when the copy would lose a proxy forwarding mod the world has (moving to or from Paper always does, and one carried over as it is only counts on its own loader), or when its proxy forwarding config, Paper proxy settings or permission or login plugin data would differ from the live world's (moving to or from Paper leaves none).
- Keep it too: the copy is a world of its own, and counts towards your plan's worlds
- Replace it: the copy becomes the world, with its name, stats and backups, and the original is kept whole as a pinned backup; for the live world, the map, configs and plugin data are taken when the server next stops, so nothing played until then is lost, and the copy takes over once it has started (this needs a Madsi launcher recent enough to take the map at the stop, which a restart sees to except on Windows)
- A world opens on the same or a newer version; a forced downgrade is the owner's call, and never crosses 26.1's save format
- New world can also start from an uploaded world zip (up to 10 GB, resumable) or a Modrinth modpack, which picks the loader and version
- A pinned backup is never deleted to keep the newest few
Who can use it
AdminBacking up, downloading, renaming and pinning backups and the backup keep count need the Backups permission; restoring and deleting backups, regenerating, new worlds, uploads and switching need Worlds. The owner always has both and can give them to a team role. Setting allowWorldManage to false in the server's config/madsi.json switches it off for that server, whatever the dashboard says. Every backup, rename, download, regenerate, restore, new world and switch is recorded in the Audit Log.