A new Minecraft release lands, or the mod you want exists for one version only, and the question is always the same: can the server move without taking the world into the bin with it. On uniz.host it can, and the copy is made for you before anything is touched. What follows is what the machinery does, in what order, and which direction ends in a server that will not start.
The control lives on the Version & software card in that server's Settings tab, and pressing Change version opens a dialog rather than doing anything. The dialog's opening line is the important sentence — a safety backup runs first, and the change applies only after it succeeds.
Sending the request does exactly two things: it launches a full backup of the server's data folder, and it stamps the change as pending. Nothing about the version or the software has moved yet. You get a confirmation that the backup started, the card grows a banner saying the change will apply automatically once the backup completes, and the change button stays disabled while that banner is up, so a second request cannot stack on the first.
Minutes later a background loop notices the backup job finished and settles the request:
| Backup outcome | What happens to the change |
|---|
| Succeeded | The new version and software are written to the server, the mods list is cleared if that was part of the deal, and the pod template updates |
| Failed | The pending change is discarded unapplied, the server keeps its current version, and the failure is recorded and sent as a notification |
| The job disappears entirely | Treated as a failure after a few sweeps — nothing is applied |
That is the whole safety story: the only path to a changed version runs through a backup that provably exists. It also survives you closing the tab — the request is settled server-side, not by the page you were looking at.
The safety backup does not spend your manual allowance
The backup taken here is filed as an automatic backup, and the limit that stops you piling up backups counts manual ones only — so a version change never costs you a slot. It does join the automatic pool, which is trimmed to the newest few whenever an automatic backup completes, three by default. A pre-change snapshot you want to keep for weeks should be taken manually as well.
One difference by edition. A running Java server can be backed up live: it is told to flush the world and pause autosaving for the length of the copy, and autosaving comes back on when the job settles, so nobody is kicked. Bedrock has no live backup path, so a running Bedrock server's version request is refused until you stop it.
Change the version, step by step
Open the Settings tab and find the Version & software card
The card sits above the per-game settings on Minecraft servers and shows the software, the version pinned today, and an Update available marker when your software has published something newer than your pin. You need the settings permission — the owner has it, a team member needs it granted.
Pick the target version, the software, or both
The version list is fetched per software, from that project's own build catalogue, so you can only pick a version your software actually publishes a build for. Above the concrete versions sits LATEST (auto-update).
The Software select appears for Java servers on the thirteen switchable builds. Bedrock has no software axis at all — only a version field. Switching software re-checks your pinned version against the new software's catalogue and moves you to its newest build if that software never made your version.
Read every warning the dialog shows you
Every red box here names a real failure mode, and more than one can appear at once. The next three sections walk through them.
Decide whether to restart after the change is applied
A checkbox at the bottom offers to restart once the change lands, and it is pre-ticked when the server is running. Leave it ticked and the change is live as soon as the backup settles. Untick it and the change is stored while the running pod keeps the old version until its next restart. On a stopped server it changes nothing: the new version is what boots next time you start it.
Send the request and watch for the backup banner
The submit button stays disabled until something has actually changed and every acknowledgement in view is ticked. After sending, the banner on the card is your progress indicator; when it clears, the card shows the new software and version.
Downgrading is the direction that breaks worlds
Going up is routine. Going down is the one that ends with a server that will not boot, and the dialog says it plainly: Minecraft cannot load worlds saved by a newer version, so the server will not start until you change back or restore the backup. There is no repair, no converter, no fixing it from the console — the world file is simply newer than the game reading it.
The dialog raises this warning whenever it can prove the target sits below your current pin in the same catalogue, and a softer version of it whenever the direction cannot be proven either way — your server is on LATEST, your pinned version has been dropped from the catalogue being compared against, or you switched to software whose newest build predates your current version. That softer wording is the platform refusing to guess about your world, not the platform being vague. If you are downgrading on purpose — because a mod you need never got updated — do it knowing the return trip is the backup, and take a manual one first.
Switching software family clears the mods you installed
Server software falls into families: plugins (Paper, Purpur, Leaf, Folia, Spigot, Bukkit), Fabric (Fabric, Quilt), and Forge (Forge, NeoForge, and the hybrids). Plain vanilla belongs to no family, so moving into it counts as leaving whichever one you were in.
Moving inside a family keeps your installed list. Crossing between families cannot, because a plugin cannot load on a mod loader and a mod cannot load on a plugin server — the files are for different software entirely. So the change clears the installed list as part of applying, and while you have file-installed mods the request will not be accepted until you tick the acknowledgement that says they will be removed. The family warning appears whenever you cross; the acknowledgement only when there is something to lose. Write down what you had installed before you cross — the list is cleared, not archived somewhere you can read it back.
Latest versus pinning a version
LATEST (auto-update) is stored as a sentinel, not as a number, and the newest published build for your software is resolved when the server starts. Two things follow. A LATEST server never shows the update marker, because it cannot be behind. And an ordinary restart — including one you did for an unrelated reason — can move it onto a release that landed yesterday. That is fine on a vanilla server and a genuine hazard on a modded one, because mods are built against specific versions and a new major release routinely leaves them behind for weeks.
A pinned server compares itself against its own software's catalogue and shows the update marker when that software has published something newer — but only while the catalogue still lists your pin, so a pin old enough to have been pruned stays quiet rather than nagging. As of 2026-08-14 the newest Minecraft Java release is 26.2, and Mojang's own manifest is what the picker's vanilla list is derived from.
The Java runtime pin survives the change
If you have ever set the Java runtime field on the settings card by hand, it stays exactly where you put it across a version change. This is the trap that produces a server crash-looping on Java too old for the version it just moved to — the newest releases require Java 25, so a server pinned to java8 for a 1.12-era pack will not boot on them.
The dialog checks this against the version and software you are moving to, and shows a separate warning naming your pinned runtime, with its own acknowledgement to tick. It is a warning rather than a block: nothing stops the change, and the runtime select on the settings card is never disabled by server state, precisely so you can climb out afterwards. Setting that field back to Auto is the fix in almost every case — the full picture is in .
Some combinations are refused outright rather than warned about:
| Situation | Why |
|---|
| A modpack is attached | The pack owns both the software and the version |
| The pack was detached but the software is still the pack type | There is no version catalogue behind that software |
| Changing software on a Bedrock server | Bedrock has no software axis |
| Nothing was actually changed | The request needs at least one axis to move |
| A change is already pending | One safety-backup chain at a time |
| A world reset is pending | Same rule, from the other direction |
| A version that software never built | The picker will not offer it and the API rejects it |
If the new version will not boot
Work down this list rather than restarting and hoping:
- Read the console. A world too new for the game and a Java too old for it fail in visibly different ways, and the first lines after the boot attempt usually name which.
- Check the
Java runtime field on the settings card. If it is anything but Auto, set it back to Auto and start again — that field is editable even while the server is crash-looping.
- Change the version back. Going up to where you were is the fastest recovery from a downgrade, and it takes its own safety backup on the way.
- Restore from the
Backups tab. The safety backup the change took is sitting there, and restoring it returns the world to its pre-change state — at the cost of everything built since.
Read next
- — which Java each version needs, and how Auto picks it
- — the settings card the runtime field lives on
- — the settings that live in the world file, not in our database
- — the same job without a panel