3.3.0

ObserverLauncher 3.3.0

3.3.0 is a feature release. You can now check on a server from another device, keep your
plugins/mods/datapacks up to date from inside the app, and the World Map is smoother to pan. Nothing
about your existing setup changes — no migration, same settings.

This is the plain-English release note. Developers: see the full technical changelog in CHANGELOG.md.

---

Check on your server from another device

New in Settings → Remote access (off by default). Turn it on and you get a small, private web
address you can open from your phone or another PC to see a running server — without opening any
port on your router.

• It can read: server status, the console, who is online, and the list of your servers.
• It can send one console command — but only if you switch Read-only OFF. Read-only is ON by
  default.
• It can never install, edit or delete anything. Those stay in the app.
• Access is protected by a long token (stored encrypted on your PC) and, if you want, a list of
  allowed IP addresses.

The safe way to reach it from outside your home is Tailscale (a free private network between your
own devices). The app links you to a short step-by-step guide. There is also an advanced Bind
option if you prefer to point it at a specific address yourself.

If you run more than one server, you can target any of them — the address accepts ?instance=<id>,
and there is a /instances list to find the ids.

Keep your content up to date

The Content tab now shows the version of each plugin/mod/datapack and a Check updates
button. When a newer build exists, that row gets an Update button — one click installs it over the
old file (the old file is backed up first).

You can also Enable / Disable a plugin or mod without deleting it: disabling renames the file to
….disabled, so it stays on disk and you can turn it back on anytime. (The server ignores disabled
files.)

The same three actions are available to an AI assistant over MCP (check_updates, update_content,
toggle_content) — so a whole batch can be checked and updated in one go.

Datapacks are easier to manage

• .mcfunction and .snbt files are now editable in the built-in editor (most folder datapacks
  are made of these).
• Extract a .zip datapack into a folder in one step (folder datapacks are easier to edit).
• Validate a datapack before you start the server: the app reads its pack.mcmeta and warns you if
  the pack is built for a different Minecraft version (a common cause of a datapack that silently does
  nothing or crashes the world). If the version is too new to know, it says so honestly instead of
  guessing.
• Unzipped datapacks now show up in the list and can be deleted normally (before, a folder
  datapack was invisible).

The World Map is lighter

• Panning is smoother — the map no longer re-computes colours for every cell on every frame, and
  it draws large same-coloured areas in one go.
• The small overview map refreshes a few times a second instead of on every frame, and scales to big
  worlds.
• Less memory: the map releases its biome/colour caches when you leave the tab.

Recovering from a mistake

When an AI assistant (over MCP) writes or edits a file for you, the app now keeps a backup copy of
the previous file first — so an unwanted change can be recovered, just like the player-data editor
already did.

Smaller things

• The background status check asks the server for TPS less often when everything is healthy, and
  immediately when it is not — a little less work for a busy server.
• Cleaned up unused text strings (no visible change).

---

Upgrade note: your settings and servers are untouched — there is no migration in this release.
Just install 3.3.0 over 3.2.5 as usual.

3.2.5

ObserverLauncher 3.2.5

3.2.5 is a fix and polish release. No new features — it fixes a few things that could go wrong when
you run more than one server, corrects the World Map colours on some worlds, and makes the app a little
lighter to run.

This is the plain-English release note. Developers: see the full technical changelog in [CHANGELOG.md].

---

Running more than one server is safer now

If you manage several servers in one window, three rough edges are fixed:

• Switching servers no longer shows the wrong file. Before, if you had a config file open in the
  Content tab and switched to another server, the editor still showed the first server's file — and
  saving could write it into the wrong folder. Now the editor returns to its list when you switch, and
  the settings panel refreshes for the server you just opened.
• You cannot delete a server that is running. If a server is running in the background and you try
  to remove it, the app now stops you with a clear message instead of leaving a hidden Java process
  behind. Stop the server first, then remove it.
• Deleting the server you are viewing no longer confuses the app. Removing the active server now
  cleanly moves you to the next one.

Two servers can also no longer share the same name — the second one becomes "Name (2)".

