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"`.