diff --git a/HOSTING.md b/HOSTING.md
index fb65c1c..e6079b0 100644
--- a/HOSTING.md
+++ b/HOSTING.md
@@ -95,6 +95,7 @@ Make sure your Minecraft server itself is running with `online-mode=false` in `s
 - `install.sh` needs `curl`, `unzip`/`find` (standard on any Linux/macOS box) and relies on FUSE for running the AppImage directly; if a participant's distro lacks FUSE, the AppImage will fail to launch — tell them to run `./FjordLauncher.AppImage --appimage-extract` once and point `LAUNCHER_BIN` at the extracted `AppRun`.
 - Re-running either script is safe/idempotent: it skips re-downloading the modpack if the instance folder already exists, and just overwrites `accounts.json` with the (same, deterministic) account if the nickname is unchanged.
 - lazymc's first wake after a sleep takes as long as the Forge server normally does to boot (expect 20–60s depending on the box) — the client will show a "starting" MOTD/kick message during that window; just reconnect after a few seconds.
+- **lazymc is pinned to v0.2.10, not "latest."** v0.2.11 has a confirmed, still-open upstream regression ([timvisee/lazymc#65](https://github.com/timvisee/lazymc/issues/65), [#86](https://github.com/timvisee/lazymc/issues/86)) where it never detects a Forge server as ready — it just perpetually shows the "still starting" kick screen even when the real server has been up and warm for minutes, no matter how long you wait or how many times you reconnect. `forge = true` alone does not fix it. If `setup-server.sh` is ever changed back to pulling "latest," expect this to come back.
 - `setup-server.sh` pins a Forge build (`47.4.28` for `1.20.1`) — check [files.minecraftforge.net](https://files.minecraftforge.net/net/minecraftforge/forge/index_1.20.1.html) if it's gone stale by the time you run this.
 - Double-check the server's mod list is byte-for-byte the same mods as the client instance (same versions) — Forge is strict about mod-list mismatches between client and server and will refuse to connect otherwise. The cleanest way to guarantee this is pulling server-side jars straight out of the exported client zip (`unzip -j modpack.zip "minecraft/mods/*.jar" -d mcserver/mods`), not re-downloading them independently.
 - **`unzip` can extract files with `0000` permissions from zips built on Windows** (seen when extracting a Prism/Fjord-exported instance zip — the jars came out as `----------`, unreadable even by their owner). If the server fails to load mods right after extracting a client zip with errors that don't match what actually worked on the client, check `ls -la mcserver/mods/` first — `chmod -R u+rwX mcserver/mods` fixes it.
diff --git a/server/setup-server.sh b/server/setup-server.sh
index 9277582..6bac594 100755
--- a/server/setup-server.sh
+++ b/server/setup-server.sh
@@ -67,13 +67,13 @@ mkdir -p "$SERVER_DIR/mods"
 echo "==> NOTE: copy the same mod jars from your client modpack's mods/ folder into $SERVER_DIR/mods/ (Create, Flywheel, Farmer's Delight + addons, JEI, etc.) before first boot."
 
 # ---- 2. Install lazymc ----
+# Pinned to v0.2.10, NOT "latest" — v0.2.11 has a confirmed, still-open upstream
+# regression where it never detects a Forge server as ready (timvisee/lazymc#65,
+# #86). 0.2.10 was the last version that correctly detects Forge startup.
+LAZYMC_VERSION="v0.2.10"
 if [[ ! -x "$BASE_DIR/lazymc" ]]; then
-  echo "==> Downloading latest lazymc"
-  api_url="https://api.github.com/repos/timvisee/lazymc/releases/latest"
-  release_json="$(curl -fsSL "$api_url")"
-  asset_url="$(echo "$release_json" | grep -oE '"browser_download_url": *"[^"]+linux-x64"' | cut -d'"' -f4 | head -n1)"
-  [[ -n "$asset_url" ]] || { echo "Could not find linux-x64 lazymc asset" >&2; exit 1; }
-  curl -fsSL -o "$BASE_DIR/lazymc" "$asset_url"
+  echo "==> Downloading lazymc $LAZYMC_VERSION"
+  curl -fsSL -o "$BASE_DIR/lazymc" "https://github.com/timvisee/lazymc/releases/download/${LAZYMC_VERSION}/lazymc-${LAZYMC_VERSION}-linux-x64"
   chmod +x "$BASE_DIR/lazymc"
 else
   echo "==> lazymc already present, skipping"