The World Map shows the right colours

On some worlds, The End was drawn with the wrong colours (green and blue, like the Overworld).
This happened because chunks that were still being generated carry a temporary placeholder biome. The
map now reads a biome only from fully generated chunks, so The End looks like The End. Colour data is
also kept separate per dimension, so switching between Overworld, Nether and The End can never mix
colours.

A lighter World Map

• Panning and zooming the map now redraw only once per frame, so it feels smoother.
• The map uses less memory on big worlds — its chunk/biome caches are capped.
• The background refresh (every 45 seconds while a server runs) no longer re-reads every region file,
  so it does not cause a stutter.
• New buttons: zoom in / zoom out and Fit spawn (centre the map on the world spawn).
• Touch and pen now work on the map, not just the mouse.

Behind the scenes

• CI is more reliable: a temporary outage of the Paper download service now skips the boot test
  instead of failing it; the Docker image is built and checked on every change (so the old "container
  that could not start" class of bug cannot come back); and publishing uses a single workflow, so a
  release always gets both the installers and the modpack file.
• Less duplicated code: a new automated check scans for copy-pasted blocks across the codebase and
  fails the build when it finds one. It already removed nine real duplicates.
• A long note that was accidentally repeated six times in the 2.2.0 changelog was cleaned up.

Nothing to migrate. The settings file format is unchanged (still v4).

3.2.0

ObserverLauncher 3.2.0

3.2.0 makes a Minecraft server setup verifiable in CI. You describe a modpack in a simple
modpack.json, and on every pull request a check proves the pack is consistent — correct game version,
correct loader, no two files fighting over the same name, no missing required mod — before anything is
downloaded. It also adds a one-command build and a persistent "is this server stable?" record.

This is the plain-English release note. Developers: see the full technical changelog in CHANGELOG.md.

---

Describe your modpack in a file

Instead of clicking through the marketplace, you can keep a small text file next to your server:

{
  "name": "My Server Pack",
  "version": "1.0.0",
  "minecraft": "1.21.1",
  "loader": "neoforge",
  "items": [
    { "id": "jei", "kind": "mod", "source": "modrinth" }
  ]
}

This file is now the single source of truth for what your pack contains. It lives in version control, so
you can see exactly what changed and when.

Catch a broken pack before you download it

A new command checks the file:

observer modpack verify modpack.json

It looks each item up and reports problems it can see without downloading anything:

• a mod built for the wrong loader (a Fabric mod in a NeoForge pack),
• a mod for the wrong Minecraft version,
• two mods that would write the same file,
• a required mod that is missing.

If it cannot look an item up at all, that is treated as a failure too — a pack we cannot prove is
compatible should not quietly pass. Add --offline when you only want the file checked, with no network.

Every pull request checks itself

A GitHub Action runs that check automatically whenever a modpack.json changes, so a broken pack can
never be merged by accident. There is also a heavier, opt-in job that actually builds the pack and
boots a real Minecraft server from it — because that needs a lot of memory and about a minute, it runs
only when you ask for it (a nightly run, a manual trigger, or a pull request labelled e2e).

Build the pack in one command

observer modpack build modpack.json --out my-server

This downloads every item into a fresh server folder — with the same safety checks (allowed hosts only,
file hashes verified) the normal marketplace install uses. Refuses to build if anything could not be
resolved, so you never get half a pack.

Ship the pack as a download

When you push a version tag, CI builds every modpack.json in the repository into a ready-to-run
archive (.tar.gz) and attaches it to that release on GitHub — next to the app installers. You can also
do it locally:

node scripts/modpack-publish.js --out dist

The archive contains the resolved jars and the install manifest, so a friend can download one file and
drop it into a server folder. Same safety checks as the build above: allowed hosts only, hashes verified.

Did the server stay up?

ObserverLauncher now keeps a small persistent note of each server run: when it started and how it ended.
A run that survives a couple of minutes counts as stable; if a server crashes early several times in a
row, the Console recommends a rollback so a bad update cannot loop forever. This record lives on disk, so
it survives even a launcher crash, which the old in-memory counters did not.

---

Under the hood: a small code-health pass removed duplicated CSS and JavaScript, and two unused
translation keys were dropped. A new duplicate-code guard (tests/no-dup.test.js) runs as part of the
test suite, so a copy-pasted CSS rule or JavaScript block now fails the build. CI also builds the Docker
image on every change and loads the headless entry point inside it, closing the gap that once shipped a
container that could not start. Note for old servers: Minecraft 26.1 and newer requires Java 25 —
the launcher detects this and installs the right Java automatically, so 1.21.x and older still run on
their own Java. The settings file format is unchanged (still v4) — nothing to migrate.

3.1.0

ObserverLauncher 3.1.0

3.1.0 puts the headless launcher into a container. If you want to run a Minecraft server on a VPS, a home server or a NAS — somewhere with no desktop — you can now generate a ready-made Docker setup in one command. This release also fixes a handful of command-line rough edges found in 3.0.0.

This is the plain-English release note. Developers: see the full technical changelog in CHANGELOG.md.

---

Run your server in Docker

One command writes everything you need:

observer docker create --type fabric --ram 4 --port 25565 --out my-server

That produces a Dockerfile, a docker-compose.yml, a .dockerignore and a short README. Then:

cd my-server
mkdir -p server data
# put a server jar (or run.sh) in ./server
docker compose up -d

The image bakes its own Java, runs the launcher with no window, and keeps your server folder and your launcher settings in two separate volumes (./server and ./data), so they survive rebuilds. The container restarts automatically after a reboot, and Docker can see whether it is healthy.

Supported server types: Paper, Vanilla, Purpur, Leaf, Folia, Fabric, Forge, NeoForge and Spigot.

Your server folder is found automatically

A fresh container has no server folder configured, which used to leave the launcher reporting "no folder". Now it adopts the mounted /server folder by itself, and there is a observer set-folder <path> command to point it somewhere else. You never have to hand-edit settings.json.

Stopping the container stops the server properly

When you stop the container (or press Ctrl+C), the launcher now shuts the Minecraft server down first — letting it save — then closes cleanly. Only if the server refuses to stop within 15 seconds does it force-kill it. Nothing is lost, and no orphaned server process is left behind.

Command-line fixes

• --instance now actually works. Before, observer <cmd> --instance <id> was documented but quietly ran against whichever server was active. It now targets the instance you asked for.
• observer start stays in the foreground. The server runs attached to your terminal, so you can watch it and stop it with Ctrl+C. If the server crashes, the command returns instead of hanging silently.
• Command-line actions are now recorded. Starting, stopping and installing from the CLI appear in the audit log, just like actions taken through an AI.
• observer set-folder (new) sets the active server folder from the command line — useful for headless setups.

A note on what did not change

• The window. The desktop app is unchanged.
• Your settings and servers. They carry straight over; there is no migration.

What is coming next

• 3.2.0 — CI/CD for modpacks: verify and boot-test a modpack automatically in GitHub Actions.
• 3.3.0 — Remote management: check on your server from elsewhere, designed to be safe by default.

---

Developer notes: npm test (70 files) passes. New: src/main/docker.js (a pure Dockerfile/compose generator), observer docker create, observer set-folder, container-aware shutdown, and a Docker guide in docs/docker.md. The generated image runs node src/headless.js as PID 1 with a baked JRE, a ./server/./data volume split and a cheap PID-1 healthcheck.

3.0.0

ObserverLauncher 3.0.0

ObserverLauncher can now run without its window. That sounds strange for a desktop app, but it is the point: the same launcher that runs your server from the GUI can now run as a plain background program — started from a command line, or driven entirely by an AI assistant over the Model Context Protocol (MCP).

If you only ever use the window, nothing changes. Same screens, same buttons, same look. The new power sits underneath, and the window uses the exact same machinery.

This is the plain-English release note. Developers: see the full technical changelog in CHANGELOG.md.

---

You can now run a server from the command line

There is a new observer command. It gives you the everyday actions without opening the app:

observer status      # is the server running, where is the folder, which Java
observer start       # start the server
observer stop        # stop it gracefully
observer logs        # the last lines of the console
observer players     # who is online / whitelisted / banned
observer backup      # make a world backup
observer doctor      # a full health report
observer list        # all your server instances
observer install ... # install a plugin or mod from a marketplace

Add --json to any of them and the output becomes machine-readable, so you can script it. Add --instance <id> to target one specific server.

You can set a server up from a template

Instead of walking through the wizard and picking plugins by hand, you can start from a ready-made recipe:

observer templates                          # list the recipes
observer init --template survival-5         # show the steps to build it

Three ship today:

• survival-5 — a Paper survival server, tuned for up to 5 players.
• creative-build — a Paper creative world with WorldEdit for fast building.
• modded-performance — a Fabric server with a performance mod set (lithium, ferritecore, krypton).

init prints the exact steps it would run; the same steps are the same actions the app already knows how to do, so nothing is magic.

The app can run with no window at all

A new background mode starts the whole backend — the server manager, metrics, backups, the scheduler and the MCP server — with no window. It is the same code the window uses, so your settings, your server folders and your instances all carry over. Close it with Ctrl+C and it shuts down cleanly.

This is what makes the next part possible.

An AI can now manage a headless server

The app has spoken MCP for a while. Until now that always meant the app was open. Now the MCP server can run in the background with no window, so an assistant can connect and manage a server on a machine that has no desktop at all.

The safety rules are unchanged and now explicit: with no one to click a confirmation box, write and destructive actions are refused by default (and recorded in the audit log). If you want to allow specific ones for automation, you can opt in.

A health check for unattended setups

When the MCP server is running, it answers a simple GET /health with “yes, I’m alive” plus the version — no password needed. That is what a container or a monitoring tool asks. Everything that can do something still needs the secret token.

A better record of what an assistant did

The audit log — the list of write and destructive actions an assistant performed — is now stored as structured entries and keeps its history: instead of throwing everything away when it gets large, it rolls over to older files, so you can still see what happened days ago.

Linux is now officially verified

For a long time the Linux build came with a caveat: it was written and reasoned about on Windows, but nobody had actually run it on a real Linux machine. That caveat is gone.

Every change is now checked on a real Linux kernel automatically — the unit tests, the full app test, and, for the first time, a test that downloads a real Paper server, boots it, waits for it to finish starting, and shuts it down cleanly. The Linux-specific parts (finding the server process, reading its memory and CPU, making and restoring a backup) are exercised for real rather than assumed. If a Linux-only problem ever slips in, the build turns red before it reaches you.

---

What did not change

• The window. No new buttons, no moved screens, no colour or layout changes. If 3.0.0 looks identical to 2.6.0, that is on purpose.
• Your settings and servers. They carry straight over; there is no migration and nothing to re-configure.
• The confirmation rules. Write and destructive actions still need approval wherever a person is present.

What is coming next

3.0.0 is the foundation. On top of it:

• 3.1.0 — Docker: package a headless server as a container.
• 3.2.0 — CI/CD for modpacks: verify and boot-test a modpack automatically.
• 3.3.0 — Remote management: check on your server from elsewhere, designed to be safe by default.

---

Developer notes: npm test (68 files) passes. New: a headless entry point, an observer CLI, server templates, an MCP /health endpoint, JSONL audit with rotation, an explicit headless confirm policy, and Linux verified on a real kernel (unit + E2E + a real server boot in CI). The GUI shares every line of backend code with the headless mode.

2.6.0

ObserverLauncher 2.6.0

A polish release. Nothing looks different, no new buttons, no rearranged screens, but the launcher feels better to use. It is harder to break by clicking too fast, friendlier to the keyboard, and it remembers where you were.

This is the plain-English release note. Developers: see the full technical changelog in CHANGELOG.md.

---

The launcher no longer double-fires when you click fast

Some buttons start something that takes a moment. Start server, Stop, Save settings, Apply properties, Create backup, Check for updates, install a mod, and the op / whitelist / ban / kick buttons on a player. If you clicked one twice because nothing seemed to happen yet, it could run the action twice.

Now the button disables itself the instant you press it and only comes back when the job is done. One click, one action — no matter how impatient you are.

You can always get out of a dialog with the keyboard

Before, if you opened a confirmation box and pressed Tab, focus could slip out to the page behind it — you would be typing into a screen that is not really there. Every dialog now keeps the keyboard inside it while it is open, and when you close it, your cursor goes back to the button you clicked to open it.

We also made two more things work without a mouse:

• The player list — click a player row once and you can move up and down with the arrow keys.
• The little "?" help bubbles next to the numbers. you can now reach them with Tab and open them with Enter or Space.

Each tab remembers where you were

Scroll halfway down your Players list, switch to the Console and come back. you land exactly where you left off, instead of snapping to the top. The Console is the one exception: it always follows the newest line, because that is what a console is for.

And when you go to the next page of Marketplace results or the player list, it jumps to the top of the new page instead of leaving you at the bottom of the old one.

Oops, wrong one? Undo.

If you remove a server from the instance list by mistake, the confirmation now comes with an Undo button in the corner. One click puts it back. (This was never dangerous — removing an instance never deletes your server folder. but it is easier than re-adding the folder by hand.)

Error messages in plain language

When something fails. a flaky connection, a full disk, a file another program is using. you used to sometimes see the raw technical error. These are now turned into short, readable sentences in your language, so you know what happened and what to try next.

The small stuff

• The TPS number now eases to its new value the same way CPU and memory already did, so the readouts move together instead of one of them jumping.
• A handful of buttons that used to change state before their action finished now wait for the real result first.

A note on what did not change

No screens, buttons, colours or layouts were touched in this release. If 2.6.0 looks identical to 2.5.0, that is on purpose — the improvement is in how it behaves, not how it looks.

---

Developer notes: npm test (58 files) and npm run test:e2e (12 tests) both pass. The motion-token ratchet is unchanged. 2.6.0 adds shared helpers (withBusy, trapFocus/releaseFocus, friendlyError, toast actions) and 8 new localized strings.

2.5.0

ObserverLauncher 2.5.0

A two-way AI integration release, plus a new Autonomous Doctor and a license change. If you use the MCP / AI tools, or you want an assistant that can watch your server instead of only being asked, this one is for you.

This is the plain-English release note. Developers: see the full technical changelog in CHANGELOG.md.

---

The AI can now watch your server, not just answer questions

Before, the AI could only ask your launcher for something and get one answer. Now it can subscribe to live parts of your server and be told when they change:

• Metrics history (TPS, MSPT, CPU, RAM, players over time)
• The newest console lines
• The player list
• All of your server instances

This means an assistant can react to a lag spike or a crash as it happens, instead of you having to ask it to check again and again.

A doctor that proposes fixes (you still say yes)

The Server Doctor could already tell you what was wrong. It can now build a repair plan you can review before anything happens:

• Port already in use → proposes a free port and a restart.
• A mod is missing a required dependency → proposes installing it from the marketplace.
• Memory climbing / running hot → proposes lowering view distance (and suggests more RAM if it looks like a leak).
• Crash loop (several crashes in an hour) → proposes rolling back to your newest backup.

Nothing changes on its own. The assistant shows you the plan, and each fix needs your confirmation. Destructive fixes (a rollback) always ask, even if you turned on auto-allow.

License changed to Apache-2.0

ObserverLauncher is now under the Apache License 2.0 instead of MIT. For you as a user, nothing changes — it is still free and open. The difference is legal: Apache 2.0 includes an explicit patent grant and a patent-retaliation clause, which MIT does not. A new NOTICE file lists third-party components.

Bug fixes

• The doctor can now actually install a mod it finds missing. Modrinth search does not match a run-together name like alexsmobs against the real project name (Alex Mobs), so the doctor used to propose a dependency it then could not install. It now tries name variations, looks up the project directly, and — if more than one mod matches — shows you the list instead of silently installing the wrong one.
• Installing a mod no longer picks the wrong loader. A NeoForge server can no longer receive a Forge-only build.
• Installing an update while a server is running now works. Before, the launcher could fail to apply an update if a server was running (the update install and the "let the world save first" logic fought each other). It now stops the server first, waits for it to save, then installs.
• Downloads from the mod registries are more reliable. A brief network hiccup no longer fails a search or version lookup — it retries a couple of times.

Smaller improvements

• The AI approval pop-up now shows a short, readable summary of what the assistant wants to do (for example "Install Sodium (mod)" or "3 fixes: change_port, restore_backup") instead of a wall of raw JSON.
• The server list in the sidebar no longer replays its animation every time you switch tabs.
• Removed some leftover code tied to an old chart that no longer exists.

What to watch out for

• The two-way subscription and the Autonomous Doctor need a client that supports MCP resources and notifications. If your client does not, everything still works the old way — the tools are unchanged.
• apply_fix is a destructive-tier tool: it always asks for confirmation and is written to the audit log.
• Updates are not code-signed yet, so Windows may show a SmartScreen prompt when installing one.
• Nothing else changed for normal server hosting.

2.4.0

ObserverLauncher 2.4.0

A performance and telemetry polish release, driven by real use: hosting a NeoForge modpack server. If the launcher felt heavy while a server was running, or the in-app Performance tab showed nothing useful, this one is for you.

---

The launcher is much lighter now

The app was quietly burning ~17% CPU even when the server was idle — because it started a fresh PowerShell process every single second just to read the server's memory and CPU. That's gone:

• The app now keeps one background PowerShell helper and reuses it, instead of spawning a new one every second.
• Reading the server's process tree is cheaper and more reliable.
• When the window is hidden, its timers are throttled.

Result: idle CPU drops dramatically, and you no longer see a pile of "Console Window Host" / "Windows PowerShell" processes sitting next to the app in Task Manager.

The Performance tab now actually shows your server

If you host a server started by run.bat (NeoForge / Forge with no .jar), the Performance tab used to show 0% CPU and 0 MB — because it was measuring cmd.exe (the script runner) instead of the real Java process. It now tracks the actual JVM, so the CPU and RAM graphs match what the server is really using (your 4 GB, etc.).

TPS / MSPT show up on NeoForge

NeoForge rejects the old forge tps command, so the launcher gave up on TPS and the graphs stayed empty — even with Spark installed. Now:

• When the native TPS command is rejected, the launcher automatically uses spark tps instead.
• Spark prints its numbers across two lines; the launcher now reads both, so TPS and MSPT appear on the Performance tab just like on Paper servers.
• The chatty spark tps output is hidden from the console so it no longer spams your log.

What to watch out for

• Nothing to configure — these are all automatic. Just make sure Spark is installed if you want TPS on a NeoForge server that doesn't support forge tps.
• Everything else — the setup wizard, Java handling, backups, and the MCP / AI tools — is unchanged from 2.3.0.

---

Full technical changelog (for developers): see CHANGELOG.md → [2.4.0] in the repository.

2.3.0

ObserverLauncher 2.3.0

Better AI-assisted modpack building. If you use the MCP / AI integration to install mods, this release fixes the most common way a plan that "looks fine" ends up crashing your server on startup.

---

The big one: no more "looks fine, then crashes"

When an AI assistant installed a batch of mods for you, it could pick a version built for Forge on a NeoForge server, or for the wrong Minecraft version, and the plan still said everything was OK — then the server refused to start. That can't happen anymore:

• The planner now checks every mod against your real server (loader + Minecraft version) and refuses versions that don't match, instead of just warning.
• It works even for NeoForge/Forge servers that start from run.bat (no .jar file) — the launcher reads the server's own files to figure out what it is.
• The batch installer skips any incompatible item and tells you which ones it skipped, and why.

Missing dependencies, caught before the crash

Some mods need other mods that aren't listed anywhere online — a classic example is Kotlin for Forge. The launcher now opens each downloaded mod and reads what it actually requires, then reports anything still missing before you start the server.

There's also a new check_mod_compat you (or your AI assistant) can run on any server: it scans mods/ for jars built for the wrong loader, client-only mods, missing required dependencies, and mods that are supposed to be absent (incompatible ones).

Better crash explanations

• explain_crash now reads the server log, not just the crash report. It used to say "No associated exception found" while the real cause — a missing mod, or a jar for the wrong loader — was sitting in latest.log. It now lists the exact missing mods and skipped jars.
• New read_crash_report reads a crash report directly from your server folder (the old file reader was rooted at the project, not the server).

Smaller improvements

• Searching the marketplace can now be pinned to a specific loader (NeoForge / Forge / Fabric / Quilt), so a NeoForge search no longer returns Forge builds. Searches also wait longer before timing out when several run at once.
• list_content now shows each mod's loader and its client/server environment — so you can tell at a glance which mods are client-only (they do nothing useful on a dedicated server).
• check_performance says "metrics are warming up" instead of showing an empty result right after a server starts.

What to watch out for

• These changes make the AI path stricter on purpose: if a mod genuinely has no build for your loader and Minecraft version, it will now be skipped rather than installed and crashing. You can still force a specific item through if you know what you're doing.
• Everything else — the setup wizard, Java handling, backups — is unchanged from 2.2.0.

---

Full technical changelog (for developers): see CHANGELOG.md → [2.3.0] in the repository.

2.2.0

ObserverLauncher 2.2.0 —

This is the user-facing summary for the GitHub Release. No jargon. The developer changelog is
in CHANGELOG.md; the two are kept in sync.

The big one: create a server without it landing in the wrong place

If you had more than one server, creating a new one could quietly target a different server's
folder — the wizard would complain the folder "already has a server jar" (showing another server's
jar) even though the new folder was empty. That's fixed. Each server now stays in its own folder.

Also: a server creation that failed used to leave an empty leftover instance behind. Now it doesn't
(a cancel still keeps your work so you can resume).

Downloads that actually work

• Paper and Folia used to fail with "no stable build" right after a new Minecraft version came
  out, because the launcher was picking an early test build. It now picks the newest stable build
  automatically and tells you which one it chose.
• NeoForge used to install a test version for the wrong Minecraft version. Now you pick your
  Minecraft version first, then see that version's builds (newest stable first, test builds clearly
  marked).
