# MSM is a shell script that turns one box into many Minecraft servers

> Minecraft Server Manager, or MSM, is a single Bash init script that manages several Minecraft or Bukkit servers on one machine, with world backups, jar download, log rolling and tab completion for its own commands. It fits a server admin running several instances from one host, and it does not fit a deployment that needs a panel, a database or a supported platform other than Linux.

**msmhq/msm** — An init script for managing Minecraft servers

- Repository: https://github.com/msmhq/msm
- Website: http://msmhq.com
- Stars: 1,264 · Forks: 223
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/msmhq-msm

## One script, many servers, and the design that follows from that

Minecraft Server Manager, or MSM, is a single init script which makes running multiple Minecraft and Bukkit servers easier for the admins who use it. The word single is the whole design.

The stated purpose is one script handles multiple servers, so you can run two or more on one machine. Everything else in the feature list follows from that premise. You can create and start new servers with a single command, and the script downloads the jars for you. Jar files are organised into groups, such as minecraft and craftbukkit, with each server linked to a single jar, and new versions are downloaded automatically. Global defaults are easily configurable with per-server overrides if needed, which is what makes a single script workable for heterogeneous instances rather than just clones of one.

Commands apply to one, multiple or all servers in one go, and the README gives the reason: it is useful for whitelisting a player on all servers. Send commands straight to the server via the command line, with a plethora of in-game commands available, including whitelist, blacklist, operator, gamemode, kick, say, time, toggledownfall and save.

The other half of the feature list is operational. It periodically makes WorldEdit snapshot compatible backups of your worlds, and it can back up the entire server directory for complete protection. It loads worlds into RAM for faster access, which reduces lag. It keeps server logs organised by periodically rolling them, and it provides tab completion for all commands.

The script grew out of an old version of Ahtenus' Minecraft Init Script, which the acknowledgements section names.

## Installing means running a script you have not read

The quick installers are two lines, one for Debian and one for RedHat.

On a Debian box:

```
wget -q http://git.io/Sxpr9g -O /tmp/msm && bash /tmp/msm
```

And under RedHat:

```
wget -q http://git.io/lu0ULA -O /tmp/msm && bash /tmp/msm
```

The shape of this is worth pausing on. The command downloads an opaque redirect target, pipes it into a shell, and the shell then runs it. You are executing code you have not seen, fetched over a shortener URL, as whatever user you run it as, and the installer is expected to need root because it installs an init script into the system's boot path.

That is the normal shape for a Linux quick installer and it is how most server administration tooling was distributed at the time. The mitigation is that the source is in the repository, so a careful operator can read the init/ directory and the installers/ directory before running anything, or clone the repository and run the installer from the checkout instead. The repository layout supports that: init/ holds the script itself, installers/ holds the per-platform installers, cron/ holds the scheduled jobs behind the periodic backups and log rolling, bash_completion/ holds the tab completion, and versioning/ holds the version data.

The README also asks you to suggest a new platform if yours is not covered, which is a reasonable ask given that the supported list is Debian and RedHat only.

## The configuration model is one file with per-server overrides

The repository root holds msm.conf, and it is the single place where the behaviour of every server is described. The README describes the model as easily configurable global defaults, with per server overrides if needed.

That is a sensible shape for a script that manages several instances, and it is worth thinking about where the boundaries are. A global default plus an override is enough for the common case, where servers are similar with small differences, and it keeps the file count low. It is less suited to servers that differ along several independent axes at once, because then the override list grows and the effective configuration of a given server is the merge of two places.

The file also holds the settings for the things the feature list mentions: the jar groups, the backup behaviour, the RAM loading of worlds, and the log rolling interval. There is a cron/ directory in the repository for the scheduled work, which is how the periodic backups and the rolling of logs are wired up on a system without a supervisor.

The versioning/ directory is where the semantic version scheme is applied to the script itself, and the README explains the scheme: releases are numbered <major>.<minor>.<patch>, with a breaking backward compatibility change bumping the major and resetting the minor and patch, new additions without breaking compatibility bumping the minor and resetting the patch, and bug fixes and miscellaneous changes bumping the patch. The stated purpose is to better describe what code one might have installed, and to indicate backwards incompatible changes.

## The upstream features on the roadmap are still described in the present tense

The Upcoming features section lists two items, and both are written as though they are close.

QuickBackup is for the case where you store your backups non-locally, maybe on a NAS. It optionally creates a backup locally for speed, and then moves it after your players are building again. The README cites a specific measurement: initial testing shows a 54 second network backup confaltes to 23 seconds of in-game time. That is an unusual number to publish, and it is the kind of detail that suggests the feature was actually tried rather than merely designed.

Restore is the other one, a roll-back to an old world or whole server backup automatically.

