From 9b95e96e049223e6373a4994300f2bf841336e73 Mon Sep 17 00:00:00 2001 From: David White Date: Thu, 20 Aug 2026 10:05:08 +0100 Subject: [PATCH] docs: Stop replaces Pause for taking a server offline Pause and Unpause are being removed from FluxOS. Docker reports a paused container as running, so the network could not see the state at all: the load balancer kept routing players to a server whose processes were frozen and which could never answer, monitoring charts flatlined with no explanation, and the reconciler saw a perfectly healthy app. Nothing could release one either - unpause went with it - so a paused container stayed frozen and unrecoverable. Stop does the same job for every procedure documented here. It releases the files, it is visible everywhere as stopped, and it can always be started again. The one thing Pause did that Stop did not - keep the load balancer pointing at this instance so the server comes back on the same node with the same data - now holds for Stop as well. Six world-upload guides said to pause the container before uploading and restart afterwards: terraria, valheim, projectzomboid, minecraftbedrock, windrose and vrising. They now say stop and start. The Control reference drops the two rows and explains why, the management overview no longer lists pause among the per-node actions, and the container status list no longer offers "paused" as a state a container can be in. Left alone deliberately - these are not the FluxOS control: satisfactory's in-game auto-pause setting, Project Zomboid's PauseEmpty= config, Don't Starve Together's "Sim paused" log line, the three MaxGCPauseMillis Java flags, the billing FAQ's pause question, and the ArcaneOS note about services pausing during setup. DEPENDS ON the flux-domain-manager change that keeps an operator-stopped master named as primary. Without it deployed, stopping a g: server drops it out of the load balancer and the primary can move to another node's copy of the data on the next start - which would make the "comes back on the same node" promise above false on the fleet even though it is true in the code. Do not publish ahead of that deploy. Co-Authored-By: Claude Opus 5 (1M context) --- .../applications/management/manage-app/README.md | 2 +- .../applications/management/manage-app/control.md | 4 ++-- .../applications/management/manage-app/information.md | 2 +- docs/fluxcloud/marketplace/games/minecraftbedrock.md | 8 ++++---- docs/fluxcloud/marketplace/games/projectzomboid.md | 6 +++--- docs/fluxcloud/marketplace/games/terraria.md | 8 ++++---- docs/fluxcloud/marketplace/games/valheim.md | 8 ++++---- docs/fluxcloud/marketplace/games/vrising.md | 8 ++++---- docs/fluxcloud/marketplace/games/windrose.md | 6 +++--- 9 files changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/fluxcloud/applications/management/manage-app/README.md b/docs/fluxcloud/applications/management/manage-app/README.md index a17e056..d245c47 100644 --- a/docs/fluxcloud/applications/management/manage-app/README.md +++ b/docs/fluxcloud/applications/management/manage-app/README.md @@ -26,7 +26,7 @@ A quick reference to help you choose the right tool for the task, with links to | Track file-system changes | [File Changes](file-changes) | | See running processes inside your container | [Monitoring](monitoring#processes-overview) | | Read your app's logs | [Log Files](logs) | -| Start, stop, pause, or redeploy single node | [Control](control) | +| Start, stop, restart, or redeploy single node | [Control](control) | | Run a terminal or modify files in-container | [Secure Shell](secure-shell), [Volume Browser](secure-shell#volume-browser) | | Backup or restore container data | [Backup & Restore](backup-and-restore) | | Manage global deployment (all nodes) | [Control](control) | diff --git a/docs/fluxcloud/applications/management/manage-app/control.md b/docs/fluxcloud/applications/management/manage-app/control.md index 4de3d13..ab79ba5 100644 --- a/docs/fluxcloud/applications/management/manage-app/control.md +++ b/docs/fluxcloud/applications/management/manage-app/control.md @@ -37,12 +37,12 @@ General options to control running status of Application. | **Start Application** | Launches the application if it's currently stopped. | | **Stop Application** | Gracefully stops the running application and terminates its processes. | | **Restart Application** | Stops and immediately starts the app again — useful for applying configuration changes or recovering from temporary issues. | -| **Pause Application** | Suspends all active processes within the app without shutting it down. This is like hitting a “pause button” on execution. | -| **Unpause Application** | Resumes previously paused processes and returns the app to its active running state. | | **Remove Application** | Uninstalls the app and deletes all associated data from the current selected FluxNode running the application. This will result in the app being deployed on a different FluxNode. | | **Soft Reinstall** | Restarts the app while preserving persistent data. Ideal for safe updates or config changes. | | **Hard Reinstall** | Wipes persistent data and redeploys the app from scratch. Use with caution — this is best for full resets or destructive testing. | +> **Pause and Unpause have been removed.** A paused container looked healthy to the network — it stayed listed as running, so the load balancer kept sending traffic to a server that could not answer, and monitoring showed a flat line with no explanation. **Stop Application** replaces it: it does the same job (releases files, frees the app for maintenance), it is visible everywhere as stopped, and it can always be started again. + **Pro tip:** Always use **Soft Redeploy** unless you intentionally want to delete stored application state. *** diff --git a/docs/fluxcloud/applications/management/manage-app/information.md b/docs/fluxcloud/applications/management/manage-app/information.md index 784ca04..784f7f9 100644 --- a/docs/fluxcloud/applications/management/manage-app/information.md +++ b/docs/fluxcloud/applications/management/manage-app/information.md @@ -18,7 +18,7 @@ At the top right you'll find a **FluxNode IP selector**, letting you choose whic #### What You'll See -* **Container Status**: Indicates if your container is running, paused, or stopped. +* **Container Status**: Indicates if your container is running or stopped. * **Start Time & Uptime**: Tracks when the container started and how long it has been active. * **Docker Image Info**: Shows the image name and version used. * **Networking Details**: Lists exposed ports and internal IP assignments. diff --git a/docs/fluxcloud/marketplace/games/minecraftbedrock.md b/docs/fluxcloud/marketplace/games/minecraftbedrock.md index 4372cfa..50a4418 100644 --- a/docs/fluxcloud/marketplace/games/minecraftbedrock.md +++ b/docs/fluxcloud/marketplace/games/minecraftbedrock.md @@ -154,9 +154,9 @@ Replace the current world directory in `/data/worlds/` with your backup, then re #### Upload an existing world (from a single-player game or another server) -Simply dropping a new world directory onto a running server is unreliable: the server holds its current world files open and writes autosaves on a timer, so a copy that overlaps with an autosave can leave the directory in a half-written state. The procedure below pauses the container while you swap files in, then points the server at the new world on the next start. +Simply dropping a new world directory onto a running server is unreliable: the server holds its current world files open and writes autosaves on a timer, so a copy that overlaps with an autosave can leave the directory in a half-written state. The procedure below stops the container while you swap files in, then points the server at the new world on the next start. -1. Open **Applications → Management**, select your Minecraft Bedrock app, and switch to **Control → Local → Pause Container**. Pausing stops the server from writing to the current world while you upload. +1. Open **Applications → Management**, select your Minecraft Bedrock app, and switch to **Control → Local → Stop Container**. Stopping releases the world files so the server cannot overwrite your upload. 2. Open the **Volume Browser** and upload your world directory into: ``` @@ -164,7 +164,7 @@ Simply dropping a new world directory onto a running server is unreliable: the s ``` 3. In the same Volume Browser, edit `server.properties` and set `level-name` to exactly match your uploaded directory's name (case-sensitive, no trailing slash). -4. Return to **Control → Local → Restart Container**. The server starts with your uploaded world. +4. Return to **Control → Local → Start Container**. The server starts with your uploaded world. > 💡 **Tip:** `level-name` must match the directory name **exactly** — including case. If your folder is `MyOldWorld`, set `level-name=MyOldWorld`, not `myoldworld`. @@ -194,7 +194,7 @@ If your current primary server becomes unavailable or experiences downtime, one #### Can I use my own world file? -Yes — for example a backup from a single-player save or another server. Because a running server keeps its world files open and writes autosaves on a timer, follow the **Upload an existing world** procedure under [Managing World Files](#managing-world-files): pause the container, upload the world directory, set `level-name` in `server.properties` to match, then restart. +Yes — for example a backup from a single-player save or another server. Because a running server keeps its world files open and writes autosaves on a timer, follow the **Upload an existing world** procedure under [Managing World Files](#managing-world-files): stop the container, upload the world directory, set `level-name` in `server.properties` to match, then restart. *** diff --git a/docs/fluxcloud/marketplace/games/projectzomboid.md b/docs/fluxcloud/marketplace/games/projectzomboid.md index 63e152c..bccfaed 100644 --- a/docs/fluxcloud/marketplace/games/projectzomboid.md +++ b/docs/fluxcloud/marketplace/games/projectzomboid.md @@ -238,9 +238,9 @@ Use the **Volume Browser** to download the world save folder and the `.db` file #### Roll back to a previous backup / Upload an existing world -Simply dropping save files onto a running server is unreliable: the server holds the world files open and writes autosaves on a timer, so a copy that overlaps with an autosave can leave the world in a half-written state. Pause the container first: +Simply dropping save files onto a running server is unreliable: the server holds the world files open and writes autosaves on a timer, so a copy that overlaps with an autosave can leave the world in a half-written state. Stop the container first: -1. Open **Applications → Management**, select your Project Zomboid app, and switch to **Control → Local → Pause Container**. Pausing stops the server from writing to the world while you upload. +1. Open **Applications → Management**, select your Project Zomboid app, and switch to **Control → Local → Stop Container**. Stopping releases the world files so the server cannot overwrite your upload. 2. Open the **Volume Browser** and upload your world folder into: ``` @@ -248,7 +248,7 @@ Simply dropping save files onto a running server is unreliable: the server holds ``` Also upload the matching player database to `/home/steam/Zomboid/db/.db` if you want to keep player accounts and characters. -3. Return to **Control → Local → Restart Container**. The server starts with the uploaded world. +3. Return to **Control → Local → Start Container**. The server starts with the uploaded world. > 💡 **Tip:** When migrating a world from another host, the save folder and database must be renamed to match **your** `SERVERNAME` exactly — Project Zomboid finds them by name. diff --git a/docs/fluxcloud/marketplace/games/terraria.md b/docs/fluxcloud/marketplace/games/terraria.md index 470d7a0..beac3cf 100644 --- a/docs/fluxcloud/marketplace/games/terraria.md +++ b/docs/fluxcloud/marketplace/games/terraria.md @@ -190,21 +190,21 @@ Replace the current `.wld` file in `/root/.local/share/Terraria/Worlds/` with yo #### Upload an existing world (from another host or a single-player save) -Simply dropping a new `.wld` file onto a running server does **not** work reliably: the server holds the current world file open and, if `WORLD_FILENAME` is changed on a live instance, will generate a fresh world before your upload completes. The procedure below performs a clean redeploy so the server boots with your `WORLD_FILENAME` from the start, then swaps the file in while the container is paused. +Simply dropping a new `.wld` file onto a running server does **not** work reliably: the server holds the current world file open and, if `WORLD_FILENAME` is changed on a live instance, will generate a fresh world before your upload completes. The procedure below performs a clean redeploy so the server boots with your `WORLD_FILENAME` from the start, then swaps the file in while the container is stopped. 1. Open **Applications → Management**, select your Terraria app, click the **Settings icon** and open the **Specifications** tab. 2. Switch to the **Component** tab and change `WORLD_FILENAME` to exactly match your world file's filename, including the `.wld` extension. Click **Review** in the top-right corner, confirm, and sign — this update is **free**. 3. Wait until the cloud marks the update as paid and live on the network. 4. Open the **Control** tab and choose **Global → Remove Application**. The app uninstalls from its current nodes and is automatically reinstalled with the new `WORLD_FILENAME` already in place. 5. Wait a few minutes, then return to **Applications → Management**. You should be routed to the new primary instance and see the container status as **running**. -6. Back on the **Control** tab, choose **Local → Pause Container**. Pausing stops the server from holding the world file open while you upload. +6. Back on the **Control** tab, choose **Local → Stop Container**. Stopping releases the world file so the server cannot overwrite your upload. 7. Open the **Volume Browser** and upload your `.wld` file into: ``` /root/.local/share/Terraria/Worlds/ ``` -8. Return to **Control → Local → Restart Container**. The server starts with your uploaded world instead of the one it generated on first boot. +8. Return to **Control → Local → Start Container**. The server starts with your uploaded world instead of the one it generated on first boot. Give it up to a minute to come back. > 💡 **Tip:** The filename **must** match `WORLD_FILENAME` exactly — including case and the `.wld` extension. If your backup is `MyOldWorld.wld`, set `WORLD_FILENAME` to `MyOldWorld.wld`, not `myoldworld.wld`. @@ -240,7 +240,7 @@ If your current primary server becomes unavailable or experiences downtime, one #### Can I use my own world file? -Yes — for example a backup from another host or a single-player save. Because a running server keeps the world file open, you can't just drop a new `.wld` onto a live instance; follow the **Upload an existing world** procedure under [Managing the World File](#managing-the-world-file), which redeploys the app with your `WORLD_FILENAME` set, then has you pause the container, upload the `.wld` file, and restart. +Yes — for example a backup from another host or a single-player save. Because a running server keeps the world file open, you can't just drop a new `.wld` onto a live instance; follow the **Upload an existing world** procedure under [Managing the World File](#managing-the-world-file), which redeploys the app with your `WORLD_FILENAME` set, then has you stop the container, upload the `.wld` file, and start it again. *** diff --git a/docs/fluxcloud/marketplace/games/valheim.md b/docs/fluxcloud/marketplace/games/valheim.md index dfb4376..dbd972e 100644 --- a/docs/fluxcloud/marketplace/games/valheim.md +++ b/docs/fluxcloud/marketplace/games/valheim.md @@ -190,21 +190,21 @@ Replace the current world files in `/config/worlds_local/` with a backup from `/ #### Upload an existing world (from another host or a single-player save) -Simply dropping new world files onto a running server does **not** work reliably: the server holds the current world file open and, if `WORLD_NAME` is changed on a live instance, will generate a fresh world before your upload completes. The procedure below performs a clean redeploy so the server boots with your `WORLD_NAME` from the start, then swaps the files in while the container is paused. +Simply dropping new world files onto a running server does **not** work reliably: the server holds the current world file open and, if `WORLD_NAME` is changed on a live instance, will generate a fresh world before your upload completes. The procedure below performs a clean redeploy so the server boots with your `WORLD_NAME` from the start, then swaps the files in while the container is stopped. 1. Open **Applications → Management**, select your Valheim app, click the **Settings icon** and open the **Specifications** tab. 2. Switch to the **Component** tab and change `WORLD_NAME` to exactly match your world file's filename, without the `.db` / `.fwl` extension. Click **Review** in the top-right corner, confirm, and sign — this update is **free**. 3. Wait until the cloud marks the update as paid and live on the network. 4. Open the **Control** tab and choose **Global → Remove Application**. The app uninstalls from its current nodes and is automatically reinstalled with the new `WORLD_NAME` already in place. 5. Wait a few minutes, then return to **Applications → Management**. You should be routed to the new primary instance and see the container status as **running**. -6. Back on the **Control** tab, choose **Local → Pause Container**. Pausing stops the server from holding the world file open while you upload. +6. Back on the **Control** tab, choose **Local → Stop Container**. Stopping releases the world file so the server cannot overwrite your upload. 7. Open the **Volume Browser** and upload both your `.db` and `.fwl` files into: ``` /config/worlds_local/ ``` -8. Return to **Control → Local → Restart Container**. The server starts with your uploaded world instead of the one it generated on first boot. +8. Return to **Control → Local → Start Container**. The server starts with your uploaded world instead of the one it generated on first boot. > 💡 **Tip:** The filename (without extension) **must** match `WORLD_NAME` exactly — including case. If your backup is `MyOldWorld.db` / `MyOldWorld.fwl`, set `WORLD_NAME` to `MyOldWorld`, not `myoldworld`. @@ -264,7 +264,7 @@ If your current primary server becomes unavailable or experiences downtime, one #### Can I use my own world file? -Yes — for example a backup from another host or a single-player save. Because a running server keeps the world file open, you can't just drop new files onto a live instance; follow the **Upload an existing world** procedure under [Managing the World File](#managing-the-world-file), which redeploys the app with your `WORLD_NAME` set, then has you pause the container, upload the `.db` / `.fwl` pair, and restart. +Yes — for example a backup from another host or a single-player save. Because a running server keeps the world file open, you can't just drop new files onto a live instance; follow the **Upload an existing world** procedure under [Managing the World File](#managing-the-world-file), which redeploys the app with your `WORLD_NAME` set, then has you stop the container, upload the `.db` / `.fwl` pair, and start it again. *** diff --git a/docs/fluxcloud/marketplace/games/vrising.md b/docs/fluxcloud/marketplace/games/vrising.md index 0058ce1..1b24c31 100644 --- a/docs/fluxcloud/marketplace/games/vrising.md +++ b/docs/fluxcloud/marketplace/games/vrising.md @@ -201,9 +201,9 @@ Replace the current world folder in `/mnt/vrising/persistentdata/Saves/v3/` with #### Upload an existing world (from a self-hosted server) -Simply dropping a new world folder onto a running server is unreliable: the server holds its current save files open and writes autosaves on a timer, so a copy that overlaps with an autosave can leave the folder in a half-written state. The procedure below pauses the container while you swap files in, then points the server at the new world on the next start. +Simply dropping a new world folder onto a running server is unreliable: the server holds its current save files open and writes autosaves on a timer, so a copy that overlaps with an autosave can leave the folder in a half-written state. The procedure below stops the container while you swap files in, then points the server at the new world on the next start. -1. Open **Applications → Management**, select your V Rising app, and switch to **Control → Local → Pause Container**. Pausing stops the server from writing to the current world while you upload. +1. Open **Applications → Management**, select your V Rising app, and switch to **Control → Local → Stop Container**. Stopping releases the world files so the server cannot overwrite your upload. 2. Open the **Volume Browser** and upload your world folder into: ``` @@ -211,7 +211,7 @@ Simply dropping a new world folder onto a running server is unreliable: the serv ``` 3. If your uploaded folder's name differs from the current `WorldName`, edit `ServerHostSettings.json` via the Volume Browser and set the `WorldName` field to match your folder's name (case-sensitive). -4. Return to **Control → Local → Restart Container**. The server starts with your uploaded world. +4. Return to **Control → Local → Start Container**. The server starts with your uploaded world. > 💡 **Tip:** `WorldName` must match the folder name **exactly** — including case. If your folder is `MyOldWorld`, set `"WorldName": "MyOldWorld"`, not `"myoldworld"`. @@ -305,7 +305,7 @@ If your current primary server becomes unavailable or experiences downtime, one #### Can I use my own world save? -Yes — for example a backup from another self-hosted server. Because a running server keeps its save files open and writes autosaves on a timer, follow the **Upload an existing world** procedure under [Managing the World File](#managing-the-world-file): pause the container, upload the world folder, set `WorldName` in `ServerHostSettings.json` to match, then restart. +Yes — for example a backup from another self-hosted server. Because a running server keeps its save files open and writes autosaves on a timer, follow the **Upload an existing world** procedure under [Managing the World File](#managing-the-world-file): stop the container, upload the world folder, set `WorldName` in `ServerHostSettings.json` to match, then restart. *** diff --git a/docs/fluxcloud/marketplace/games/windrose.md b/docs/fluxcloud/marketplace/games/windrose.md index 94b5a1d..048f5d4 100644 --- a/docs/fluxcloud/marketplace/games/windrose.md +++ b/docs/fluxcloud/marketplace/games/windrose.md @@ -208,9 +208,9 @@ Rename or delete the matching `RocksDB//Worlds//` folder and #### Upload an existing world -Simply dropping a new world folder onto a running server is unreliable: the server holds its current save open and writes autosaves on a timer, so a copy that overlaps with an autosave can leave the folder in a half-written state. The procedure below pauses the container while you swap files in, then points the server at the new world on the next start. +Simply dropping a new world folder onto a running server is unreliable: the server holds its current save open and writes autosaves on a timer, so a copy that overlaps with an autosave can leave the folder in a half-written state. The procedure below stops the container while you swap files in, then points the server at the new world on the next start. -1. Open **Applications → Management**, select your Windrose app, and switch to **Control → Local → Pause Container**. Pausing stops the server from writing to the current world while you upload. +1. Open **Applications → Management**, select your Windrose app, and switch to **Control → Local → Stop Container**. Stopping releases the world files so the server cannot overwrite your upload. 2. Open the **Volume Browser** and upload your world folder into: ``` @@ -219,7 +219,7 @@ Simply dropping a new world folder onto a running server is unreliable: the serv Use the same `` folder Windrose is currently writing to (the one already present alongside the existing world). 3. In the same Volume Browser, edit `ServerDescription.json` and set `WorldIslandId` to exactly match your uploaded folder's name — the world ID (case-sensitive). -4. Return to **Control → Local → Restart Container**. The server starts with your uploaded world. +4. Return to **Control → Local → Start Container**. The server starts with your uploaded world. > 💡 **Tip:** `WorldIslandId` must match the folder name **exactly** — including case. If your folder is `MyOldIsland`, set `"WorldIslandId": "MyOldIsland"`, not `"myoldisland"`.