• Forge/NeoForge installer now catches a corrupt download before running it, and if the install
  fails it shows the real reason instead of a blank error.

A friendlier setup wizard

• Server software is now a card picker: pick Paper, Purpur, Fabric, Forge, NeoForge, Vanilla and
  more, each with a short description and what it needs. Vanilla is marked Recommended for
  beginners.
• You can step back to change the Minecraft version (before, NeoForge was a dead end).
• The review screen shows where the download comes from, which Java it needs, and warns you if your
  Java is too old.
• Downloads show speed and time remaining, with a Cancel button.
• Errors are now plain: network, checksum, missing Git/JDK, folder not empty, out of disk space,
  or "no stable build" (which jumps you back to pick a version).

Java: the right version, automatically

• The launcher now installs the Java the server actually needs. Old servers (Minecraft 1.16.5 and
  older) need Java 8 — before, they got Java 21 and wouldn't start.
• Servers launched by run.bat (NeoForge/Forge with no .jar) now get the right Java too: the
  launcher reads the server's files to figure out which Minecraft version it is, so an old 1.16.5
  Forge server gets Java 8, not Java 21.
• Overview shows "needs Java 21, have 25" and gives you a one-click Install button when your
  Java is missing, too old, or too new (so you can drop Java 25 to 21 if a mod needs it).
• If you have several Java versions installed, a new Installed runtimes dropdown lets you switch
  between them per server.

Smaller fixes

• Renaming an instance no longer crashes (the old browser prompt isn't supported in the app — it now
  uses an in-app dialog).
• The console no longer spams "Unknown or incomplete command" from forge tps on servers that
  reject it.

What to watch out for

• Java is usually backward-compatible, so Java 25 often runs a 1.21.1 server fine. You only need to
  switch to the exact version if a mod or plugin (mixin/ASM) breaks on the newer Java.
• Existing empty leftover instances from earlier versions are not cleaned up automatically — remove
  them with the X button in the sidebar.