Neither appears in the repository listing as a directory or a script, and the repository's top level holds .github/, .gitignore, CHANGELOG.markdown, LICENSE.markdown, README.markdown, bash_completion/, cron/, init/, installers/, msm.conf, test.sh and versioning/. So the feature list in the README describes intent rather than a shipped feature set, which is a reminder to check the changelog and the init script rather than the README alone.

There is a test.sh at the root, so there is a test entry point, though the README does not describe how to run it.

## The release history is old and the repository is not

The dates in this repository are worth reading carefully before you plan around it.

The listed releases are 0.11.0 and 0.10.1, both on 2023-04-29, and 0.9.10 from 2018-11-04. The last push was on 2026-05-23. The repository is not archived, and the README describes an active project with a changelog, an issue tracker and a contribution flow.

The gap between the newest tag and the last commit is the thing to note. It is entirely normal for a shell script project to accumulate commits on master without cutting a release, since a release for MSM is a versioned copy of the init script that admins download, and the maintainer tags when there is a reason. But it does mean that if you install by cloning, you get code that is newer than any tagged release, and if you install a tagged release you get 2023 code.

The documentation is split across the repository and the website, with msmhq.com hosting the docs and the installation page, and the README linking out to them. The changelog lives at CHANGELOG.markdown in the repository, and the licence at LICENSE.markdown.

The licence is GPLv3, and the README adds that the author is open to suggestions where licensing is concerned, which is a courtesy worth noting if you are evaluating whether an internal deployment of a modified script causes any obligation on you.

## Where MSM is the wrong tool

The first wrong-tool case is a hosting business. A service provider running customer servers wants a control panel, per-tenant isolation, a database of customers, access control and billing hooks. MSM is a script you run as an administrator on a box you own. It has no notion of a tenant, no panel and no API, so the moment you need to give twenty customers their own servers on shared hardware, you are writing that layer yourself.

The second is a team that wants managed infrastructure rather than a shell script. The whole product is a set of Bash functions, an init script, a cron directory and a config file. That was a feature in the era of hand-rolled init scripts and a liability in a containerised environment where the process supervisor, the configuration and the health checks all want to be declarative.

The third is a non-Linux host. The installers cover Debian and RedHat, and the README asks for suggestions for other platforms. Running it on a system with a different init system, a different service manager or a different cron implementation means porting the script.

The fourth is a single server. Every feature here is about multiplicity, the jar groups, the multi-server command fan-out, the per-server overrides. With one server, a systemd unit and a handful of cron jobs is a smaller amount of machinery with fewer moving parts.

The fifth is the operational model behind the RAM feature. Loading worlds into RAM is a Minecraft server configuration choice, and it only pays off if the host has memory to spare and the world set is stable. On a small machine running several instances, the RAM setting is the first thing that will need tuning, and the README does not describe how it interacts with the other instances.

## Conclusion

MSM fits a Linux administrator who runs two or more Minecraft or Bukkit instances from a single host and wants one command surface for backups, restarts and console access, and it does not fit a team that needs a web panel, remote management or a non-Linux platform. Before installing, check the release you are getting, because the newest tag is 0.11.0 from 2023-04-29 while the last push was on 2026-05-23, and note the licence is GPLv3 with the author explicitly open to suggestions about licensing.

## FAQ

### What is MSM and what does it manage?

MSM is the Minecraft Server Manager, a single Bash init script that makes running multiple Minecraft and Bukkit servers easier for admins. One script handles multiple servers, and it can create and start new servers with a single command, downloading the jars for you.

### How do I install MSM?

On a Debian box run wget -q http://git.io/Sxpr9g -O /tmp/msm && bash /tmp/msm, and under RedHat run wget -q http://git.io/lu0ULA -O /tmp/msm && bash /tmp/msm. The README suggests a new platform through an issue if yours is not covered, and the script sources are in the repository if you would rather read them first.

### What backups does MSM make?

It periodically makes WorldEdit snapshot compatible backups of your worlds, and it can back up the entire server directory for complete protection. The upcoming QuickBackup feature is described as optionally creating a local backup for speed and then moving it once players are building again, and a Restore feature for rolling back to an old backup is listed as upcoming.

### How does MSM handle configuration?

Through the msm.conf file at the repository root, with easily configurable global defaults and per server overrides if needed. The repository also has cron/ for scheduled jobs, bash_completion/ for tab completion of MSM's own commands, and versioning/ for the version data.

## Sources

- [License: GPL-3.0](https://github.com/msmhq/msm/blob/master/LICENSE)
- [msmhq/msm on GitHub](https://github.com/msmhq/msm)
- [Project website](http://msmhq.com)
- [README](https://github.com/msmhq/msm/blob/master/README.md)
- [Releases](https://github.com/msmhq/msm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/msmhq-msm