# Game Server Hosting - everything RE:NODE has published > Instantly deployed servers for 30 games, from Minecraft and Counter-Strike 2 to Arma 3 and Factorio. NVMe storage, full file access and a console that does not hide anything from you. Generated from https://www.renode.space/game-servers, the live catalogue, the deploy docs, the panel guides and the RE:NODE blog. English. Source of truth for anything that changes: https://www.renode.space/game-servers. > This file is trimmed to stay under 400,000 characters: every post is listed with its link, but only the newest ones are included in full. Open a post's link for its text. Contents: what it is, plans and prices, panel how-to, tutorials, rules for the assistant. ## What it is Every game deploys ready to play: the right runtime, a generated map and its own admin password. Full file manager, SFTP, live console and scheduled tasks on every plan, from 3. Four titles need a credential the publisher issues to a person (a Steam token, a Steam account, a Klei token or a Cfx.re licence). Their pages say so before you pay. The panel runs standard Pterodactyl eggs, so almost anything with a dedicated server can be added. Ask in Discord or open a ticket and tell us which one - most requests are live within a day or two. Each game has its own file with its plans and every tutorial written about it: - [Minecraft](https://www.renode.space/ai/game-servers/minecraft.md) - [Counter-Strike 2](https://www.renode.space/ai/game-servers/counter-strike-2.md) - [FiveM](https://www.renode.space/ai/game-servers/fivem.md) - [Palworld](https://www.renode.space/ai/game-servers/palworld.md) - [Valheim](https://www.renode.space/ai/game-servers/valheim.md) - [Project Zomboid](https://www.renode.space/ai/game-servers/project-zomboid.md) - [7 Days to Die](https://www.renode.space/ai/game-servers/7-days-to-die.md) - [Unturned](https://www.renode.space/ai/game-servers/unturned.md) - [Terraria](https://www.renode.space/ai/game-servers/terraria.md) - [Garry's Mod](https://www.renode.space/ai/game-servers/garrys-mod.md) - [DayZ](https://www.renode.space/ai/game-servers/dayz.md) - [Factorio](https://www.renode.space/ai/game-servers/factorio.md) - [Satisfactory](https://www.renode.space/ai/game-servers/satisfactory.md) - [Team Fortress 2](https://www.renode.space/ai/game-servers/team-fortress-2.md) - [Counter-Strike 1.6](https://www.renode.space/ai/game-servers/counter-strike-1-6.md) - [Arma 3](https://www.renode.space/ai/game-servers/arma-3.md) - [Insurgency: Sandstorm](https://www.renode.space/ai/game-servers/insurgency-sandstorm.md) - [SCP: Secret Laboratory](https://www.renode.space/ai/game-servers/scp-secret-laboratory.md) - [The Isle](https://www.renode.space/ai/game-servers/the-isle.md) - [Sons of the Forest](https://www.renode.space/ai/game-servers/sons-of-the-forest.md) - [The Forest](https://www.renode.space/ai/game-servers/the-forest.md) - [Killing Floor 2](https://www.renode.space/ai/game-servers/killing-floor-2.md) - [Don't Starve Together](https://www.renode.space/ai/game-servers/dont-starve-together.md) - [Abiotic Factor](https://www.renode.space/ai/game-servers/abiotic-factor.md) - [RimWorld](https://www.renode.space/ai/game-servers/rimworld.md) - [BeamMP (BeamNG.drive)](https://www.renode.space/ai/game-servers/beammp.md) - [The Front](https://www.renode.space/ai/game-servers/the-front.md) - [Euro Truck Simulator 2](https://www.renode.space/ai/game-servers/euro-truck-simulator-2.md) - [Assetto Corsa](https://www.renode.space/ai/game-servers/assetto-corsa.md) - [Skyrim Together](https://www.renode.space/ai/game-servers/skyrim-together.md) ### General questions ### Getting started **How quickly is my server ready?** Game, app, web and database servers are created the moment payment clears, usually inside a minute. The game or runtime is installed and started for you, and the console is live in your browser while it happens. VDS and dedicated servers are prepared by hand and delivered within 24 hours. **Do I need to configure anything before it works?** No. The install runs, the configuration is written, and admin passwords are generated for your server rather than shared with everybody else's. The exception is four games whose publisher issues a credential to a person - those say so on the shop before you pay, and ask for it on a Setup tab afterwards. **Which games need a key from me?** Counter-Strike 2 needs a Steam game-server token, Don't Starve Together a Klei cluster token, FiveM a Cfx.re licence, and DayZ, Project Zomboid, 7 Days to Die, Arma 3 and Unturned need a Steam account or token of your own. We cannot create any of them and we never share one between customers. Your server is built immediately and the installation waits until you paste yours in. **Can I try before buying?** There is no free tier. The entry plans start at 1.5 a month precisely so that trying something costs about as much as a coffee. **Can Claude or ChatGPT set my project up?** Yes, and the panel gives it what it needs. On a server's Console tab, pick a purpose and press Connect AI: the panel copies a private link with the runtime, the port the code must read from SERVER_PORT, the code path, the GitHub branch, the databases and the limits. Paste it into Claude, ChatGPT or any assistant that can open links; the same link followed by /mcp works as an MCP server URL. It stops by itself after 7 days unused. You can also connect Claude, or any MCP client, to your whole account at https://panel.renode.space/api/client/mcp. Linked repositories get a pre-flight check that shows what will break before a deploy, no AI needed. No password or token is ever shown to the assistant - the AI setup page explains it all. ### Running the server **Do I get full file access?** Yes - a complete file manager with an in-browser editor, plus SFTP credentials. There is no plan on which the file manager is disabled or read-only. **Can I install mods and plugins?** Yes. Upload them through the file manager or SFTP, or use the game's own workshop support where it has any. Nothing here whitelists which mods you are allowed to run. **Can other people help me run it?** Yes. Invite subusers with granular permissions - console only, files only, no billing - or build a team with a role and grant it access to several servers at once. Permissions are a union, so nobody loses access they were given elsewhere. **What happens if my server runs out of memory?** New servers are configured so the kernel stops the container and it restarts clean, rather than swapping and dragging the whole machine down. If a server restarts repeatedly we warn you on the server page and open a support ticket before anything is suspended - you get told twice before it stops. **Is the CPU limit a hard limit?** Yes, and it cannot be breached: the container is throttled to the share you bought. A server sitting at 100% is slow, not broken, and is never suspended for it. ### Backups and safety **Are backups included?** Every plan carries backup slots - two on the entry tiers, more further up. Take them on demand or on a schedule, and restore with a button rather than a support ticket. **Where are backups stored?** Off the machine they protect. A backup sitting on the same disk as the thing it is insuring covers you deleting your world and covers nothing at all about the disk failing. **What happens to my backups if I cancel?** Deleting a server deletes its backups with it, deliberately and including locked ones. Download anything you want to keep first - the panel lets you. ### Billing **How do I pay?** PayPal, card, your wallet balance, or bank transfer. Every method produces a proper invoice you can download or print, with our details and the bank account on it while it is unpaid. **Can I pay in Georgian lari?** The panel displays every figure in lari at the National Bank of Georgia's published rate, marks converted figures as approximate, and always shows the amount that will actually be charged. Invoices stay in the currency they were raised in, because an invoice is a demand for a specific amount. **What happens when my subscription is due?** An invoice is raised and emailed to you seven days before expiry, and again on the day. Paying it settles that same document rather than raising a second one. **Can I upgrade or downgrade later?** Yes, and it does not rebuild anything. Changing plan changes the limits on the container you already have - your world, files and database stay exactly where they are. **Do you offer refunds?** There is no automatic refund button. If a server cannot do what it was sold to do, open a ticket and we will sort it out - including refunding you. We would rather fix the plan than argue about the policy. ### Support and the honest bits **How do I get help?** Open a ticket from the panel - it reaches every member of staff and every administrator, not a queue aimed at nobody in particular. Attach a screenshot if it helps; attachments are private to your ticket rather than sitting at a guessable public URL. Discord is there for faster, less formal questions. **Is there an uptime guarantee?** We measure node availability every five minutes and report it in the panel rather than printing a number with four decimal places we have not earned. If something is down you will usually hear it from us first. **Who actually runs this?** A small team that writes the panel, the shop and the automation itself. When something is wrong the fix is a code change, which is why the list of things wrong keeps getting shorter. ## Plans and prices Read from the live catalogue at 2026-10-19 13:56 UTC. Prices are in US dollars per month; checkout also takes Georgian lari and bills for 1, 3, 6, 12 or 24 months. Prices change - re-check on https://www.renode.space/game-servers or in the panel shop at https://panel.renode.space before quoting one. - Minecraft: from 5/month, 5 plans, 2 GB-14 GB memory. Every plan: https://www.renode.space/ai/game-servers/minecraft.md - Counter-Strike 2: from 7/month, 5 plans, 1 GB-6 GB memory. Every plan: https://www.renode.space/ai/game-servers/counter-strike-2.md - FiveM: from 9/month, 5 plans, 2 GB-12 GB memory. Every plan: https://www.renode.space/ai/game-servers/fivem.md - Palworld: from 19/month, 4 plans, 8 GB-14 GB memory. Every plan: https://www.renode.space/ai/game-servers/palworld.md - Valheim: from 6/month, 5 plans, 2 GB-8 GB memory. Every plan: https://www.renode.space/ai/game-servers/valheim.md - Project Zomboid: from 9/month, 5 plans, 3 GB-10 GB memory. Every plan: https://www.renode.space/ai/game-servers/project-zomboid.md - 7 Days to Die: from 20/month, 3 plans, 8 GB-14 GB memory. Every plan: https://www.renode.space/ai/game-servers/7-days-to-die.md - Unturned: from 6/month, 5 plans, 2 GB-8 GB memory. Every plan: https://www.renode.space/ai/game-servers/unturned.md - Terraria: from 3/month, 5 plans, 512 MB-4 GB memory. Every plan: https://www.renode.space/ai/game-servers/terraria.md - Garry's Mod: from 5/month, 5 plans, 1 GB-6 GB memory. Every plan: https://www.renode.space/ai/game-servers/garrys-mod.md - DayZ: from 19/month, 4 plans, 6 GB-12 GB memory. Every plan: https://www.renode.space/ai/game-servers/dayz.md - Factorio: from 5/month, 5 plans, 1 GB-6 GB memory. Every plan: https://www.renode.space/ai/game-servers/factorio.md - Satisfactory: from 21/month, 4 plans, 8 GB-14 GB memory. Every plan: https://www.renode.space/ai/game-servers/satisfactory.md - Team Fortress 2: from 6/month, 5 plans, 2 GB-6 GB memory. Every plan: https://www.renode.space/ai/game-servers/team-fortress-2.md - Counter-Strike 1.6: from 3/month, 5 plans, 512 MB-4 GB memory. Every plan: https://www.renode.space/ai/game-servers/counter-strike-1-6.md - Arma 3: from 12/month, 5 plans, 4 GB-12 GB memory. Every plan: https://www.renode.space/ai/game-servers/arma-3.md - Insurgency: Sandstorm: from 9/month, 5 plans, 2 GB-6 GB memory. Every plan: https://www.renode.space/ai/game-servers/insurgency-sandstorm.md - SCP: Secret Laboratory: from 8/month, 5 plans, 4 GB-10 GB memory. Every plan: https://www.renode.space/ai/game-servers/scp-secret-laboratory.md - The Isle: from 16/month, 5 plans, 6 GB-14 GB memory. Every plan: https://www.renode.space/ai/game-servers/the-isle.md - Sons of the Forest: from 20/month, 3 plans, 8 GB-12 GB memory. Every plan: https://www.renode.space/ai/game-servers/sons-of-the-forest.md - The Forest: from 8/month, 5 plans, 3 GB-8 GB memory. Every plan: https://www.renode.space/ai/game-servers/the-forest.md - Killing Floor 2: from 8/month, 5 plans, 3 GB-8 GB memory. Every plan: https://www.renode.space/ai/game-servers/killing-floor-2.md - Don't Starve Together: from 5/month, 5 plans, 1 GB-6 GB memory. Every plan: https://www.renode.space/ai/game-servers/dont-starve-together.md - Abiotic Factor: from 10/month, 5 plans, 4 GB-12 GB memory. Every plan: https://www.renode.space/ai/game-servers/abiotic-factor.md - RimWorld: from 5/month, 5 plans, 1 GB-6 GB memory. Every plan: https://www.renode.space/ai/game-servers/rimworld.md - BeamMP (BeamNG.drive): from 6/month, 5 plans, 2 GB-8 GB memory. Every plan: https://www.renode.space/ai/game-servers/beammp.md - The Front: from 15/month, 5 plans, 6 GB-14 GB memory. Every plan: https://www.renode.space/ai/game-servers/the-front.md - Euro Truck Simulator 2: from 5/month, 5 plans, 1 GB-6 GB memory. Every plan: https://www.renode.space/ai/game-servers/euro-truck-simulator-2.md - Assetto Corsa: from 8/month, 5 plans, 2 GB-8 GB memory. Every plan: https://www.renode.space/ai/game-servers/assetto-corsa.md - Skyrim Together: from 5/month, 5 plans, 1 GB-6 GB memory. Every plan: https://www.renode.space/ai/game-servers/skyrim-together.md ## Panel how-to From the panel guides at https://www.renode.space/guides. ### Ordering a server Ordering takes about a minute and happens in three screens: find what you want to run, pick a plan, and pay. Pay by card or PayPal and the server is set up the moment the payment goes through - you can watch it install in its console. - Takes: About a minute - Pay with: Card, PayPal, crypto or bank transfer - Billed for: 1, 3, 6, 12 or 24 months - Prices in: US dollars or Georgian lari Open the shop and find what you want to run: 1. Sign in to the panel and open the shop. The tabs along the top are the product lines: VDS, Game Servers, App Hosting, Web Hosting and Databases. 2. Find your game - there is a search box - and press View plans. The card already shows the lowest price and the range of memory on offer. Compare the plans and pick one: 3. Every plan lists its memory, CPU and NVMe storage, roughly how many players it suits, and what is included - updates, backup slots, file and SFTP access. 4. Press Get Started on the one you want. Not sure? Start smaller: you can move to a bigger plan later without losing your world. Choose how long, then pay: 5. Pick a billing period - 1, 3, 6, 12 or 24 months. The total for the whole period is shown before you pay, so there are no surprises. 6. Pay with PayPal, or press Debit or Credit Card - paying by card does not need a PayPal account. The server is created as soon as the payment completes. Paying by bank transfer instead: Prefer to pay from your bank? Choose bank transfer at checkout. The server is set up once the payment arrives, usually the next working day. 1. Switch the payment tab to Bank transfer. The account details for Bank of Georgia and TBC Bank appear, each with a Copy button. 2. Press Order & get invoice, then pay that invoice from your banking app, quoting the reference on it. After you pay: - The server appears under My Servers and installs itself. Open it to watch the install in the console. - Your orders, invoices and subscriptions are under Finances in the side menu. - Stuck at any step? Open Support in the side menu and raise a ticket. ### The console Live output, a command line, power controls and the resource graphs. It is the server's own output rather than a filtered summary - if the game prints it, you see it. - Start, stop, restart and kill, with the current state always visible. - Command history with the arrow keys, and tab completion for common commands. - Web-server noise - the internet knocking on doors that are not there - is folded behind a count you can switch off. A real error always prints. - Graphs for memory, CPU and disk against your limits, so whether it is the plan or the mod is answerable. - Average Ping and Hops on the stats strip. Press Test now under the console and the round trip is measured from 12 countries; Hops counts the routers between the server and you, shown as ≥N when the last ones do not answer. Your address is not stored. ### Files and SFTP A complete file manager with an editor in the browser, plus SFTP credentials for the tools you already use. Upload a modpack, fix a config, pull a world down to your machine. - Drag files in, or upload a folder. Archives can be unpacked in place. - Edit any text file with syntax highlighting and save without downloading it. - PDFs and images preview in the panel rather than downloading first, with buttons to open them in a new tab or download them. - SFTP on the same credentials - use FileZilla, WinSCP or your editor's remote mode. ### Backups Take one before you try something. Restore it when the something goes wrong. Lock the ones that matter so they are not rotated away. - Slots on every plan - two on the entry tiers, more further up. - Take one on demand, or on a schedule you set. - Download any backup to your own machine. - Separately, every server is backed up every night, whatever its plan, outside your backup slots. Those are system backups: they are not on the Backups tab, and a restore from one goes through support. - A game server's database is not inside its file archive, so it is dumped on its own every night. - We pull copies off the node every day, so a backup does not live only on the machine it protects. > Important: Deleting a server deletes its backups, including the locked ones. A lock stops you removing a backup by accident; it is not a claim on the disk after the server is gone. Download what you want to keep before you cancel. ### Subusers, roles and teams Give somebody the console without giving them your files, or the files without your billing. Three separate ideas, kept apart deliberately. - A role holds permissions - what may be done. - A team holds people. - A grant joins a team to a server with a role, so adding a moderator to the team gives them the same access everywhere at once. - Invite by link, by a join code, or by email address - and require approval on the codes if you would rather vet people. - Access can be time-boxed, and expiry stops working immediately rather than overnight. ### Scheduled tasks Restart nightly, back up before the restart, announce it to players first. Tasks run in order with delays between them, so a schedule can be a small routine rather than one action. - Send a console command - a warning to players, a save, a world flush. - Take a backup. - Power actions: start, stop, restart. ### Games that need a key from you A few games want a credential their publisher issues to a person - a Steam game-server token, a Steam account that owns the server files, a Klei cluster token, a Cfx.re licence. We cannot create one and we never share one between customers. > Note: Those games say so on the shop before you pay. Your server is built immediately, and the game installation is held until you paste the value into a Setup tab, because installing without it produces a server with no game files in it and no explanation. ## Tutorials 157 posts, newest first. The newest 17 follow in full after the list; open the link for the rest. - [Pull server backups to your own PC: a Windows backup agent](https://www.renode.space/blog/backup-agent-pull-backups-to-your-pc) (2026-10-16): Why a copy of your server backups belongs on a machine you own, and how to pull them to a Windows PC on a schedule with a short PowerShell script. - [Connect Claude to your game server or app with MCP](https://www.renode.space/blog/connect-claude-to-your-game-server) (2026-10-16): Step by step: add the RE:NODE MCP endpoint to Claude Code, Claude.ai or Claude Desktop, sign in once with OAuth, and know what the AI can and cannot touch. - [Hosting bundles explained: app, database and cache together](https://www.renode.space/blog/hosting-bundles-explained) (2026-10-16): What a RE:NODE bundle contains, what it saves against list price, who each of the twelve stacks fits, and when buying the plans separately is the better call. - [Loyalty pricing: how hosting renewals get cheaper over time](https://www.renode.space/blog/loyalty-pricing-how-renewals-get-cheaper) (2026-10-16): How RE:NODE loyalty pricing works: 2% more off each month renewed without a gap, the 20% floor, the 35% stacking cap, grace, freeze and enrolment. - [Nightly server backups outside your quota: what they cover](https://www.renode.space/blog/nightly-backups-outside-your-quota) (2026-10-16): Every RE:NODE server is backed up each night without using your backup slots, databases included. What that covers, how a restore works, and why you still keep a copy. - [Pay for hosting with crypto: coins, fees and confirmation times](https://www.renode.space/blog/pay-for-hosting-with-crypto) (2026-10-16): How paying for a server in USDT, BTC, ETH or LTC works on RE:NODE: coin minimums, network fees, 10-60 minute confirmations and what to do if a payment goes wrong. - [Reading ping and hops on your game server panel](https://www.renode.space/blog/reading-ping-and-hops-on-your-server) (2026-10-16): What the Ping, Average Ping and Hops figures on the RE:NODE panel measure, what they cannot see, and how to use them when players say the server lags. - [The RE:NODE panel in Georgian: switching language and what changes](https://www.renode.space/blog/renode-panel-in-georgian) (2026-10-16): The RE:NODE panel now runs in Georgian - console, billing, shop, files, backups, AI bar and support chat. How to switch, what is translated and what stays English. - [Free trial server: how RE:NODE trials work, no card needed](https://www.renode.space/blog/try-before-you-pay-free-trial) (2026-10-16): How a RE:NODE free trial works: which plans have one, 24-hour and 30-day modes, daily Renew, one per account, and keeping the same server when you pay. - [SteamCMD errors and fixes: a reference for server admins](https://www.renode.space/blog/steamcmd-errors-and-fixes) (2026-10-15): What SteamCMD errors really mean - Missing configuration, No subscription, Disk write failure, state 0x202 and 0x602, timeouts, 32-bit libraries - and how to fix each. - [SteamCMD login and Steam Guard: anonymous vs account](https://www.renode.space/blog/steamcmd-login-and-steam-guard) (2026-10-15): When SteamCMD needs a real Steam login, how Steam Guard codes and cached credentials work, and how to use a spare account so a server never holds your main one. - [SteamCMD on Windows: install, scripts and updates](https://www.renode.space/blog/steamcmd-on-windows) (2026-10-15): Set up SteamCMD on Windows: the first-run self-update, force_install_dir, batch files with +runscript, Task Scheduler updates and Defender exclusions. - [Choosing a hosting provider: what to look at, from the inside](https://www.renode.space/blog/choosing-a-hosting-provider-from-the-inside) (2026-10-14): What matters when picking a game server, VDS or app host, from the operator's side: CPU, 'unlimited', status pages, backups, access, support and red flags. - [Game server backups to S3: off-site world copies on a schedule](https://www.renode.space/blog/game-server-backups-to-s3) (2026-10-08): Copy game worlds and saves to S3 storage every night with rclone or restic: what to copy, getting a clean save, keeping history, pruning, and restoring. - [Announcing server maintenance to players](https://www.renode.space/blog/announcing-maintenance-and-downtime) (2026-10-07): When and how to warn players about game server maintenance, in-game countdown commands, automated restart warnings, and what to post during and after an outage. - [ARK cluster setup and cross-server transfers](https://www.renode.space/blog/ark-cluster-and-cross-server-transfers) (2026-10-07): How an ARK: Survival Ascended cluster works: the cluster ID, the shared directory, upload and download rules, transfer limits, and what breaks between maps. - [ARK Ascended mods on a server via CurseForge](https://www.renode.space/blog/ark-mods-curseforge-on-server) (2026-10-07): Add CurseForge mods to an ARK: Survival Ascended server: finding project IDs, the -mods list, map mods, mod settings, updates, and removing a mod safely. - [ARK Ascended server ini settings](https://www.renode.space/blog/ark-survival-ascended-game-ini-settings) (2026-10-07): Which ARK: Survival Ascended settings belong in GameUserSettings.ini and which in Game.ini, with rates, breeding, imprinting and stat multipliers explained. - [Arma Reforger server: config.json and mods](https://www.renode.space/blog/arma-reforger-dedicated-server) (2026-10-07): Set up an Arma Reforger dedicated server: SteamCMD install, every config.json block, scenario IDs, Workshop mods, crossplay, ports, admins and RCON. - [Astroneer dedicated server setup and ports](https://www.renode.space/blog/astroneer-dedicated-server) (2026-10-07): Run an Astroneer dedicated server: install, every key in AstroServerSettings.ini, port 8777, PublicIP, owner and whitelist, moving a save and fixing join errors. - [Automating game server updates safely](https://www.renode.space/blog/automating-game-server-updates) (2026-10-07): Update on restart, scheduled SteamCMD updates and validate explained: which servers can update themselves safely, which must not, and how to stage the rest. - [Barotrauma dedicated server and mods](https://www.renode.space/blog/barotrauma-dedicated-server) (2026-10-07): Run a Barotrauma dedicated server: install, serversettings.xml, ports 27015 and 27016, permissions and ranks, console commands, LocalMods and campaign saves. - [BattlEye and Easy Anti-Cheat on servers](https://www.renode.space/blog/battleye-and-easy-anti-cheat-on-servers) (2026-10-07): What BattlEye and Easy Anti-Cheat actually do on a dedicated server, which switches and files belong to you, how bans work, and what neither will ever catch. - [Cheapest way to host a server for friends](https://www.renode.space/blog/cheapest-way-to-host-a-server-for-friends) (2026-10-07): Honest options for hosting a server for friends: in-game hosting, free hosts, a spare PC at home, Realms and small rented plans, with real costs and catches. - [Choosing a game for your group's server](https://www.renode.space/blog/choosing-a-game-for-your-server) (2026-10-07): Which game suits your group's server: co-op crews, persistent communities, competitive and roleplay players, with player caps, admin effort and costs. - [Conan Exiles server: settings, mods, purge](https://www.renode.space/blog/conan-exiles-dedicated-server) (2026-10-07): Set up a Conan Exiles dedicated server: ServerSettings.ini, Engine.ini and Game.ini, ports, admin and RCON, Workshop mods with modlist.txt, purge and saves. - [Core Keeper dedicated server: setup and saves](https://www.renode.space/blog/core-keeper-dedicated-server) (2026-10-07): Set up a Core Keeper dedicated server: SteamCMD install, ServerConfig.json and launch flags, Game ID or direct connect, world modes, saves and backups. - [Cross-play on dedicated game servers](https://www.renode.space/blog/cross-play-dedicated-servers-explained) (2026-10-07): Which games let PC, Xbox and PlayStation players share a dedicated server, how console players connect, and what cross-play costs in mods, admin and latency. - [Discord bots for game server admins](https://www.renode.space/blog/discord-bots-for-game-server-admin) (2026-10-07): Which Discord integrations game servers actually use, how to give a bot console access without handing Discord your RCON, and a small slash-command admin bot. - [Eco server setup: configs and world settings](https://www.renode.space/blog/eco-server-guide) (2026-10-07): Run an Eco dedicated server: Network.eco and the other config files, world size, meteor timing, admins, the web UI on port 3001, mods in UserCode and saves. - [Enshrouded dedicated server: config and ports](https://www.renode.space/blog/enshrouded-dedicated-server-guide) (2026-10-07): Set up an Enshrouded dedicated server: enshrouded_server.json key by key, user groups and passwords, ports, moving a local world in, and keeping saves safe. - [First game server checklist, start to finish](https://www.renode.space/blog/first-game-server-checklist) (2026-10-07): A beginner's checklist for a first game server: pick game and size, secure the panel, set passwords and admins, test the connection, back up, schedule restarts, invite. - [Game server admin account security](https://www.renode.space/blog/game-server-admin-account-security) (2026-10-07): How each game decides who is an admin, why shared admin passwords and name-based admins leak, and how to give staff power you can take back cleanly. - [Game server admin plugins compared](https://www.renode.space/blog/game-server-admin-plugins-compared) (2026-10-07): Which admin tool each game uses - SourceMod, AMX Mod X, CounterStrikeSharp, ULX and SAM, LuckPerms, Oxide, txAdmin, TShock - what each gives you and what vanilla lacks. - [Game server autosave: how often to save](https://www.renode.space/blog/game-server-autosave-intervals) (2026-10-07): Autosave settings for Valheim, Minecraft, Rust, Palworld, ARK, Factorio and more, what each save costs in lag, how much progress a crash loses, and how to set them. - [Game server backup strategy, game by game](https://www.renode.space/blog/game-server-backup-strategy) (2026-10-07): Which folders hold the world in each popular game, how to get a consistent copy, how many backups to keep, and where the off-site copy should live. - [Game server bandwidth per player, by game](https://www.renode.space/blog/game-server-bandwidth-per-player) (2026-10-07): How much upload each player costs on Minecraft, Source games, Valheim, Arma 3, Factorio and more, the settings that change it, and how to size and measure server traffic. - [Game server config formats: ini, json, xml](https://www.renode.space/blog/game-server-config-file-formats) (2026-10-07): How to edit every game server config format - ini, json, yaml, xml, cfg, lua and toml - the syntax rules that break servers, and how to check a file first. - [Game server CPU: clock speed vs cores](https://www.renode.space/blog/game-server-cpu-requirements) (2026-10-07): Why one fast core decides how most game servers run, how many vCPU each game really uses, what a CPU percentage means and how to prove the CPU is the limit. - [Game server crash loops: find the bad mod](https://www.renode.space/blog/game-server-crash-loops-diagnosis) (2026-10-07): How to read a game server crash loop, tell a broken mod from a corrupt save or a bad config, and bisect a mod folder to the one file at fault in a few starts. - [Discord for a game server: channels and roles](https://www.renode.space/blog/game-server-discord-setup) (2026-10-07): Set up a Discord for your game server: a channel layout, roles and permission overrides, verification against raids, bots, and linking roles to the game. - [Game server disk full: what to delete](https://www.renode.space/blog/game-server-disk-space-full) (2026-10-07): What fills a game server's disk - logs, local backups, crash dumps, map tiles, Workshop caches - how to find the biggest folders, and what is safe to delete. - [Game server events and tournaments](https://www.renode.space/blog/game-server-events-and-tournaments) (2026-10-07): How to run events and tournaments on a game server: picking a format, scheduling across timezones, preparing the server, rules, prizes and the night itself. - [Game server exploits and crash bugs](https://www.renode.space/blog/game-server-exploits-and-crash-bugs) (2026-10-07): How crash exploits, dupes and remote code bugs reach game servers, what Log4Shell taught Minecraft owners, and the patches, limits and settings that blunt them. - [Game server file permissions and ownership](https://www.renode.space/blog/game-server-file-permissions-and-ownership) (2026-10-07): Why a game server says Permission denied: Linux owners and modes, the executable bit, read-only configs, and which of your staff can touch which files. - [Game server for a school or club](https://www.renode.space/blog/game-server-for-a-school-or-club) (2026-10-07): How to run a game server for a school, club or youth group: choosing a game, whitelists, chat and moderation, staff access, schedules, data and budgeting. - [Game server glossary in plain English](https://www.renode.space/blog/game-server-glossary) (2026-10-07): Plain-English definitions of game server terms: dedicated, headless, tick rate, TPS, query port, RCON, GSLT, SteamCMD, egg, allocation, wipe, whitelist, OOM and more. - [Game server listing and voting sites](https://www.renode.space/blog/game-server-listing-and-voting-sites) (2026-10-07): How server listing and voting sites work, getting your server polled correctly, NuVotifier vote rewards on Minecraft, list rules and paid slots worth skipping. - [Game server logs: where and what to search](https://www.renode.space/blog/game-server-logs-explained) (2026-10-07): Where Minecraft, Source, Unity, Unreal, DayZ, Zomboid and other game servers write their logs, which files matter, and the exact strings worth searching for. - [Game server map rotation and custom maps](https://www.renode.space/blog/game-server-maps-and-map-rotation) (2026-10-07): How map rotation works across game servers: mapcycle.txt, CS2 map groups, Squad layers, Arma missions, KF2 and Sandstorm cycles, map votes and custom map downloads. - [Game server memory leaks: find and fix them](https://www.renode.space/blog/game-server-memory-leaks) (2026-10-07): How to tell a real memory leak from world growth and a full heap, find the plugin or mod behind it in Java, Lua, Unity and Source servers, and contain it meanwhile. - [Game server ping by region: what to expect worldwide](https://www.renode.space/blog/game-server-ping-by-region) (2026-10-07): Typical ping from each part of the world to a game server in Western Europe, what that feels like in shooters, survival and racing games, and how to measure it fairly. - [Game server privacy: player data and GDPR](https://www.renode.space/blog/game-server-privacy-and-player-data) (2026-10-07): What personal data a game server collects, when GDPR applies to a community server, how long to keep IP logs, and how to answer access and deletion requests. - [Game server save files: where worlds live](https://www.renode.space/blog/game-server-save-files-explained) (2026-10-07): Where dedicated servers keep worlds and player data for Minecraft, Valheim, Palworld, 7 Days to Die, Zomboid, Satisfactory and more, and how to copy them safely. - [Game server startup parameters by game](https://www.renode.space/blog/game-server-startup-parameters-explained) (2026-10-07): What launch flags do on a game server: -flag, +convar and ?option styles, panel startup variables, and real command lines for Source, Unity, Unreal and Java. - [Game server update day checklist](https://www.renode.space/blog/game-server-update-day-checklist) (2026-10-07): A checklist for the day a game patches: backup first, check mods and plugins, update with SteamCMD, test, tell players, and roll back cleanly if it breaks. - [Game server version pinning and rollbacks](https://www.renode.space/blog/game-server-version-pinning-and-rollbacks) (2026-10-07): How to keep a game server on a known build, use Steam beta branches, fetch an older depot, and roll a server and its world back when an update goes wrong. - [Game server whitelist applications](https://www.renode.space/blog/game-server-whitelist-applications) (2026-10-07): Run whitelist applications for a game server: when to use one, questions that filter, vetting applicants, whitelist commands per game and handling data. - [Whitelist vs password for a private server](https://www.renode.space/blog/game-server-whitelist-vs-password) (2026-10-07): Password, whitelist, hidden listing or accounts: how each way of keeping a game server private works, its weak spots, and the exact settings in popular games. - [Global ban lists across game servers](https://www.renode.space/blog/global-ban-systems-for-communities) (2026-10-07): How shared ban systems work for a network of servers or between communities: SourceBans++, Minecraft ban plugins, BattleMetrics lists, the database and the risks. - [Handling cheaters: evidence and ban lists](https://www.renode.space/blog/handling-cheaters-and-ban-lists) (2026-10-07): How to confirm a cheater before you act, record evidence that survives an appeal, ban by the right identifier in each game, and keep ban lists that last. - [Holdfast: Nations At War server config](https://www.renode.space/blog/holdfast-server-config-guide) (2026-10-07): Set up a Holdfast: Nations At War server: install, the serverconfig file, ports, map rotation blocks, game modes, map voting, mods, auto-restarts and rc admin. - [Rust server RAM: sizing by map and wipe](https://www.renode.space/blog/how-much-ram-does-a-rust-server-need) (2026-10-07): Real Rust server memory figures by world size and population, why usage peaks the day before a wipe, what plugins add, and how to stop a map generation crash. - [ARK server RAM: Ascended and Evolved](https://www.renode.space/blog/how-much-ram-does-an-ark-server-need) (2026-10-07): ARK server memory by map, tribe count and mods for Survival Ascended and Evolved, the ini settings that set the ceiling, clusters, and why saves freeze. - [Game server storage: disk space by game](https://www.renode.space/blog/how-much-storage-does-a-game-server-need) (2026-10-07): How much disk a game server really needs: install sizes by game, how saves, mods, logs and backups grow, the free space updates need, and how to find what filled it. - [Icarus dedicated server setup and prospects](https://www.renode.space/blog/icarus-dedicated-server) (2026-10-07): Run an Icarus dedicated server: install, every ServerSettings.ini key, the 5-minute auto-shutdown, creating and resuming prospects, ports 17777 and 27015, admin commands. - [LAN party server setup: network and games](https://www.renode.space/blog/lan-party-server-setup) (2026-10-07): How to set up servers for a LAN party: wired network layout, a local server box vs a hosted server, LAN mode per game, Steam download caching and the usual failures. - [Left 4 Dead 2 addons and SourceMod](https://www.renode.space/blog/left-4-dead-2-addons-and-sourcemod) (2026-10-07): Install VPK addons and custom campaigns on an L4D2 server, fix addon conflicts, set up SourceMod with left4dhooks, and run 8 or more survivors without breaking it. - [Linux vs Windows for game servers](https://www.renode.space/blog/linux-vs-windows-game-servers) (2026-10-07): Which dedicated servers ship Linux builds, which are Windows-only, and the real differences: memory, cost, case-sensitive paths, mods with DLLs and shutdown. - [Malicious plugins and mods on game servers](https://www.renode.space/blog/malicious-plugins-and-mods) (2026-10-07): The four routes backdoored plugins take onto servers, what the code looks like in Minecraft, Garry's Mod and FiveM, how to search for it, and what to do when you find it. - [Mod load order on game servers](https://www.renode.space/blog/mod-load-order-explained) (2026-10-07): How mod load order, dependencies and conflicts work on game servers - Minecraft, Arma and DayZ, 7 Days to Die, Factorio, RimWorld, Zomboid, ARK and FiveM. - [Mordhau dedicated server: config, maps, mods](https://www.renode.space/blog/mordhau-dedicated-server) (2026-10-07): Set up a Mordhau dedicated server: SteamCMD install, Game.ini keys, map rotation, the three ports, admins by PlayFab ID, admin commands, mod.io mods and tick rate. - [NAT and CGNAT: why home game servers fail](https://www.renode.space/blog/nat-and-cgnat-for-game-hosts) (2026-10-07): How NAT, CGNAT and DS-Lite block inbound connections, what NAT types and hole punching mean for co-op hosting, and the real ways out when you cannot port forward. - [OpenTTD server: openttd.cfg, network, AI](https://www.renode.space/blog/openttd-server-guide) (2026-10-07): Run an OpenTTD dedicated server: openttd -D, the network settings in openttd.cfg, invite codes, ports 3979 and 3977, rcon, AI companies, NewGRFs and autosaves. - [Port forwarding vs hosted game servers](https://www.renode.space/blog/port-forwarding-vs-hosted-servers) (2026-10-07): What a port forward really does, the router features that break it at home, and what changes on the network when the server lives in a datacentre instead. - [Pterodactyl eggs for game servers](https://www.renode.space/blog/pterodactyl-eggs-for-game-servers) (2026-10-07): How a Pterodactyl egg works field by field: Docker images, the startup line, variables and rules, config parsers, the install script, done detection and stop. - [Query ports and A2S: server status queries](https://www.renode.space/blog/query-ports-and-a2s) (2026-10-07): What the query port answers, how Valve's A2S protocol and its challenge work, how to query any Steam server from a script, and why a query fails while the game works. - [Game server CPU: what 100% on one thread means](https://www.renode.space/blog/reading-game-server-cpu-usage-single-thread) (2026-10-07): Why a game server lags at 100% CPU on a multi-core plan, how panels count CPU per core, and how to find the main thread, throttling and tick time yourself. - [RedM server setup: server.cfg and txAdmin](https://www.renode.space/blog/redm-server-setup-guide) (2026-10-07): Set up a RedM server for Red Dead Redemption 2: the same FXServer as FiveM, gamename rdr3, game builds, resource manifests, ports, txAdmin and sizing. - [RedM roleplay frameworks: VORP vs RSG](https://www.renode.space/blog/redm-vorp-and-rsg-frameworks) (2026-10-07): VORP and RSG compared for RedM roleplay: how each is built, database and oxmysql setup, resource load order, ecosystem, performance and which to start with. - [A modded server for friends, minus the hassle](https://www.renode.space/blog/running-a-modded-server-for-friends) (2026-10-07): Run a small modded server for friends: pick a pack or list, get everyone on identical mods, size the memory, install, update without breaking the world. - [Running a test game server beside production](https://www.renode.space/blog/running-a-test-server-beside-production) (2026-10-07): How to run a second game server for testing updates, mods and configs: what to copy, what must differ, sizing it cheaply, and promoting changes safely. - [Rust admin commands: bans, teleport, spectate](https://www.renode.space/blog/rust-admin-commands) (2026-10-07): The Rust admin commands you will actually use - owner and moderator grants, kicks and bans, teleport, spectate, noclip, items - and how to make them stick. - [Rust Carbon vs Oxide: switching frameworks](https://www.renode.space/blog/rust-carbon-mod-framework) (2026-10-07): How the Carbon mod framework for Rust differs from Oxide, which plugins carry over, how to install it on Windows or Linux, and how to switch safely. - [Rust custom maps, world size and seeds](https://www.renode.space/blog/rust-custom-maps-and-procedural-size) (2026-10-07): Pick a Rust world size and seed for your population, preview maps before wipe day, and host a custom .map file with server.levelurl that downloads cleanly. - [Rust dedicated server setup: install and ports](https://www.renode.space/blog/rust-dedicated-server-setup) (2026-10-07): Install RustDedicated with SteamCMD, write a startup line that works, open the right ports and get through the first boot and map generation without surprises. - [Rust modded server: gather rates and kits](https://www.renode.space/blog/rust-modded-server-gather-rates-and-kits) (2026-10-07): Set up a 2x, 3x or 5x Rust server properly: gather rates, stack sizes, smelting, kits, the Modded listing, and keeping the economy and lag in check. - [Rust force wipe schedule: dates and times](https://www.renode.space/blog/rust-monthly-force-wipe-schedule) (2026-10-07): When the Rust force wipe lands, the first Thursdays through 2027, how to fit weekly or biweekly wipes around four- and five-week months, and what to automate. - [Rust Oxide plugins: install and permissions](https://www.renode.space/blog/rust-oxide-umod-plugins) (2026-10-07): Install Oxide on a Rust server, add uMod plugins, edit their JSON configs, set up groups and permissions, and survive the monthly update without losing them. - [Rust RCON and WebRCON: setup and security](https://www.renode.space/blog/rust-rcon-and-webrcon) (2026-10-07): Enable WebRCON on a Rust server, connect RustAdmin, BattleMetrics or a script, read the JSON messages, and keep rcon.password from being the weak point. - [Rust server.cfg and convars: decay and upkeep](https://www.renode.space/blog/rust-server-cfg-and-convars) (2026-10-07): Where Rust keeps server.cfg and users.cfg, how convars load, and the settings that matter - listing, PvE, AFK kicks, decay, upkeep - with what each one does. - [Rust server performance: entities and FPS](https://www.renode.space/blog/rust-server-performance-entities) (2026-10-07): Read a Rust server's frame rate and entity count, find what drags them down - bases, plugins, garbage collection, map size - and fix lag without guessing. - [SCUM admin commands, squads and logs](https://www.renode.space/blog/scum-admin-commands-and-squads) (2026-10-07): Make yourself a SCUM server admin, use the # chat commands safely, manage squads, flags and bans, and read the server logs that settle every dispute. - [SCUM server lag, puppet caps and loot](https://www.renode.space/blog/scum-server-performance-and-loot) (2026-10-07): Size and tune a SCUM server: RAM and CPU by player count, what really causes lag, puppet and vehicle caps, database growth, and the Loot override folder. - [SCUM server settings: ServerSettings.ini](https://www.renode.space/blog/scum-server-settings-guide) (2026-10-07): A guide to SCUM's ServerSettings.ini: where it lives, the scum. key format, time of day, puppets, loot multipliers, fame, respawn and the files beside it. - [Server not showing in the Steam list?](https://www.renode.space/blog/server-browser-visibility-steam-master-server) (2026-10-07): Why a running game server does not appear in the Steam or in-game browser: master server registration, query ports, tokens, filters and the per-game list flags. - [Soulmask dedicated server setup and saves](https://www.renode.space/blog/soulmask-dedicated-server) (2026-10-07): Run a Soulmask dedicated server: install, launch parameters, ports 8777, 27015 and 18888, GameXishu.json, admin access, the world.db save and backups. - [SourceMod admin flags, groups and immunity](https://www.renode.space/blog/sourcemod-admin-flags-and-immunity) (2026-10-07): Every SourceMod admin flag, the admins_simple.ini and admins.cfg formats, groups, immunity levels and sm_immunity_mode, and command overrides that fit your staff. - [Space Engineers server: config and PCU](https://www.renode.space/blog/space-engineers-dedicated-server) (2026-10-07): Set up a Space Engineers dedicated server: SpaceEngineers-Dedicated.cfg, world settings, PCU and block limits, ports, admins, mods and keeping sim speed at 1.0. - [Squad Workshop mods and layer rotation](https://www.renode.space/blog/squad-mods-and-layers) (2026-10-07): How Squad layers are named and rotated, how to install Workshop mods on a dedicated server, add mod layers to LayerRotation.cfg, and keep a modded server joinable. - [Squad Server.cfg, admins and bans](https://www.renode.space/blog/squad-server-config-and-admins) (2026-10-07): Run a Squad server's staff and rules properly: the ServerConfig folder file by file, admin groups and permissions, bans, reserved slots, remote lists and rotations. - [SRCDS basics: launch options and cfg](https://www.renode.space/blog/srcds-source-dedicated-server-basics) (2026-10-07): How srcds works for TF2, Garry's Mod, CS:S and L4D2: srcds_run, launch options, server.cfg and the cfg folder, ports, logs, updates and common errors. - [Starbound server config and mods](https://www.renode.space/blog/starbound-server-guide) (2026-10-07): Run a Starbound dedicated server: SteamCMD install, every key in starbound_server.config, accounts and admins, port 21025, commands, mods and universe backups. - [Starting a roleplay server community](https://www.renode.space/blog/starting-a-roleplay-server-community) (2026-10-07): How to start a roleplay server that survives its first month: picking a game and framework, RP rules people understand, staff roles, scripts and launch. - [Stationeers dedicated server setup](https://www.renode.space/blog/stationeers-dedicated-server) (2026-10-07): Set up a Stationeers dedicated server: SteamCMD install, the -file start and -settings launch syntax, worlds, ports, admin access, saves and performance tuning. - [Steam connect links and direct connect](https://www.renode.space/blog/steam-connect-links-and-direct-connect) (2026-10-07): How steam://connect links, console connect commands and direct IP join work, with passwords, per-game syntax and why some links do nothing when clicked in Discord. - [SteamCMD app IDs and beta branches](https://www.renode.space/blog/steamcmd-app-ids-and-beta-branches) (2026-10-07): Server and game app IDs for 30 dedicated servers, how to list and switch beta branches, beta passwords, when validate helps and which installs need a login. - [Game server tunnels: playit.gg, frp and VPS](https://www.renode.space/blog/tunnels-and-proxies-for-game-servers) (2026-10-07): How tunnels like playit.gg, frp and WireGuard on a VPS put a home game server online behind CGNAT, what they cost in latency and real player IPs, and when to use one. - [Unity dedicated server: batchmode and logs](https://www.renode.space/blog/unity-dedicated-server-basics) (2026-10-07): How Unity game servers run: -batchmode and -nographics, where Player.log goes, the _Data folder, Mono vs IL2CPP for mods, and the errors that are only noise. - [Unreal Engine dedicated server: ini and ports](https://www.renode.space/blog/unreal-engine-dedicated-server-basics) (2026-10-07): How Unreal Engine dedicated servers work across Palworld, ARK, Satisfactory and others: the Saved/Config layout, Engine.ini, launch flags, ports, logs and crashes. - [V Rising dedicated server: settings and admins](https://www.renode.space/blog/v-rising-dedicated-server-guide) (2026-10-07): Run a V Rising dedicated server: ServerHostSettings.json and ServerGameSettings.json explained, ports 9876-9877, admins, PvP windows, saves and backups. - [Vintage Story server: setup, config and mods](https://www.renode.space/blog/vintage-story-dedicated-server) (2026-10-07): Run a Vintage Story dedicated server: install and .NET runtime, serverconfig.json key by key, world generation settings, roles and whitelist, mods and backups. - [TeamSpeak vs Mumble for gaming communities](https://www.renode.space/blog/voice-servers-teamspeak-mumble-for-communities) (2026-10-07): When a community needs its own TeamSpeak or Mumble server instead of Discord, how to set each up, the ports to open, and how much CPU, RAM and bandwidth voice uses. - [Why players cannot connect to your server](https://www.renode.space/blog/why-players-cannot-connect-to-your-server) (2026-10-07): Find why players cannot join a game server, step by step: is it up, listening, reachable, on the right port and accepting them, with the errors each step causes. - [Wine and Proton: Windows game servers on Linux](https://www.renode.space/blog/wine-and-proton-for-windows-only-servers) (2026-10-07): How to run a Windows-only dedicated server on Linux with Wine or Proton: the prefix, winetricks, Xvfb, SteamCMD platform forcing, clean stops and common errors. - [Cloudflare for websites and game servers](https://www.renode.space/blog/cloudflare-for-websites-and-game-servers) (2026-09-21): The orange cloud carries HTTP and nothing else. What that means for a Minecraft server, an SRV record, SSL modes and your origin address. - [DDoS attacks on game servers: an honest look](https://www.renode.space/blog/ddos-attacks-on-game-servers-explained) (2026-09-21): What the three attack layers actually do, why UDP games are cheap to hit, what upstream filtering can and cannot drop, and what you can do that helps more. - [Game server RAM, CPU and disk by game](https://www.renode.space/blog/game-server-requirements-by-game) (2026-09-21): A single table of sensible RAM, vCPU, disk and port numbers for every game we host, then the reason each genre needs what it needs. - [Growing a game server community](https://www.renode.space/blog/growing-a-game-server-community) (2026-09-21): How servers actually get players and keep them: listings, the first ten minutes, Discord that is not dead, events, and the numbers worth tracking. - [How much does a game server cost per month?](https://www.renode.space/blog/how-much-does-a-game-server-cost) (2026-09-21): What drives the price of a game server, starting prices by game, why Palworld costs four times Terraria, and what the monthly figure does not include. - [Choosing game server hosting: a checklist](https://www.renode.space/blog/how-to-choose-game-server-hosting) (2026-09-21): The questions to ask before you pay any host: latency you measured yourself, what the CPU share really is, whether backups are yours, and how to leave. - [Monetising a game server within the rules](https://www.renode.space/blog/monetising-a-game-server-within-the-rules) (2026-09-21): What Minecraft, FiveM and Valve actually let you sell on a server, how a store is wired to the game, and the chargebacks and tax nobody warns you about. - [Several game servers on one VDS](https://www.renode.space/blog/multiple-game-servers-on-one-vds) (2026-09-21): How to run four or five game servers on one box: a port map, one user each, systemd units with limits, LinuxGSM, staggered updates and backups, and when not to bother. - [Pterodactyl panel: Wings, eggs and containers](https://www.renode.space/blog/pterodactyl-panel-explained) (2026-09-21): What Pterodactyl actually is: the panel, the Wings daemon, eggs, and one Docker container per server. What a panel-based host gives you, and what it cannot. - [Reading traceroute and MTR correctly](https://www.renode.space/blog/reading-traceroute-and-mtr) (2026-09-21): Loss in the middle of a trace usually means nothing. How traceroute works, what the MTR columns mean, and how to tell a real fault from a decoy. - [Game server at home vs renting one](https://www.renode.space/blog/self-hosting-a-game-server-at-home-vs-renting) (2026-09-21): When a spare PC at home is genuinely enough, and when CGNAT, upload speed, electricity or your own IP address make renting the cheaper answer. - [Server rules, moderation and staff](https://www.renode.space/blog/server-rules-moderation-and-staff) (2026-09-21): Rules people can be held to, the logs that make a ban stick, how few staff you need, panel permissions, a sane ban ladder and an appeals process. - [Steam game server login tokens (GSLT)](https://www.renode.space/blog/steam-game-server-tokens-gslt) (2026-09-21): What a GSLT is, who may create one, which app id to use, where the token goes in each game, what gets one banned, and why you should never accept one from a host. - [Steam Workshop mods on dedicated servers](https://www.renode.space/blog/steam-workshop-mods-on-dedicated-servers) (2026-09-21): How Workshop content reaches a server and its players: item ids, SteamCMD downloads, collections, per-game config keys, update breakage, disk cost and trust. - [SteamCMD: updates, betas and scripts](https://www.renode.space/blog/steamcmd-explained) (2026-09-21): What SteamCMD is, how app ids work, anonymous versus account logins, what validate really does, beta branches, unattended update scripts and every common error. - [TCP vs UDP: why game servers use UDP](https://www.renode.space/blog/tcp-vs-udp-for-game-servers) (2026-09-21): Why almost every game speaks UDP, what that costs you in firewall rules and proxies, and how to test a UDP port properly when telnet is useless. - [How a dedicated game server actually works](https://www.renode.space/blog/what-is-a-dedicated-game-server) (2026-09-21): A dedicated game server runs the game with nobody playing on it. What that changes, what it needs in RAM, CPU and ports, and how to run one properly. - [Game server ports: query, RCON and firewalls](https://www.renode.space/blog/game-server-ports-explained) (2026-09-01): Every port a game server uses, what the query port is for, why a running server never appears in the browser, and how to test a port from outside. - [ARK: Survival Ascended dedicated server](https://www.renode.space/blog/ark-survival-ascended-server-setup) (2026-08-28): What Ascended costs in memory, the GameUserSettings.ini and Game.ini keys that decide whether your island is playable, ports, RCON, mods and clusters. - [Why your game server keeps restarting](https://www.renode.space/blog/why-your-game-server-keeps-restarting) (2026-08-25): Out-of-memory kills, crash loops, schedules you forgot and tokens that expired - how to tell them apart from exit codes and console lines, and what to fix. - [Rust wipes without losing your players](https://www.renode.space/blog/rust-wipes-without-losing-your-players) (2026-07-14): What Rust's forced wipe actually forces, which files a map wipe and a BP wipe delete, how to pick a cadence, and a wipe-day runbook that does not lose people. - [Left 4 Dead 2 server setup and lobby settings](https://www.renode.space/blog/left-4-dead-2-server) (2026-07-03): Running an L4D2 dedicated server: the install, server.cfg and Director cvars, lobbies and sv_search_key, custom campaigns, more than four players, and fixes. - [Squad server hosting: licence and config](https://www.renode.space/blog/squad-server-hosting) (2026-06-19): Running a Squad dedicated server: the Offworld licence and its conditions, Server.cfg, Admins.cfg, RCON, the five ports, Workshop mods and holding 50 Hz. - [Tick rate and why your server feels slow](https://www.renode.space/blog/what-tick-rate-actually-means) (2026-06-09): TPS, MSPT, ping and frame rate are four different numbers. How to read each one, which of them your players are complaining about, and what fixes each. - [What we do about attacks and what no host can](https://www.renode.space/blog/what-we-do-about-attacks) (2026-06-02): Which attacks upstream filtering actually drops, why player-shaped floods get through, and the query, whitelist and moderation settings that do the rest. - [Game server location and latency](https://www.renode.space/blog/choosing-where-your-server-lives) (2026-05-26): Latency is distance divided by the speed of light. How to choose a location for the players you actually have, measure it honestly, and read the numbers. - [SFTP and the file manager for your server](https://www.renode.space/blog/sftp-and-the-file-manager) (2026-05-19): Both reach the same filesystem. Which one to use for a config edit, a plugin folder or a whole world, and the traps that quietly eat an upload. - [How many players fit on a server, by game](https://www.renode.space/blog/how-many-players-fit-on-a-server) (2026-05-08): Slot counts are a config number. What really limits concurrency is memory, tick budget and bandwidth - plus a table of realistic player counts for 20 games. - [CPU or RAM: what limits your game server](https://www.renode.space/blog/cpu-vs-ram-for-game-servers) (2026-05-01): Memory is what gets sold and clock speed is usually what limits you. How to tell them apart in thirty seconds, with the exact commands, graphs and fixes. - [Bandwidth, fair use and unmetered hosting](https://www.renode.space/blog/bandwidth-and-fair-use) (2026-04-17): How much traffic a game or web server actually uses, the sums that turn kilobytes per second into a monthly figure, and what unmetered does not cover. - [Scheduled tasks every game server needs](https://www.renode.space/blog/scheduled-tasks-worth-having) (2026-03-31): The cron expression, the task order and the delays that make a schedule safe: warnings, saves, backups, dumps and restarts, with the commands per game. - [Game server restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) (2026-02-20): A nightly restart is a workaround, not maintenance. When it genuinely helps, how often to run one, and how to tell what it is quietly hiding. - [Moving a game server without losing players](https://www.renode.space/blog/moving-a-server-without-losing-players) (2026-02-13): The order of operations that makes a migration uneventful: what to copy, when to stop the old server, how DNS TTL really behaves, and how to roll back. - [When a mod update breaks your server](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) (2026-01-16): The triage that gets a modded server running again in ten minutes: read the crash report, find the file that changed, roll it back, and stop it repeating. - [Server monitoring: four checks worth alerting](https://www.renode.space/blog/monitoring-that-tells-you-something) (2026-01-09): Uptime checks that catch real outages, thresholds for memory, disk and CPU, where the alert should land, and the rule that keeps the list short. - [Subdomains for game servers and apps](https://www.renode.space/blog/subdomains-for-servers) (2025-12-19): Why every server should have its own name, how to create the record, what a subdomain cannot carry, and the TTL routine that makes a migration boring. - [Domain for a game server: A and SRV records](https://www.renode.space/blog/connecting-a-domain-to-a-game-server) (2025-12-12): A game server lives at an address and a port, and a domain carries only the address. The three ways to bridge that gap, and how to prove it worked. - [IPv6 and game servers: benefits and pitfalls](https://www.renode.space/blog/ipv6-and-game-servers) (2025-11-28): Support is uneven across games, launchers and tooling. What works over IPv6, what silently does not, and why dual-stack is the only sane answer today. - [Latency, jitter and packet loss in games](https://www.renode.space/blog/latency-jitter-and-packet-loss) (2025-11-21): Players call all of it lag. The three have different causes and different fixes, and a sixty-second ping test tells you which one you are looking at. - [The firewall rules that actually matter](https://www.renode.space/blog/firewall-rules-that-matter) (2025-11-14): Default deny, a short allow list, and the three ports people leave open without meaning to. With the ufw and nftables rules to copy and the audit commands. - [Safe RCON: ports, passwords and the console](https://www.renode.space/blog/rcon-safely) (2025-10-24): Remote console is a plaintext password on an open port. How RCON works per game, which ports to close, and when the panel console replaces it entirely. - [Mod and plugin safety on a modded server](https://www.renode.space/blog/keeping-a-modded-server-clean) (2025-10-17): Mods run with your server's permissions. Where to download them, how to check a jar before it runs, the signs of a compromise, and how to clean up after one. --- ### Pull server backups to your own PC: a Windows backup agent Published 2026-10-16 by RE:NODE Team. https://www.renode.space/blog/backup-agent-pull-backups-to-your-pc A backup that lives with the same provider as the server it protects covers most accidents, but not all of them. The ones it misses are the ones where you lose access to the provider side: a deleted server, a lapsed payment, a compromised account. The fix is cheap: keep a second copy on a machine you control, usually the PC you are reading this on. You can do it by hand from the panel's Backups tab, or you can let a small scheduled script do it for you - list the server's finished backups, download any it does not have yet, check that each archive opens, and delete the oldest local copies. This post builds that script for Windows, schedules it with Task Scheduler, and covers the parts people get wrong: what an archive does and does not contain, where the API key lives, and how to tell a good copy from a corrupt one. One note before we start, because the name invites it. We run a program of our own, also called the RENODE Backup Agent, to pull copies off the node every day for our platform. That one is internal and is not something you download. What follows is the same idea, built from parts any Windows machine already has, pointed at your own servers. #### Why a copy on your own machine matters Backups on a hosting panel are already a good deal better than nothing. On RE:NODE they are stored off the machine they protect, so a dead disk on the node does not take the backups with it, and you can lock a backup so that rotation never removes it. That covers the common failures: a bad plugin update, a corrupted world, a config edit that will not boot. What a provider-side backup cannot cover is the provider side itself. The plain cases: - **The server is deleted.** Deleting a server on RE:NODE deletes its backups too, locked ones included. That is the right behaviour for privacy, and it means a mistaken delete, or a subuser with too much access, takes every copy at once. - **The service lapses.** A card expires, the renewal email lands in spam, and a server you stopped watching runs past its grace period. Whatever happens to the files then, they are no longer yours to fetch. - **The account is compromised.** Someone with your panel password and no 2FA can delete backups before they delete anything else. A copy on your PC is out of their reach. - **You want to leave.** Moving to another host, or to a box at home, starts with having the data. A folder of archives on your own disk is the easiest migration you will ever do. This is the old 3-2-1 rule with the numbers filled in: three copies (the live server, the panel backup, your PC), on two kinds of storage, one of them away from the other two. Your PC is the "away" copy. It is not a perfect one - home disks fail, laptops get stolen - but it fails for completely different reasons than the hosting side does, and that is the whole point. For the wider strategy, [game server backup strategy](https://www.renode.space/blog/game-server-backup-strategy) goes through slots, frequency and what to lock. > [!WARNING] Deleting a server deletes its backups, locked ones included. If you are about to cancel or rebuild a server, download the backups first, not after. #### What RE:NODE already does, and what it leaves to you It helps to know which copies exist before adding another, so you know what the new one is for. - **Your backups.** Every plan has backup slots - two on most game plans, a range on app, web and database plans. You make them on demand or from a schedule, restore them with a button, download them, and lock the ones you want to keep. They live off the machine they protect. These are the ones this post pulls. - **Nightly system backups.** Every server is also backed up every night, whatever its plan's slot count, outside your quota. Those are ours: they do not show on your Backups tab and you cannot download them. If you need one restored, that goes through support. [Nightly backups outside your quota](https://www.renode.space/blog/nightly-backups-outside-your-quota) explains how they work. - **Platform backups.** Separately, the platform itself is backed up nightly to separate hardware, verified and pruned, and we pull copies off the node every day. None of those three is a copy you hold. The nightly system backup is a safety net we keep for incidents; it is not a substitute for your own, and it is not something you can reach at three in the morning when you need it. The copy on your PC is the one that depends on nobody but you. ```diagram title: Three copies, and the one you hold yourself live = Live server | files on the node panel = Panel backups | your slots, off the node pc = Your PC | pulled on a schedule usb = External disk | optional, offline live -> panel : schedule or button panel -> pc : download over HTTPS pc --> usb : weekly copy ``` #### What a backup archive contains Before automating anything, be clear about what you are pulling, because the most common surprise in a restore is something that was never in the archive. | Thing | In the backup archive? | How to keep a copy | |---|---|---| | Server files (world, configs, plugins) | Yes | Download the archive | | A database slot (MySQL) | No | Dump it separately | | Files listed in `.pteroignore` | No | Remove the line, or copy by SFTP | | Startup variables | No | Note them or screenshot the Startup tab | A server backup is a `.tar.gz` of the server's files. A database you created in the panel's Databases tab lives on a database server, not in the server's file system, so it is not in the archive. If your Minecraft plugins, your FiveM resources or your Discord bot keep data in that database, a file backup alone restores a server that cannot find its data. Dump the database on its own - [mysqldump backup and restore](https://www.renode.space/blog/mysqldump-backup-and-restore) has the commands - and have the dump land in the server's files before the backup runs, so it rides along in the archive. The other gap is `.pteroignore`. It is a file in the server's root that works like `.gitignore`: anything it lists is skipped when a backup is made. It is useful for leaving out logs and caches, and dangerous when someone added `world/` to it months ago to save space. Open it before you trust any archive. Startup variables - the version, the jar, the environment values on the Startup tab - are not files either. Write them down once. Rebuilding them from memory during an outage is slow. #### The manual way: download from the Backups tab If you only want a copy now and then, there is nothing to install. 1. Open the server in the panel and go to the Backups tab. 2. If the newest backup is old, press the button to create one and wait until it shows as finished. 3. Open the menu on that backup and choose Download. The browser fetches a `.tar.gz` through a short-lived signed link. 4. Move the file somewhere that is not your Downloads folder, and rename it with the date and server name. That is fine before a risky change or before cancelling. It is not a backup routine, because it depends on you remembering, and the backups you most need are the ones from the week you forgot. The rest of this post makes it automatic. The panel side of backups is also covered in the [backups guide](https://www.renode.space/guides#backups). #### Automating it with PowerShell and the client API RE:NODE's panel is built on Pterodactyl, and its client API is what the panel's own pages use to list and download backups. With a client API key you can make the same two calls from a script. We do not publish an API reference of our own, so treat what follows as the upstream Pterodactyl client API and test it against your own server before relying on it. You need three things: - **An API key.** Create one in the panel under your account's API credentials. It starts with `ptlc_`. You can restrict a key to particular addresses; if your home connection has a fixed IP, do that. If the IP changes, a restricted key will start failing, which is safer than an open one but worth knowing about. - **The server's short ID.** It is the eight-character part of the server's URL in the panel, for example `a1b2c3d4` in `/server/a1b2c3d4`. - **A folder with room.** Count the archive size times the number of copies you want to keep, plus a margin. Store the key as a user environment variable, not in the script, so the script can be shared or committed without leaking it: ```text setx RENODE_API_KEY "ptlc_your_key_here" ``` `setx` writes the variable for future sessions, so open a new PowerShell window afterwards. The scheduled task we create later runs as your user and sees it. Now the script. Save it as `C:\ServerBackups\pull.ps1`: pull.ps1: ```text $Panel = 'https://panel.renode.space' $Server = 'a1b2c3d4' $Dest = "C:\ServerBackups\$Server" $Keep = 14 $Key = $env:RENODE_API_KEY [Net.ServicePointManager]::SecurityProtocol = 'Tls12' $ProgressPreference = 'SilentlyContinue' $Headers = @{ Authorization = "Bearer $Key"; Accept = 'application/json' } $Base = "$Panel/api/client/servers/$Server/backups" New-Item -ItemType Directory -Force -Path $Dest | Out-Null $Log = Join-Path $Dest 'pull.log' $list = Invoke-RestMethod -Headers $Headers -Uri $Base foreach ($b in $list.data) { $a = $b.attributes if (-not $a.is_successful -or -not $a.completed_at) { continue } $stamp = ([datetime]$a.completed_at).ToString('yyyy-MM-dd_HHmm') $file = Join-Path $Dest ("$stamp-" + $a.uuid.Substring(0,8) + '.tar.gz') if (Test-Path $file) { continue } $link = Invoke-RestMethod -Headers $Headers -Uri "$Base/$($a.uuid)/download" Invoke-WebRequest -Uri $link.attributes.url -OutFile "$file.part" -UseBasicParsing tar -tzf "$file.part" > $null 2>&1 if ($LASTEXITCODE -ne 0) { Add-Content $Log "$(Get-Date -f s) BAD archive $stamp, kept as .part" continue } Move-Item "$file.part" $file Add-Content $Log "$(Get-Date -f s) pulled $stamp $($a.name)" } Get-ChildItem $Dest -Filter *.tar.gz | Sort-Object LastWriteTime -Descending | Select-Object -Skip $Keep | Remove-Item ``` It is written for Windows PowerShell 5.1, the version every Windows 10 and 11 machine already has, so there is nothing to install. The fence is marked as plain text only because of how the blog colours code; the file itself is an ordinary `.ps1`. ##### What each part does The first block is configuration. `$Keep` is how many archives to hold on the PC; fourteen with a daily panel backup is two weeks. The `SecurityProtocol` line forces TLS 1.2, which older 5.1 installs do not always pick by default. `$ProgressPreference` matters more than it looks: in Windows PowerShell 5.1, `Invoke-WebRequest` redraws a progress bar for every chunk, and on a multi-gigabyte archive that alone can make the download several times slower. The loop asks the panel for the server's backups and skips any that failed or are still running. Each finished backup gets a file name built from its completion time and the first eight characters of its UUID, so the names sort by date and never collide. If the file already exists, the script moves on - that is what makes it safe to run as often as you like. It only ever downloads what it does not have. For a new backup it asks for a download link, which comes back as a signed URL that expires shortly, and downloads to a `.part` file. Only after `tar -tzf` has read the whole archive without an error is it renamed to `.tar.gz`. That one step is the difference between a backup folder and a folder of files that look like backups. `tar` ships with Windows 10 and 11, so this also needs nothing extra. The last pipeline is retention: sort the archives newest first, skip the ones you want to keep, delete the rest. It only touches `.tar.gz` files in that server's folder, so a broken `.part` stays put for you to look at, and nothing else on your disk is in scope. ##### More than one server Make `$Server` a list and wrap the body in a second loop, or keep one copy of the script per server with its own folder. Separate folders are easier to reason about when you restore, and one server with a broken key does not stop the others. #### Scheduling the pull with Task Scheduler A script you have to remember to run is the manual way with extra steps. Windows Task Scheduler runs it for you. Open PowerShell as your normal user and register a task: Register the task (PowerShell): ```text $action = New-ScheduledTaskAction -Execute 'powershell.exe' ` -Argument '-NoProfile -ExecutionPolicy Bypass -File C:\ServerBackups\pull.ps1' $daily = New-ScheduledTaskTrigger -Daily -At 9am $logon = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME $opts = New-ScheduledTaskSettingsSet -StartWhenAvailable ` -ExecutionTimeLimit (New-TimeSpan -Hours 3) Register-ScheduledTask -TaskName 'Server backup pull' ` -Action $action -Trigger $daily,$logon -Settings $opts ``` Two triggers on purpose. A home PC is often off at whatever time you pick, so a daily trigger alone misses days. The logon trigger runs it whenever you sign in, and `-StartWhenAvailable` tells Windows to run a missed daily start as soon as the machine is back. Because the script only downloads what it lacks, running it twice in a morning costs one API call. `-ExecutionTimeLimit` stops a hung download from sitting there forever; three hours is generous for most archives. If you have servers measured in tens of gigabytes on a slow line, raise it. ##### Line it up with the panel's backup schedule The pull can only fetch what exists. On the panel side, open the server's Schedules tab and add a schedule with a backup task, using a cron expression for the time you want. If the panel backup runs at 05:00 and your PC pulls at 09:00 and at logon, every morning's copy reaches your disk the same day. [Cron expressions explained](https://www.renode.space/blog/cron-expressions-explained) covers the five fields if you have not written one before, and [scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having) suggests what else belongs on that tab. Mind the slot count. A game plan with two backup slots rotates: when both are full, a scheduled backup replaces the oldest unlocked one. That is fine here - your PC keeps the history the panel has no room for. It is also the best argument for the pull: two slots on the server, fourteen days on your disk. > [!TIP] Lock one known-good panel backup before a big change and leave it locked. Rotation then works around it, and your PC still collects the daily copies. #### Checking that the copies are any good A file with the right name and size is not yet a backup. "A backup nobody has restored is a hypothesis," and the same goes for a downloaded one. The script already lists every archive end to end, which catches truncated downloads and corrupt gzip streams. That is the first layer. The second layer is looking inside. Once a month, take the newest archive and list what is in it: ```text tar -tzf C:\ServerBackups\a1b2c3d4\2026-10-16_0500-3f9a1c2e.tar.gz | more ``` You are checking that the world folder, the config files and the plugin data are there and are not suspiciously small. If the world is missing, look at `.pteroignore` before you look anywhere else. The third layer is an actual restore, and it is the only one that proves anything. Unpack the archive into an empty folder and start the server from it - on your PC if the game runs there, or on a spare server. [Testing a restore before you need it](https://www.renode.space/blog/testing-a-restore-before-you-need-it) walks through doing this without touching production, and [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) covers the failure modes that only show up at this step. #### Keeping the local copy safe The copy on your PC is only "away" if it stays separate from the things that can hurt the server. - **Do not sync it straight back to the cloud.** A backup folder inside OneDrive or Dropbox is fine as a third copy, but sync clients mirror deletions. If ransomware or a bad script empties the folder, the empty folder syncs. Use version history, or keep the sync copy separate from the pull folder. - **Keep a weekly offline copy.** An external disk that you plug in, copy to and unplug is the one copy ransomware on your PC cannot reach. `robocopy C:\ServerBackups E:\ServerBackups /E` does it in one line. - **Protect the key.** The API key can do anything your account can do on the servers it can reach. Restrict it by address if you can, keep it in the environment variable rather than the script, and revoke it in the panel if the PC is lost. - **Mind the disk.** Game archives grow with the world. Look at the folder size after the first fortnight and adjust `$Keep` before the disk fills, rather than after. If you would rather the copy lived somewhere other than your PC, the same pattern works with object storage: [game server backups to S3](https://www.renode.space/blog/game-server-backups-to-s3) and [rclone with S3 storage](https://www.renode.space/blog/rclone-with-s3-storage) cover that route. #### Troubleshooting the pull The script writes one line per archive to `pull.log` in the server's backup folder, and Task Scheduler keeps the last run result for the task. Between them, most failures are easy to place. - **401 or 403 from the API.** The key is wrong, revoked, or restricted to an address you are not on. Check the key in a fresh window with `echo $env:RENODE_API_KEY`; if it is empty, `setx` ran but this session started before it. If you restricted the key by IP and your connection's address changed, add the new one. - **404 on the server.** The short ID is wrong, or the key belongs to an account that is not the owner or a subuser of that server. - **The task shows success but nothing downloads.** There may be nothing new. Check the Backups tab: if the last backup failed or is still running, the script skips it by design. - **Downloads are painfully slow.** Make sure the `$ProgressPreference` line is there. Without it, Windows PowerShell 5.1 spends much of its time drawing the progress bar. - **A `.part` file stays behind with a BAD line in the log.** The download was cut off or the archive is damaged. Delete the `.part` file; the next run fetches it again. If the same backup fails every time, make a fresh one in the panel and check whether that one passes. - **"Running scripts is disabled on this system".** That is the execution policy. The task passes `-ExecutionPolicy Bypass` for this one script; when running it by hand, use the same flag rather than loosening the policy for the whole machine. - **The task never runs when you are logged out.** Tasks registered this way run only while you are signed in, which is what lets them read your user environment variable. If you need it to run with nobody signed in, register it with a stored password and move the key into a file only that account can read. #### FAQ ##### Can I download the nightly backups RE:NODE makes? No. The nightly system backups are ours, kept for incidents, and they are hidden from the Backups tab. A restore from one goes through support. The backups you can download, and that this script pulls, are the ones in your own slots. ##### Is there an official RE:NODE backup app to install? No. We do run an internal program to pull copies off the node every day for the platform, but it is not a customer download. The script in this post does the same job for your own servers with tools already on Windows. ##### Does the downloaded archive include my database? No. A server backup archive is the server's files. A database slot is a separate thing and needs its own dump. Write the dump into the server's files before the backup runs and it will be inside the archive you pull. ##### How many copies should I keep on my PC? Enough to go back past the point where a problem was noticed. Griefing, a corrupt chunk or a bad plugin are often spotted days later, so a week is the minimum and two weeks is comfortable. Disk space is usually the only limit. ##### Will pulling backups slow down my server? No. The download reads an archive that already exists in backup storage; the game server is not involved. Making the backup in the first place takes some disk and CPU on the node, so schedule that for a quiet hour. ##### Can I use this on a Mac or Linux machine? The idea carries over directly - two API calls, a download, `tar -tzf`, a retention step - but the script is PowerShell and the scheduler is Windows. On Linux or macOS the equivalent is a short shell script with `curl` and a cron entry. Every RE:NODE plan has backup slots, on demand or on a schedule, downloadable and lockable, stored off the machine they protect. Pulling a copy to your own PC takes one script and one scheduled task. [See game server plans](https://www.renode.space/game-servers) --- ### Connect Claude to your game server or app with MCP Published 2026-10-16 by RE:NODE Team. https://www.renode.space/blog/connect-claude-to-your-game-server To connect Claude to a RE:NODE server, you add one URL - `https://panel.renode.space/api/client/mcp` - as a remote MCP server, then approve the connection once in your browser. In Claude Code that is a single `claude mcp add` command; in Claude.ai it is a custom connector with the same address. Nothing is installed on your machine or on the server. On the consent page you choose which servers the assistant may reach and at which level: **Files** (read and edit files, read the console) or **Manage** (the same, plus start, stop, restart and console commands). Databases, backups, schedules, users, startup settings and passwords stay out of reach whatever you pick. If you only want help with one server for one conversation, there is a shorter path: the **Connect AI** button above the console makes a share link you paste into the chat. Both routes are covered below, along with what the assistant actually sees, what is withheld, and what to do when the connection does not come up. None of this is specific to games - a Valheim server, a Discord bot and a Next.js app look the same to the assistant. #### What MCP is, in one paragraph The Model Context Protocol is the standard way for an AI assistant to call tools that live somewhere else. An MCP server publishes a list of tools with names and arguments - `read_file`, `tail_console`, `power` - and the assistant decides when to call them, reads the result and carries on. A remote MCP server is one reached over HTTPS rather than started as a local program. Ours speaks Streamable HTTP, which is what current Claude clients expect for a remote server, so there is no package to install, no Node.js or Python runtime on your machine, and nothing to keep updated. The practical difference from pasting logs into a chat is that the assistant stops guessing. Instead of you copying the last 40 lines of console output and describing your folder layout, it lists the directory itself, reads `server.properties` or `package.json`, tails the console and tells you what it found. With the Manage level it can then restart the server and watch it come back. #### Two ways in: the MCP endpoint or a share link There are two doors, and they suit different jobs. | Route | Best for | Lifetime | | --- | --- | --- | | MCP endpoint + OAuth | Ongoing work across your servers | Stays connected while used | | Share link (Connect AI) | One server, one conversation | 7 days idle (read), 24 hours idle (control) | The **MCP endpoint with OAuth** is the one to set up if you use Claude regularly. You connect once, choose your servers and a level, and the assistant keeps its own access alive: access tokens last an hour and are refreshed in the background, and the refresh token slides forward 30 days with every use. An assistant you open once a month never asks you to sign in again. It also gets the `list_servers` tool, so you can say "the Minecraft one" instead of pasting an ID. A **share link** is scoped to a single server and is something you hand over, not something you sign into. It works in any assistant that can open a URL - Claude, ChatGPT or anything else - because at its simplest it is a page of markdown describing the server. A link created for the **Manage this server** purpose can also act, and it has its own MCP address you can add to Claude as a connector. If you are unsure, start with OAuth in whichever Claude client you use most. Use share links for a quick one-off, or for an assistant that does not support remote MCP at all. #### Connect Claude Code Claude Code is the command-line agent, and it is the quickest to set up. From any terminal: ```bash $ claude mcp add --transport http renode https://panel.renode.space/api/client/mcp ``` `renode` is just the name the server will have inside Claude Code - call it what you like. The command registers the server; it does not sign you in yet. Start Claude Code and run `/mcp`. The `renode` entry will show that it needs authentication; pick it, and Claude Code opens your browser at the panel's consent page. 1. If you are not signed in to the panel, you are sent to log in first (with your two-factor code if you have one) and then straight back to the consent page. 2. Check the host the approval goes back to. For Claude Code this is a `localhost` address, and the page warns you about that - expected for a CLI, since the browser hands the code back to the program on your own machine. 3. Choose **All my servers** or pick specific ones. 4. Choose a level: **Files** or **Manage**. 5. Approve. The browser tab can be closed; Claude Code now has the tools. Back in Claude Code, ask something that forces a tool call: "List my RE:NODE servers and tell me which ones are running." If it answers with your actual server names, the connection works. A few Claude Code details worth knowing: - By default `claude mcp add` registers the server for the current project only. Add `--scope user` to make it available in every project on your machine, or `--scope project` to write it into a `.mcp.json` file in the repository so teammates get the same entry (each still signs in as themselves). - `claude mcp list` shows what is registered and whether each server connects. `claude mcp remove renode` removes the entry on your side. - Removing the entry does not revoke the grant on the panel. To end access properly, disconnect it from the panel as well - see the section on revoking below. ##### Using an API key instead If you already use a client API key for scripts, it still works and skips the browser: ```bash $ claude mcp add --transport http renode https://panel.renode.space/api/client/mcp \ --header "Authorization: Bearer ptlc_your_key_here" ``` This is the less tidy option. The key has the full reach of your account's client API, it never expires on its own, and it sits in plain text in Claude Code's config. Any allowed-IP list on the key and two-factor enforcement still apply, as they do to every client API call. Prefer OAuth unless you have a reason - for example a headless machine with no browser to approve from. #### Connect Claude.ai and Claude Desktop In Claude.ai the same endpoint is added as a custom connector. The exact menu wording moves around as Anthropic updates the app, but the path is Settings, then Connectors, then the option to add a custom connector. 1. Give it a name, such as `RE:NODE`. 2. Paste `https://panel.renode.space/api/client/mcp` as the URL. Leave any OAuth client ID and secret fields empty - the panel supports dynamic registration, so Claude registers itself. 3. Save, then press **Connect**. A browser window opens at the panel's consent page. 4. Choose your servers and a level, and approve. The consent page shows the name of the app asking for access and the host the approval returns to. For Claude.ai that should be an Anthropic address, not something you do not recognise. If the page says the client's name is "checked by nothing", that is accurate: anyone can register a client and call it anything, which is exactly why the page shows the return host as well. Read it before you approve. Once connected, enable the connector in a conversation (from the tools menu under the message box) and ask Claude to list your servers. Claude Desktop uses the connectors on your Claude account, so a connector added in Claude.ai should appear there too. Whether custom connectors are available to you at all depends on your Claude plan - Anthropic's help pages are the place to check that, not us. We have built and tested the endpoint against Claude Code and Claude.ai custom connectors. It follows the MCP specification, so other clients that support remote MCP with OAuth should work, but we have not tested ChatGPT or Cursor against it and make no promises there. #### The Connect AI bar on the console On every server's Console tab, above the terminal, there is a bar titled **Work on this server with AI**. It also appears on the Startup tab. It is visible to anyone who can read the server's startup settings, which covers the owner and most subusers. It has one dropdown, **What the assistant is for**, and one button, **Connect AI**. The purposes are: | Purpose | What you get | | --- | --- | | General | A read link to understand the server | | Set up a new project | A read link with setup instructions | | Fix my repository | A read link focused on the repo | | Server won't start | A prompt with the console tail, no link | | Connect a database | A read link with database steps | | Add a domain | A read link with domain steps | | Manage this server | A control link that can act | Press **Connect AI** and the panel makes a link of the form `https://panel.renode.space/ai/rnai_...` and copies it to your clipboard. It is shown only this once - the panel keeps a hash, not the link - so paste it somewhere before you close the dialog. Paste it into the chat with a sentence about what you want, and the assistant opens it and gets a markdown description of the server: runtime, start command, boot order, the server's address and port, pre-flight findings from the repository if one is linked, and the instructions for the purpose you chose. **Server won't start** is the exception. It copies a ready-to-paste prompt containing the latest console output instead of a link, because the useful thing in a crash is the last screen of log, and it should not wait for the assistant to fetch anything. Use it from the Console tab so the console lines are included. If the crash is a loop rather than a one-off, [our guide to crash loops](https://www.renode.space/blog/game-server-crash-loops-diagnosis) covers what the output usually means. A **Manage this server** link shows a second address, the MCP server URL, ending in `/mcp`. Paste that into Claude.ai as a custom connector, or add it in Claude Code: ```bash $ claude mcp add --transport http renode-link https://panel.renode.space/ai/rnai_xxx/mcp ``` No sign-in happens here - the link itself is the credential. That is the point of it, and also the reason it is built to die quickly. #### What the assistant can see and do Through the MCP endpoint the assistant has these tools. Which ones work depends on the level you approved and on your own permissions on that server, both checked on every call. | Tool | What it does | Level | | --- | --- | --- | | `list_servers` | Your servers covered by the grant | Files | | `get_server_context` | Runtime, startup, address, notes | Files | | `get_resources` | Live memory, CPU and disk use | Files | | `get_setup_prompt` | Task instructions for this server | Files | | `tail_console` | Recent console output | Files | | `list_files` | Directory listings | Files | | `read_file` | File contents, secrets redacted | Files | | `write_file` | Create or overwrite a text file | Files | | `set_env` | Set keys in a `.env` without reading it | Files | | `send_command` | Type a command into the console | Manage | | `power` | Start, stop, restart or kill | Manage | A few behaviours are worth knowing before you rely on them: - `tail_console` returns at most the last 100 lines, because that is what the server daemon keeps in its buffer. For an older error, have the assistant read the log file instead - `logs/latest.log` on Minecraft, for example. - `write_file` writes UTF-8 text up to 1 MB. It will not write anywhere under `.git/`, because `.git/hooks` is code that runs on the next fetch. - Tools are always listed, even ones your level does not allow. A refused call comes back as a readable error the assistant can understand, so a Files-level connection asked to restart will tell you it cannot rather than fail silently. - Power actions, console commands and file writes are recorded in the server's activity log under your account, marked as coming through OAuth with the client's name, or through a link. A restart made by the assistant counts as a deliberate restart, not a crash. On a share link the set is narrower. A read link gets the context, the task prompts, resource use, the console tail and directory listings - but no file contents, because a read link stays valid for a week of idleness and tends to be pasted into chat history, and a `.env` is where secrets live. A control link adds file reads and writes, console commands and power actions. `list_servers` is never available through a link: a link knows exactly one server. #### What stays out of reach Some things no level and no link can reach. Through the MCP endpoint, never: databases or their passwords, backups, schedules, subusers, startup command and variables, server settings. Through a link, never: deleting or renaming files, reinstalling, startup or variable changes, databases, backups, schedules, users, SFTP details or API keys. Secrets get separate treatment. Every byte that leaves through these tools - context, console, file contents - passes a redactor that works in three layers: 1. **By name.** Any variable called something like `TOKEN`, `PASSWORD`, `KEY`, `SECRET`, `AUTH` or `SALT` has its value withheld. 2. **By shape.** Strings that look like GitHub, Slack, OpenAI or AWS keys, JWTs, passwords inside URLs, or long random-looking strings are withheld whatever they are called. 3. **By value.** The server's actual secret values and its database passwords are collected and scrubbed from the finished output, which catches a password pasted into a variable named `NOTES`. > [!WARNING] Redaction is a safety net, not a guarantee. A secret in an unusual format in an unusual place can get through. Keep real credentials in `.env` files and variables with obvious names, and do not paste passwords into the chat yourself. That redaction is also why `set_env` exists. If the assistant read a `.env` file and wrote it back, every password would come back as a placeholder and your app would break. `set_env` instead replaces or appends the named keys on the panel side, keeps every other byte of the file, and returns only key names. You can tell Claude "set `DATABASE_URL` in `.env` to this value" and nothing in the response echoes it. It works only on files named `.env` or starting with `.env`. More on keeping secrets in the right place in [environment variables and secrets](https://www.renode.space/blog/environment-variables-and-secrets). #### Limits, expiry and revoking access OAuth connections and share links age differently. - **OAuth**: access tokens last 1 hour and are refreshed automatically. Refresh tokens last 30 days and slide forward with each refresh. If a spent token is ever presented again - a sign it was copied - the whole grant is revoked and you will need to approve again. - **Read links**: each use extends the link to 7 days idle, up to 90 days from creation. - **Control links**: each use extends the link to 24 hours idle, up to 30 days from creation. - A server has at most five active links, two of them control links. Making a new link for the same purpose replaces your previous one. - Each link allows 60 requests a minute, 20 actions a minute and 6 power actions a minute. - A link stops working the moment its creator loses access to the server. An expired, revoked or refused link answers with a plain 404, so it reveals nothing about whether it ever existed. To end access sooner, go to **Account, then Connected AI** in the panel. It lists every OAuth connection with **Disconnect** and every active share link you made, on any server, with **Revoke**. This is the place to clean up after a laptop goes missing or a teammate leaves - and teammates are better handled as subusers with narrow permissions anyway, as [subusers and least privilege](https://www.renode.space/blog/subusers-and-least-privilege) explains. Note that "All my servers" on the consent page means servers you own plus servers where you are a current subuser, and your subuser permissions cap what the assistant can do there. > [!TIP] Approve the Files level by default and connect a second time at Manage only when you want the assistant to restart things. Most diagnosis needs nothing beyond reading files and the console. #### A worked example: a server that stops on boot Here is what a typical session looks like with Claude Code connected at the Manage level, on a Node.js app that crashes after an update. The prompt: ```text My RE:NODE server "shop-api" stopped starting after this morning's deploy. Find out why, fix it, restart it and confirm it stays up. ``` The assistant calls `list_servers` to resolve "shop-api" to an ID, then `get_server_context` to learn the runtime, start command and port. It calls `tail_console` and sees the app binding port 3000 when the server's port is something else. It calls `read_file` on `package.json` and the entry file, finds the hard-coded port, and uses `write_file` to read `process.env.PORT` instead, binding `0.0.0.0` rather than `localhost`. It restarts with `power`, tails the console again, and reports what it changed. Every step is visible in the conversation, and every write and restart lands in the server's activity log. Read the diff before you accept it - the habits in [AI coding agents for server work](https://www.renode.space/blog/ai-coding-agents-for-server-work) apply here exactly as they do on any machine. The same flow works for a game: "the Valheim server shows in the list but nobody can join" leads the assistant through the console, the start parameters it can read, and the world files, though it cannot change the startup variables itself and will tell you which value to change on the Startup tab. #### Troubleshooting the connection **The browser never opens in Claude Code.** Run `/mcp`, select the server and choose to authenticate. On a remote machine with no browser, copy the URL Claude Code prints into a browser on your own computer; the redirect back to `localhost` will only complete on the machine running Claude Code, so for a headless box an API key is simpler. **The consent page shows an error instead of the approval form.** The panel shows errors on the page rather than redirecting until it has verified the client and its return address. Remove the connector and add it again so the client registers fresh. **Claude says the tools exist but every call fails.** Check the level. A Files grant refuses `power` and `send_command`. Then check your own permissions: on a server where you are a subuser without console access, the assistant has none either. **A share link returns 404.** It expired, was replaced by a newer link for the same purpose, was revoked, or you lost access to the server. Make a new one from the console bar. **The assistant sees a placeholder where it expected a value.** That is the redactor working. If it needs to change a secret, ask it to use `set_env`; if it needs the value, it does not. **Two-factor prompts during sign-in.** Expected. The consent page sits behind the same two-factor check as the rest of the panel - see [two-factor on your panel account](https://www.renode.space/blog/two-factor-on-your-panel-account). #### FAQ ##### Does RE:NODE run an AI model or see my conversations? No. We run no model. The MCP endpoint and share links are doors for your own assistant; Claude runs on Anthropic's side under your Claude account, and the panel only sees the tool calls it makes, which are logged against your servers. ##### Can Claude delete my world or my files? Not through these tools. There is no delete tool on the MCP endpoint, and links refuse delete and rename outright. It can overwrite a file with `write_file` at either level, so keep a recent backup before a session that edits configs. ##### Can I connect Claude to only one server? Yes. Pick that server on the consent page instead of All my servers, or use a share link from that server's Console tab, which can only ever reach the one server. ##### Does it work with ChatGPT or Cursor? A share link works in ChatGPT, since it is a URL. The MCP endpoint and OAuth are built and tested against Claude; other clients that support remote MCP should work, but we have not verified ChatGPT or Cursor against them. ##### What happens if I stop using it for a while? An OAuth connection survives up to 30 days without use; after that Claude asks you to approve again. A read link lapses after 7 idle days and a control link after 24 idle hours, with nothing for you to clean up. Every RE:NODE server - game, app, web or database - has the Work on this server with AI bar and works with the hosted MCP endpoint, with passwords and tokens withheld from what the assistant sees. [See app hosting plans](https://www.renode.space/app-hosting) --- ### Hosting bundles explained: app, database and cache together Published 2026-10-16 by RE:NODE Team. https://www.renode.space/blog/hosting-bundles-explained A bundle on RE:NODE is two or three ordinary plans - usually an app server, its database and sometimes a cache - bought in one checkout, held on one invoice and one renewal date, and cancelled together. A two-plan bundle costs 15% less than the same plans bought one by one; a three-plan bundle costs 20% less. Each server in it is a normal server with the same panel, console, files and backups as any other plan. The price of the discount is rigidity: the members renew together, cannot be upgraded on their own, and cancelling one cancels the lot. If your stack is settled and you expect to keep it for a while, a bundle is simply the cheaper way to buy it. If one piece is likely to outgrow the others soon, buy the plans separately. That is the whole idea. The rest of this post goes through every bundle we sell, what is inside each one, what the saving is in dollars, how to wire the pieces together once they exist, and the cases where we would tell you not to bother. #### What a bundle is, and what it is not A bundle is a billing arrangement, not a different kind of server. When you buy one, the panel creates each member server from the same code that builds a single plan, so a PostgreSQL server that arrives in a bundle is indistinguishable from one bought on its own. It has its own address and port, its own generated credentials, its own resource limits, its own backup slots and its own console. Nothing is shared between the members except the bill. What changes is how the set is held: - **One checkout.** Every server in the bundle is created after one payment. Like any other plan, they are built when payment clears, usually inside a minute. - **One invoice, one renewal date.** The bundle renews as a unit. The Finances page shows it as a bundle card with a single "Renew all" button, and each member says it is part of the bundle and points you there. - **Cancelled together.** Cancelling a bundle keeps every server in it running until the paid term ends, then stops them all. Cancelling a member cancels the whole bundle. - **No solo upgrades.** A member server cannot be renewed, upgraded or downgraded on its own. The panel refuses it. It is also worth being clear about what a bundle does not give you. It is not a private network between the members: the app reaches its database on the database plan's host and port, exactly as it would if you had bought them on separate days. It is not a managed service where we tune the database for your app. And it is not a different panel or a different support queue. If you already know how to run an app and a database side by side on separate plans, you already know how to run a bundle. #### Every bundle we sell, with the maths These are the twelve bundles in the catalogue as of this post. Prices are US dollars per month on a one-month term, and they do change, so treat the bundles page on the site and the panel shop's Bundles tab as the source of truth. | Bundle | What is inside | Bundle vs separately | |---|---|---| | Node.js + PostgreSQL | Node.js Standard, PostgreSQL Starter | $11.05 vs $13 | | Go + PostgreSQL | Go Standard, PostgreSQL Starter | $11.05 vs $13 | | .NET + SQL Server | C# / .NET Standard, SQL Server Express Starter | $11.05 vs $13 | | Python + PostgreSQL + Valkey | Python Standard, PostgreSQL Starter, Valkey 256 MB | $12 vs $15 | | Node.js + MongoDB + Valkey | Node.js Standard, MongoDB Starter, Valkey 256 MB | $12.80 vs $16 | | Java + PostgreSQL + Valkey | Java Advanced, PostgreSQL Starter, Valkey 512 MB | $16.80 vs $21 | | PHP stack: Web + MySQL + Valkey | HTML CSS JS PHP Standard, MySQL Starter, Valkey 256 MB | $8 vs $10 | | Laravel + MySQL + Valkey | Laravel / PHP Standard, MySQL Starter, Valkey 256 MB | $10.40 vs $13 | | WordPress + Valkey cache | WordPress Standard, Valkey 256 MB | $8.50 vs $10 | | Ghost + Mail Server | Ghost Standard, Mail Starter | $10.20 vs $12 | | Headless: Strapi + Node.js | Strapi Standard, Node.js Standard | $14.45 vs $17 | | Bot stack: Python + MongoDB | Python Starter, MongoDB Starter | $9.35 vs $11 | The pattern is regular. Every two-plan bundle is 15% off the sum of its list prices and every three-plan bundle is 20% off. The "separately" figure is not an inflated anchor; it is just the plans' own monthly prices added up. Node.js Standard is $7 and PostgreSQL Starter is $6, so $13, and 15% off that is $11.05. In absolute terms the savings are small - between $1.50 and $4.20 a month. Over a year that is $18 to $50, which is real money for a side project and rounding error for a business. We would rather say that plainly than dress it up: the discount is a reason to choose a bundle when it fits, not a reason to buy servers you do not need. ##### What each member gives you The resources are those of the plans named above. For the common pieces: | Plan | RAM / NVMe / vCPU | Notes | |---|---|---| | Node.js, Python, Go, .NET, Laravel Standard | 2 GB / 10 GB / 1 | App server with a proxy slot | | PostgreSQL Starter | 1 GB / 20 GB / 0.5 | Own credentials, host and port | | MongoDB Starter | 1 GB / 20 GB / 0.5 | Own credentials, host and port | | MySQL Starter | 1 GB / 10 GB / 1 | MySQL 8.4 LTS, root password generated | | Valkey 256 MB | 0.25 GB / 2 GB / 0.5 | Password-protected, saves to disk | | SQL Server Express Starter | 2 GB / 10 GB / 1 | Express edition, 10 GB per database | The Java bundle is the exception that is sized up on purpose: it uses Java Advanced, with 4 GB of RAM and 1.5 vCPU, because a Spring Boot or Quarkus service on 2 GB spends its life in garbage collection. It pairs that with the 512 MB Valkey plan. The bot stack goes the other way and uses the Starter Python plan (1 GB, 0.5 vCPU), which is plenty for a bot that mostly waits on a websocket. #### How the discount and payment work The bundle discount is applied to the monthly price, and the usual longer-term discount still applies on top. Buying a bundle for 3, 6 or 12 months gets the same term discount a single plan would, compounded with the bundle's own 15% or 20%. So the cheapest way to hold a stack you are confident about is a bundle on a 12-month term. There are a few payment limits that catch people: - **Reward credit cannot pay for a bundle.** Reward credit is tied to individual hosting lines and a bundle crosses several, so the checkout will not spend it. Your wallet balance and PayPal can. - **The crypto checkout does not take bundles yet.** "Pay with crypto" works for single plans; bundles and VDS orders are not on it. - **The site's order pop-up does not take bundles.** The button on the bundles page links straight to the panel shop, where bundles have their own tab. If something goes wrong during the build - say one member fails to create while the others succeed - the bundle is still recorded as paid, the missing server is flagged to our team, and the bundle card on your Finances page says which part is missing until it is set up. You do not need to buy it again. #### Which bundle fits which project The bundle names are fairly literal, but the fit is worth spelling out, because the wrong stack is not made right by being cheap. ##### Node.js + PostgreSQL, Go + PostgreSQL The default for a typical web API or full-stack app with relational data: users, orders, anything with foreign keys and transactions. Express, Fastify, NestJS and Next.js on the Node side; a `net/http` or Gin service on the Go side. PostgreSQL Starter's 1 GB is enough for a database in the low gigabytes with a sensible number of connections. If you are unsure whether you want Postgres at all, [Postgres or MongoDB](https://www.renode.space/blog/postgres-or-mongodb) is the longer argument. ##### Python + PostgreSQL + Valkey Django, Flask or FastAPI with a relational database and a cache. Valkey earns its place here as the Celery or RQ broker, the cache backend and the session store. If your app has no background jobs and no expensive pages, you may not need the Valkey at all, in which case read [when you actually need Redis](https://www.renode.space/blog/redis-when-you-need-it) before paying for one. ##### Node.js + MongoDB + Valkey For a document-shaped API: content with flexible fields, event logs, anything where the schema moves weekly. Valkey handles sessions, rate limits and queues such as BullMQ. This is the shape an Express or Nest API tends to grow into after the first few months. ##### Java + PostgreSQL + Valkey and .NET + SQL Server The JVM bundle is for Spring Boot, Quarkus, Micronaut or Ktor services, with the extra memory the JVM wants. The .NET bundle pairs an ASP.NET Core or Blazor app with SQL Server Express, which matters when the app was written against SQL Server and its T-SQL, and porting it to Postgres is a project in itself. Express caps each database at 10 GB, bundle or not; if you are anywhere near that, Express itself is the wrong edition. ##### PHP stack and Laravel stack The PHP stack uses the plain web hosting line (HTML, CSS, JS and PHP) with MySQL 8.4 and Valkey - right for a hand-written PHP site, an older framework app, or a CMS you install yourself. The Laravel stack runs Laravel or Symfony on FrankenPHP instead, with Composer installing on start, and suits a modern Laravel app that wants Valkey for cache, sessions and queues. ##### WordPress + Valkey cache One-click WordPress, which already comes with a MySQL database of its own, plus a Valkey server as a persistent object cache. This is the bundle with the most specific purpose: it helps a site with logged-in users, WooCommerce, or heavy plugins, where the same database queries run on every page. A brochure site behind full-page caching gains little from it. ##### Ghost + Mail Server A Ghost publication and a Stalwart mail server of your own, so the mail Ghost sends - member sign-in links, account emails - goes out from your domain. The uncomfortable part is covered further down: Ghost's bulk newsletter sending is built around Mailgun, so a mail server of your own covers transactional mail, not mass newsletters out of the box. ##### Strapi + Node.js, and the bot stack The headless bundle puts Strapi on one server for content and a Node.js server for the Next.js or Nuxt front end that reads Strapi's API. The bot stack is a Python process for a Discord or Telegram bot, a scraper or a worker, with MongoDB to keep what it collects. For the bot, [picking a plan for a Discord bot](https://www.renode.space/blog/picking-a-plan-for-a-discord-bot) covers whether Starter is enough. #### Wiring the pieces together Once the bundle is built you have two or three servers, each with an address and port shown in the panel and credentials generated for it. The app does not find its database by magic; you give it the connection details, normally as environment variables, and keep them out of the repository. [Environment variables and secrets](https://www.renode.space/blog/environment-variables-and-secrets) covers why. ```diagram title: One bundle, three servers, one bill users = Visitors | HTTPS via proxy slot app = App server | Node, Python, PHP... db = Database server | own host and port cache = Valkey server | own host and port users -> app : your domain app -> db : connection string app -> cache : password auth ``` A typical Node.js or Python app with PostgreSQL and Valkey wants something like this, with the real hosts, ports and passwords copied from each server's page: .env: ```env DATABASE_URL=postgres://app_user:GENERATED_PASSWORD@DB_HOST:DB_PORT/app_db REDIS_URL=redis://:VALKEY_PASSWORD@VALKEY_HOST:VALKEY_PORT/0 ``` Valkey speaks the Redis protocol, so every Redis client library - `ioredis`, `redis-py`, `phpredis`, Predis, Lettuce, StackExchange.Redis - connects to it with a `redis://` URL as if it were Redis. For Laravel the same values go into the framework's own keys: .env: ```env DB_CONNECTION=mysql DB_HOST=MYSQL_HOST DB_PORT=MYSQL_PORT DB_DATABASE=app DB_USERNAME=app DB_PASSWORD=GENERATED_PASSWORD REDIS_HOST=VALKEY_HOST REDIS_PORT=VALKEY_PORT REDIS_PASSWORD=VALKEY_PASSWORD CACHE_STORE=redis SESSION_DRIVER=redis QUEUE_CONNECTION=redis ``` `CACHE_STORE` is the Laravel 11 name; older versions call it `CACHE_DRIVER`. Queues on Valkey also need a worker process running `php artisan queue:work` or Horizon, which is a long-running process of its own - plan for where it runs before you switch `QUEUE_CONNECTION` over. [Deploying Laravel to production](https://www.renode.space/blog/deploy-laravel-to-production) goes through that. For the WordPress bundle, the usual route is the Redis Object Cache plugin with its constants in `wp-config.php`, added above the line that says to stop editing: wp-config.php: ```php define( 'WP_REDIS_HOST', 'VALKEY_HOST' ); define( 'WP_REDIS_PORT', VALKEY_PORT ); define( 'WP_REDIS_PASSWORD', 'VALKEY_PASSWORD' ); ``` Then enable the object cache from the plugin's settings page and check that it reports as connected. [Valkey as a WordPress object cache](https://www.renode.space/blog/valkey-object-cache-for-wordpress) covers the details and the eviction settings that stop a full cache turning into errors. On the plain PHP web line, check `phpinfo()` for the `redis` extension before writing code against it. If it is not there, Predis is a pure-PHP client installed with Composer and needs no extension. ##### Ghost and its mail server Ghost reads its mail settings from the `mail` block of its configuration (`config.production.json` in a standard install, or the equivalent `mail__options__host` style environment variables): config.production.json: ```json { "mail": { "from": "'Your Site' ", "transport": "SMTP", "options": { "host": "mail.example.com", "port": 465, "secure": true, "auth": { "user": "noreply@example.com", "pass": "MAILBOX_PASSWORD" } } } } ``` Before any of it lands in an inbox, the mail server needs its DNS done properly: MX, SPF, DKIM and DMARC records you add at your DNS provider, which [SPF, DKIM and DMARC explained](https://www.renode.space/blog/email-spf-dkim-dmarc-explained) walks through. Sending works from the start; receiving mail from the internet needs port 25 forwarded, which support does on request, one mail server per address. And as above: Ghost sends bulk newsletters through Mailgun, so this setup is for sign-in links and account mail unless you change how Ghost sends newsletters. #### Renewal, cancellation and changing your mind This is the part to read before buying, because it is where a bundle behaves differently from separate plans. The renewal invoice for a bundle is raised once for the whole set, and the usual reminders apply: an invoice emailed 7 days before expiry and again on the day. "Renew all" renews every member to the same date. You cannot renew the database for a year and the app for a month; the term is the bundle's. Cancelling is all or nothing. Cancel the bundle, or any member of it, and every server in it keeps running to the end of the paid term and then stops. If you want to keep the database and drop the cache, a bundle has no switch for that. Take a backup of anything you want to keep before the term ends, and download it, because deleting a server deletes its backups - locked ones included. Upgrading one member is refused. If your PostgreSQL Starter fills up but the app is fine, there is no button to move just the database to the next tier. That is the biggest practical difference from separate plans, where [upgrading a plan](https://www.renode.space/blog/when-to-upgrade-your-plan) is a change of limits that does not rebuild the server. If you hit this, open a ticket and ask what can be done rather than cancelling in a hurry. #### When to buy the plans separately A bundle is the right call when the stack is fixed and the sizes match. It is the wrong call in several common cases: - **One piece will grow faster than the rest.** A database that will pass 20 GB in a few months, or an app that will need 4 GB once traffic arrives. Separate plans can be upgraded one at a time. - **You need a different size than the bundle uses.** The bundles use set tiers. If you need PostgreSQL Standard with a Node.js Starter, there is no bundle for that, and two separate plans at the right size beat a bundle at the wrong one. - **You do not need the third piece.** A three-plan bundle at 20% off is not cheaper than a two-plan purchase at list price if you never use the Valkey. The PHP stack at $8 still costs more than the $4 web plan alone. - **The app plan's own database slots are enough.** Every app and web plan includes two database slots, created in the panel with a generated host, user and password. A small site or a bot with a modest table may be fine with that, and needs no separate database server at all. A database server of your own buys its own RAM, CPU, disk, root access and backup slots - worth it once the database matters, not before. - **The pieces belong to different projects or people.** If the app is yours and the database is shared with another project, tying their renewal together creates a dependency you did not mean to have. - **You want to pay with reward credit or crypto.** Neither works for bundles. - **You are still deciding on the stack.** Running a test copy for a month before committing is cheaper than cancelling a bundle you got wrong. [Staging and production on one account](https://www.renode.space/blog/staging-and-production-on-one-account) has more on running two copies side by side. The way to compare is simple: price the separate plans at the sizes you actually need, then see whether a bundle matches them. If it does, take the bundle. If it is close but not quite, the separate plans win, because the cost of the wrong size is paid every day and the discount is a few dollars a month. #### Backups and day-two operations Each member server has its own backup slots, set by its plan. The app lines and PostgreSQL and MongoDB carry 2 to 6 slots depending on tier, MySQL, SQL Server and Mail carry 1 to 4, and the small Valkey plans 0 or 1. That last one matters less than it sounds: Valkey in a bundle is a cache, sessions store or queue, and if you are treating it as a primary database you are holding it wrong. It does save to disk with AOF and snapshots, so a restart does not empty it, but the data you cannot recreate belongs in PostgreSQL, MySQL or MongoDB. Schedule backups for the database server on its own Schedules tab, and test a restore before you need one. For a database, a dump is usually more useful than a file archive of the data directory; [database backups and restores](https://www.renode.space/blog/database-backups-and-restores) covers both and when each is safe. Beyond the backups you can see, every server is also copied by a nightly system backup outside your plan's slots; those are not on your Backups tab, and a restore from one goes through support. Monitoring is per server. Each member has its own console and its own graphs for memory, CPU and disk against its limits, so when the app slows down, look at the database's graph too. A PostgreSQL Starter pegged at its 0.5 vCPU looks, from the app, exactly like a slow app. #### FAQ ##### Is a bundle server weaker than the same plan bought on its own? No. The panel builds bundle members with the same code as single purchases, so a PostgreSQL Starter in a bundle has the same 1 GB of RAM, 20 GB of NVMe and 0.5 vCPU, and the same panel features, as one bought separately. The only differences are in billing: shared renewal date, shared cancellation, no solo upgrade. ##### Can I add a bundle discount to servers I already have? No. The shop sells a bundle as a new set of servers, built from one checkout. If you already run the app and want a cache, buying a single Valkey plan is the straightforward route, and you can move data onto bundle servers later if the saving is worth the migration. ##### Do the bundle servers talk to each other over a private network? No. The app connects to its database and cache on the address and port shown for each server, with the generated credentials, exactly as it would to separate plans. Keep the passwords out of your repository and use the password the panel generated rather than turning authentication off. ##### What happens to my data if I cancel? The servers keep running until the end of the term you paid for, then stop. Download a backup or a database dump of anything you want before then. Once a server is deleted, its backups go with it, including any you locked against rotation. ##### Can I pay for a bundle for a year at a time? Yes. Bundles take the same 3, 6 and 12-month terms as single plans, and the term discount is applied on top of the bundle's own 15% or 20%. That makes a year-long bundle the lowest monthly price for a stack you are confident in. Every bundle member is a full RE:NODE server: built when payment clears, with its own console, files, SFTP and backup slots, generated credentials, and the app servers' proxy slot with automatic certificates. Bundles are on the bundles page and the panel shop's Bundles tab. [See app hosting plans](https://www.renode.space/app-hosting) --- ### Loyalty pricing: how hosting renewals get cheaper over time Published 2026-10-16 by RE:NODE Team. https://www.renode.space/blog/loyalty-pricing-how-renewals-get-cheaper On RE:NODE, loyalty pricing is a per-service discount ladder. Every month a service is renewed without a gap takes another 2% off the next renewal, until the discount reaches 20% at month 11 and stays there for as long as you keep paying. The first month is always full price. It stacks with the cheaper per-month price of a 3, 6 or 12-month term, but the two together never take more than 35% off. Paying up to 7 days late costs nothing; past that, a once-a-year freeze holds your place for a month, and only after that does the service step back - 3 months, not to zero. Cancelling ends the streak. Changing plan does not. There is one condition that matters more than any of the numbers: loyalty pricing is not a box you tick at checkout. We switch it on per service. If a service of yours is enrolled, the Loyalty page under your account shows it; if it is not, you will see nothing about loyalty anywhere in the panel. The rest of this post explains the ladder in detail, the maths of stacking it with a term discount, what happens when a payment is late, and how renewal quotes show you the real figure before you pay. #### How the ladder works The rule fits in one line: month k of an unbroken run is priced at `2% × (k - 1)` off, capped at 20%. Month 1 is full price, month 2 is 2% off, month 3 is 4% off, and so on up to month 11, where the discount reaches 20% and stops growing. Month 12, month 24 and month 60 are all 20% off. A renewal buys the month after the one you are in, so it is priced at the next stage. If your service has been paid for 4 months in a row, your next renewal pays for month 5 and is priced at month 5's rate, 8% off. That is why the Loyalty page talks about "the next renewal" rather than "your current discount": what you are paying for is always one step ahead of where you are. Here is the full ladder on a plan that costs $10 a month at list price, renewed one month at a time: | Month | Discount | Price | |---|---|---| | 1 | 0% | $10.00 | | 2 | 2% | $9.80 | | 3 | 4% | $9.60 | | 4 | 6% | $9.40 | | 5 | 8% | $9.20 | | 6 | 10% | $9.00 | | 7 | 12% | $8.80 | | 8 | 14% | $8.60 | | 9 | 16% | $8.40 | | 10 | 18% | $8.20 | | 11 and after | 20% | $8.00 | Over the first year the service costs $102.40 rather than $120, and from then on it costs $96 a year instead of $120. The saving is real but it is back-loaded: in the first few months it is pocket change, and the point of the scheme is to reward the services that stay. That is the honest way to think about it. If you are running a server for a summer event and turning it off in September, loyalty pricing will barely touch your bill. If you are running a community server, a bot or a small production app that you expect to keep for years, it adds up. > [!NOTE] The plan's list price never changes because of loyalty. The discount is worked out at the moment a renewal is priced and written onto that invoice; the plan itself stays at its normal price. #### Enrolment: why you might not see it Loyalty pricing exists in the panel but it is not a public, automatic offer. In the mode we run it in, staff enrol services one by one. A few consequences follow from that, and they are worth knowing before you go looking for a discount that is not there. - **It is per service, not per account.** Your game server can be enrolled while your database server is not. Each one has its own streak, its own stage and its own next price. - **The streak starts at zero on enrolment.** If you have been paying for a server for two years and it is enrolled today, it starts at the bottom of the ladder like a new one. There is no backfill of the months before. - **Not enrolled means invisible.** A service that is not enrolled shows no loyalty fields on its card, no loyalty line in its renewal quote and no loyalty line on its invoices. If none of your services are enrolled, the Loyalty page does not appear at all. - **Un-enrolling is forward only.** If a service is taken off loyalty, the change applies from the next quote. An invoice that has already been raised keeps the amount it was raised for, and the streak is kept as history. The reason for doing it this way is simple: a discount that is guaranteed to everyone the moment they sign up is a price, not a reward, and we would rather keep list prices honest and switch the ladder on where it makes sense. If you have a long-running service and want to ask about it, a ticket from the panel is the right place. Our general billing guide covers it briefly under [loyalty pricing](https://www.renode.space/guides#loyalty). ##### What the Loyalty page shows For an enrolled service, the Loyalty page under your account has a card per service. It shows the stage the service is at ("Stage 5 of 11"), the discount the next renewal will take, the price at the floor and how many months away the floor is, and a line such as "Renew by" a date "to move up a stage". A summary at the top gives your best discount right now and your furthest stage. Underneath sits the ladder itself and a plain-language version of the rules on late payment. There is no badge, no tier name and no level title. Stages are numbered months. We think that is the right call: a name like "Gold" tells you nothing that "20% off from month 11" does not tell you better. #### Stacking with 3, 6 and 12-month terms Terms of 3, 6 and 12 months are already cheaper per month than paying monthly. Loyalty does not replace that discount, it compounds with it: ```text price = list price × (1 - term discount) × (1 - loyalty discount) ``` The two are multiplied, not added. A 10% term discount and a 10% loyalty discount give 19% off, not 20%, because the loyalty discount applies to the already-reduced price. On top of that there is a ceiling: term and loyalty together never take more than 35% off. When the two would pass it, loyalty is the part that gives way. To see how that plays out, take an illustrative term discount of 20% (an example figure for the arithmetic, not a quote of any plan - check the order dialog for the real one) on a service already at the 20% loyalty floor: | Step | Multiplier | Off list | |---|---|---| | Term discount alone | 0.80 | 20% | | Plus full 20% loyalty | 0.64 | 36% | | After the 35% cap | 0.65 | 35% | Uncapped, the two would give 36% off. The cap holds it at 35%, which means loyalty is trimmed from 20% to about 18.75% on that renewal. With a smaller term discount the cap may never bite at all. The renewal quote, covered below, shows exactly what each part contributes, so you never need to do this by hand - but it is useful to know why the loyalty line on a long term can be a little lower than the number on the ladder. The cap exists so that the two discounts compounding cannot take a plan below what it costs us to run. That is not a marketing line; it is the reason the rule is written the way it is. #### Buying several months at once This is the part of the scheme that rewards a little thought. When you renew for N months at once, all N months are priced at the rate of the next stage, and the streak moves up by N. Consider a service that has just finished its first month. Its next renewal is month 2, priced at 2% off. - **Renew monthly** and each renewal climbs one step: 2%, 4%, 6% and so on, reaching 20% at month 11. - **Renew for 12 months** now and all 12 months are priced at month 2's rate, 2% off, plus the term discount. The streak jumps to 13, so the renewal after that is priced at the 20% floor straight away. Neither is wrong. A long term at a low loyalty stage gets you the term discount immediately and puts you at the floor for the next renewal. Monthly renewals get the loyalty ladder month by month but miss the term discount. If you are early on the ladder, the term discount is usually the bigger number; once you are at the floor, a long term at the floor rate - subject to the 35% cap - is the cheapest way to pay. The renewal dialog quotes each option before you commit, so compare 1, 3, 6 and 12 months there rather than guessing. The general advice for any host applies here too: do not buy a 12-month term for something you are not sure you will keep. A discount on a service you abandon in month three is not a saving. Our piece on [what a game server really costs](https://www.renode.space/blog/how-much-does-a-game-server-cost) goes into sizing and term choice in more detail. #### Late payments, grace and the freeze A loyalty scheme that throws away a year of streak because a card expired on a Sunday would be a trap, not a reward. The rules for late payment are designed around that. 1. **The paid period ends.** A renewal invoice is emailed 7 days before expiry and again on the day. Renew before the expiry date and the next stage applies automatically. 2. **Grace: 7 days.** Paying within 7 days of the expiry date counts as on time. Nothing is lost - the renewal is priced at the next stage as if you had paid early. 3. **Freeze: once every 12 months.** The first miss past grace in a rolling 12-month window does not drop your stage. It is held for one month instead. Pay within that month and you keep climbing as if nothing had happened. The freeze is used automatically - you do not have to ask for it - and the reminder mails say when one will be used. 4. **Step back 3 months.** If the service is still unpaid a month past the frozen expiry plus grace, or if the freeze has already been used in the last 12 months, the service steps back 3 months from the stage it was on. Not to zero. The step-back is easiest to see with numbers. A service on a $30 plan at month 11 (20% off) misses its renewal and has no freeze left. It steps back 3 months, so its next renewal is priced as month 8: 14% off, $25.80. After that it climbs again normally - month 9, then 10, then back to the floor at 11. Missing once costs you three months of climb, not the whole run. The Loyalty page shows the freeze state for each service: available, in use (with the date it started and when the next one becomes available), or used on a given date with the next available date. > [!WARNING] The loyalty grace period is about pricing, not about your server. What happens to an expired service itself - suspension, and later deletion - follows the normal billing rules. Renew on time, or at least inside the 7 days, and both questions go away. ##### What resets the streak, and what does not | Event | Effect on the streak | |---|---| | Changing plan | Kept - the discount applies to the new plan's price | | Paying within 7 days of expiry | Kept, as if on time | | First miss past grace in 12 months | Held for one month (freeze) | | Still unpaid after that | Steps back 3 months | | Cancelling the service | Ends; a new service starts from month 1 | The plan-change rule is worth underlining. If your Minecraft server outgrows its plan and you move up a tier, the streak lives on the subscription, not on the plan, so you keep your stage and the discount applies to the larger plan's price. Changing plan does not rebuild the server either, so there is nothing to lose by upgrading when you need to. #### Renewal quotes: the price before you pay Renewals paid from your wallet balance or through PayPal, and the figure the renew dialog shows, all come from the same calculation. The renew dialog does not work out a figure in your browser. It asks the panel for a quote for the term you picked, and shows you: - the base price for that term, - the term discount, - the loyalty percentage, the amount it takes off and which month it is priced as, - the total, - the stage the service will reach after this renewal, - and how the total splits between reward credit and cash, if you have reward credit. If the quote cannot be fetched, the dialog shows an error rather than a number of its own. That matters more than it sounds: a dialog that guesses a price and a payment that charges a different one is the kind of mismatch that erodes trust in a bill, and we would rather show nothing than show the wrong figure. ##### Invoices never change after they are raised An invoice is fixed at the moment it is created. The loyalty percentage, the amount and the stage are written onto it then, and the invoice prints a "Loyalty discount" line under the subtotal with the number of months it was earned over. The consequence is that a renewal invoice already raised for a term is the price of that renewal, even if your stage changes before you pay it. The service card says so directly - "Already invoiced at" a given amount, with loyalty applying from the next invoice. If you were enrolled after the renewal invoice was emailed, the discount starts on the one after. That is deliberate: an invoice you might forward to an accountant should not quietly change its total. #### VDS orders and bundles Loyalty is not limited to ordinary panel subscriptions. Anything that renews as one bill can carry a streak. - **VDS orders.** A VDS renews at its plan price times the number of months, less the loyalty discount, through its own renewal quote. The first term counts towards the streak when the order is accepted, so an enrolled VDS starts climbing from its first paid period. VDS is prepared by hand, within 24 hours, but that has no effect on the ladder. - **Bundles.** A bundle - two or three plans, such as an app server with its database and cache, bought and renewed together - carries one streak for the whole set. The loyalty discount is worked out on the bundle's total, and the 35% cap is measured against the bundle's own discount compounded with the term's. Individual members of a bundle never carry a streak of their own, which fits the general bundle rule: one invoice, one renewal date, and a member cannot be renewed on its own. Because a bundle already has a discount built in, the cap is more likely to come into play there than on a single plan. Again, the bundle's renewal quote shows the real split. Bundles are paid by card, PayPal or wallet balance; reward credit and crypto do not pay for them. #### Judging any host's loyalty discount Plenty of hosts advertise renewal or loyalty discounts, and some of them are worth less than they look. Whatever host you are on, these are the questions that tell you whether a scheme is a reward or a hook. - **Is the renewal price higher than the first price?** The most common pattern in hosting is a cheap first term and a much higher renewal. A "loyalty discount" off an inflated renewal price can still leave you paying more than a new customer. Compare the renewal figure with today's price for a new order, not with the advertised discount. - **What does one late payment cost?** If a single missed day resets everything, the scheme is fragile. Look for a grace period and for what happens after it. - **Does it survive an upgrade?** A scheme that resets when you change plan punishes you for growing. - **Does it stack, and is there a cap?** Stacking rules decide whether a long term is worth it. A cap is normal; an undisclosed cap is not. - **Is the price quoted before you pay?** You should be able to see the exact renewal figure, with each discount broken out, before any money moves. Our answers to those, for the record: renewals are priced at list price less the discounts above, a late payment gets 7 days' grace and then a freeze, an upgrade keeps the streak, the stacking cap is 35% and stated, and every renewal is quoted before you pay. The longer piece on [choosing a hosting provider from the inside](https://www.renode.space/blog/choosing-a-hosting-provider-from-the-inside) covers the other billing questions worth asking, and [paying for hosting with crypto](https://www.renode.space/blog/pay-for-hosting-with-crypto) covers that payment route on its own. #### FAQ ##### Do I need to do anything to start earning loyalty discounts? No action on your side starts it. Loyalty is switched on per service by us, and the streak begins at zero from the moment a service is enrolled. If one of your services is enrolled, a Loyalty page appears under your account; if you see no such page, none of your services are enrolled. ##### Does the discount reset if I upgrade my plan? No. The streak belongs to the subscription, not to the plan, so moving to a bigger or smaller plan keeps your stage. The loyalty percentage is then applied to the new plan's price from the next renewal. ##### I paid three days after my server expired. Did I lose my discount? No. Anything paid within 7 days of the expiry date counts as on time for loyalty purposes, and the renewal is priced at the next stage as normal. The freeze and the 3-month step-back only come into play after those 7 days have passed. ##### Why is my loyalty discount lower on a 12-month renewal than on a monthly one? Because of the 35% cap. On a long term the term discount is larger, and when term and loyalty together would pass 35%, loyalty is reduced to fit. The quote in the renew dialog shows both parts separately so you can see where the difference comes from. ##### Is there a loyalty badge or a named tier I can show off? No. Loyalty is a numbered ladder per service - month 1 to month 11 and the floor after that - and the panel shows the stage, the discount and the next price, nothing more decorative than that. ##### What happens to my streak if I cancel and buy the same plan again? It starts again. Cancelling a service ends its streak, and a new service begins at month 1 at full price. If you only need to pause spending for a while, downgrading to a smaller plan keeps the streak, where cancelling and re-ordering does not. Every renewal on RE:NODE is quoted before you pay, with the term discount and any loyalty discount broken out, and terms of 3, 6 and 12 months already cost less per month. [See game server plans](https://www.renode.space/game-servers) --- ### Nightly server backups outside your quota: what they cover Published 2026-10-16 by RE:NODE Team. https://www.renode.space/blog/nightly-backups-outside-your-quota Every server on RE:NODE is backed up every night, whatever its plan, and those backups do not use any of your backup slots. Plans with no backup slots at all get them too. The databases a game server keeps in the panel are dumped separately each night, because a server archive holds files only. These nightly copies are system backups: you do not see them on the Backups tab and you cannot restore them yourself - you ask support, and we restore from them. They are a safety net under everything else, and a short-lived one. Your own backups, made in your own slots on your own schedule, are still the ones you control, and a copy that lives off our platform entirely is still the one that survives the things a host cannot protect you from. This post covers all three layers: what the nightly run does, how each kind of restore works, and how to keep an off-site copy without much effort. The short version, if you only read one paragraph: the nightly backup is there for the day something goes wrong that you did not see coming. It is not a history, it is not a versioning system, and it is not a reason to stop taking your own backups before an update or a wipe. #### What the nightly backup covers The nightly run walks through every server on a node once a day and makes a full archive of each one. "Every server" means what it says: game servers, app servers, web servers, database servers. It does not matter what the plan's backup limit is - a plan that allows zero backups still gets one each night, and a plan with six slots full of your own backups still gets one each night, because the system backup is counted outside the limit. | Kind of copy | Who makes it | Uses your slots | |---|---|---| | Nightly system backup | We do, every night | No | | Nightly database dump | We do, every night | No | | Your own backup | You, on demand or scheduled | Yes | A few things are true of the system backups that are worth knowing before you need one: - **They are hidden.** They do not appear on your Backups tab, and the panel will not let a customer list, download, delete or restore them. That is deliberate: it means nobody with access to your account, including a subuser who should not have that power, can remove the safety net. - **They hold files.** An archive is a copy of the server's file system - worlds, configs, plugins, uploads, code. It does not include databases you created in the panel's Databases tab; those live in a separate database service and are dumped on their own. - **They are recent, not historical.** We keep a short rolling window of the latest nights, not weeks of history. If a problem started a fortnight ago and you only noticed today, the nightly backups will not reach back far enough. Your own backups, locked against rotation, are how you keep an older known-good point. - **They pause rather than fill a disk.** If a node is running short of free space, the nightly run waits instead of starting new archives, because a full disk would take every server on that node down with it. Backups resume once space is back. The "outside your quota" part is the main practical difference from most panels. On a stock Pterodactyl setup a backup is a backup: if the host makes one for you, it sits in the same list and counts against the same limit. Here your slots are yours. You can fill them with your own copies before an update, lock the ones that matter, and the nightly safety net carries on underneath without competing for space. #### The database dumps A game server that uses a database - a Minecraft server with LuckPerms or an economy plugin on MySQL, a FiveM server on oxmysql, a Garry's Mod DarkRP server storing player data - keeps that database outside its own file system. On RE:NODE game plans come with one database slot, created in the panel with a generated host, user and password. The data in it is not inside the server's archive, so restoring a file backup alone gives you the world and the configs as they were, with the database as it is now. That is why the databases are dumped separately every night. A dump is a SQL file: the `CREATE TABLE` statements and the rows, written out in a form that can be replayed into an empty database. Unlike a copy of the database's own data files, a dump taken by the database server itself is consistent - it does not catch a table halfway through a write. The consequence for restores is simple and easy to forget: if you roll a server back, roll its database back to the same night, or you get a world from Tuesday with a player inventory from Friday. With plugins that store ranks, balances or claims in MySQL, a mismatch like that is usually worse than either version on its own. When you ask us to restore from a nightly backup, say whether you want the database restored to the same night. The same reasoning applies to your own backups, which hold files only. If you take a backup before a big plugin update, take a database export at the same moment - phpMyAdmin's export or a `mysqldump` from your own machine - and keep the two together. The [mysqldump guide](https://www.renode.space/blog/mysqldump-backup-and-restore) has the flags that matter. ```bash $ mysqldump --single-transaction --routines --triggers \ -h HOST -P PORT -u USER -p DATABASE | gzip > db-$(date +%F).sql.gz ``` Use the host, port, user and database name shown on the server's Databases tab. `--single-transaction` gives a consistent snapshot of InnoDB tables without locking them, which is what you want on a live game server. #### How the layers fit together There are three places a copy of your server can be: on our side as a system backup, on our side as a backup you made, and somewhere that is not us at all. They protect against different things. ```diagram title: Three copies, three different failures they cover server = Your server | files and database nightly = Nightly system backup | ours, hidden yours = Your backups | your slots, lockable offsite = Your off-site copy | your storage server -> nightly : every night server -> yours : on demand or scheduled yours -> offsite : download or sync ``` | Failure | What gets you back | |---|---| | Bad update, broken config | Any of the three | | Griefing found a week later | A locked backup or off-site copy | | Server deleted | Only the off-site copy | | Account lost or closed | Only the off-site copy | The last two rows are the uncomfortable ones. Deleting a server deletes its backups, including the ones you locked. If you cancel a server or lose access to your account, everything stored on our side goes with it. A copy you hold yourself does not. #### Restoring from a nightly backup Because system backups are hidden from the panel, a restore from one goes through support. You can reach us with a ticket from the panel or through the Chat button in the server header, which opens a conversation with staff beside the console and still works when a server is suspended or an install has failed. Discord and email work as well. To get the restore done quickly and correctly, say: 1. **Which server.** The server name, or better, its identifier from the address bar. 2. **Which night.** "The backup from before Thursday's update" is more useful than "the latest one", because the latest one may already contain the problem. 3. **What to restore.** The whole server, or particular folders - only the world, only the plugin configs. 4. **The database too or not.** Usually yes, to the same night, for the reasons above. 5. **Whether to keep the current state.** If you might want something from the broken version, take a backup of it in your own slot first, or download the files you care about. A full restore replaces what is there. Stop the server before the restore if you can. A running game server can write its world back to disk on shutdown, overwriting a restored save with the state it had in memory. For most games that is the difference between a restore that worked and one that silently did not. > [!WARNING] A full restore replaces the server's current files. Before asking for one, take your own backup of the current state, even if it is broken - it is the only copy of anything you made since the night you are going back to. #### Restoring from your own backups For the backups in your own slots there is no one to ask. The Backups tab lists them; each can be restored with a button, downloaded as an archive, or locked so that rotation does not remove it. The [panel guide](https://www.renode.space/guides#backups) walks through the screens. The difference between a full restore and a partial one matters here, because most real problems do not need the whole server put back. - **Full restore.** Stop the server, restore from the Backups tab, start it. Use this after a broken update or a mod that corrupted things you cannot list. - **One world or one folder.** Download the backup, unpack it on your own machine, and upload only the folder you need through the file manager or SFTP. The rest of the server stays as it is. - **One file.** The same, for a single config. This is the usual fix for "someone edited `server.properties` and now nothing works". ```bash $ mkdir restore && tar -xzf backup.tar.gz -C restore $ ls restore ``` Then upload the folder you want with any SFTP client, using the credentials on the server's SFTP details. The [SFTP and file manager guide](https://www.renode.space/blog/sftp-and-the-file-manager) covers clients and the usual permission errors. Lock at least one backup you know is good. Rotation is helpful right up to the moment it removes the last copy from before a problem you had not spotted yet. A locked backup taken after a clean start, before each big change, costs one slot and saves the argument about whether the rollback point still exists. #### Scheduling your own backups The nightly system backup runs whether you do anything or not. Your own backups run when you tell them to, and the Schedules tab is how you make that automatic. A schedule takes a cron expression and an ordered list of tasks with delays between them: console commands, a backup, a power action. A sensible pattern for a game server is to warn players, save the world from the console, back up, and only then restart if you restart at all: | Step | Task | Delay | |---|---|---| | 1 | Command: warning message | 0 s | | 2 | Command: save the world | 60 s | | 3 | Backup | 30 s | The save command depends on the game - `save-all` on Minecraft, `save` on many others; check your game's console reference. The point of saving first is that the backup archives what is on disk, and a game that holds the world in memory between autosaves will otherwise give you a copy that is minutes old. [Cron expressions explained](https://www.renode.space/blog/cron-expressions-explained) covers the timing syntax and [scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having) has more patterns. How often depends on how much play you can afford to lose. A small server for friends is well served by one scheduled backup a day plus a manual one before every update. A busy community server may want several a day. With a limited number of slots, rotation keeps the newest and drops the oldest, which is why locking one known-good copy matters. #### Why you still keep an off-site copy Nightly backups protect you from the failures that happen to servers: a bad update, a corrupted save, a plugin that wipes a table. We pull copies of them off the node every day, so they are not on the same machine they protect. What they cannot protect you from is anything that happens to the relationship between you and us. - **Deleting the server deletes its backups.** Ours and yours, locked ones included. A mistaken delete is not recoverable from our side. - **A cancelled service goes the same way.** When a server is removed, for whatever reason, its backups are removed with it. - **Your account is a single point of failure.** If you lose both your two-factor device and your recovery codes, the account cannot be recovered, and neither can anything only reachable through it. - **Any host is one supplier.** This is not specific to us. A copy that only exists inside one company's systems depends on that company in every way, and the [3-2-1 rule](https://www.renode.space/blog/s3-storage-sizing-and-the-3-2-1-rule) - three copies, two kinds of storage, one somewhere else - exists because people learned that the hard way. > A backup that only exists inside the service it is backing up is a feature of that service, not a backup. The off-site copy does not need to be frequent. Weekly is fine for most game servers, plus one before any major change. What matters is that it exists, is somewhere you control, and has been opened at least once to check it restores. #### Making the off-site copy There are three practical ways, from least effort to most automated. The first is manual: download a backup from the Backups tab every week or before a big change and keep it on your own disk or cloud drive. It takes a minute, which is also why people stop doing it after a month. The second is a sync from your own machine over SFTP with rclone. Configure an SFTP remote with the host, port, username and password from the panel's SFTP details, then copy the folders that matter: ```bash $ rclone config create renode sftp host HOST port PORT user USER pass PASSWORD $ rclone copy renode:world ./server-backup/$(date +%F)/world --progress ``` Copy only what you need - world, configs, plugin data - not the game binaries, which reinstall anyway. Pair it with a database dump from the same moment. Note that `rclone config create` obscures the password before storing it, but the config file still lets anyone who reads it log in, so keep it on a machine you trust. The third is object storage: send your copies to an S3-compatible bucket with rclone or restic. Restic adds deduplication, encryption and its own retention rules, which suits a copy that runs on a timer from a machine you own. [Game server backups to S3](https://www.renode.space/blog/game-server-backups-to-s3) and [restic backups to S3](https://www.renode.space/blog/restic-backups-to-s3) cover both in full. RE:NODE sells [S3 object storage](https://www.renode.space/object-storage) too, but be clear about what that is: it is on the same platform, in the same location, as your server. It is a good second kind of storage and a convenient target for scripts; it is not the "somewhere else" in 3-2-1. For that, the bucket or the disk has to belong to someone other than your host. Whichever you choose, restore from it once. Unpack the archive, load the dump into a scratch database, start a copy of the server from it if you can. [Testing a restore before you need it](https://www.renode.space/blog/testing-a-restore-before-you-need-it) has the checklist, and [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) explains why the test is the backup's real job. A backup nobody has restored is a hypothesis. #### What nightly backups do not replace To be plain about the limits, so nobody plans around something that is not there: - **No self-service restore of system backups.** It goes through support, so it takes as long as a conversation with staff, not one click. For anything you may need back in a hurry, your own backup is faster. - **No long history.** The window is short. Older recovery points are yours to keep, locked in your slots or off-site. - **No point-in-time recovery.** A nightly backup is a nightly backup. Anything between last night and now exists only on the live server. - **No protection from deletion.** Delete a server and its backups go with it. - **No database-engine backups for database hosting plans beyond the file archive.** Database servers get the nightly file archive like everything else, but a file copy of a running database engine is not the same as a dump taken by the engine. For PostgreSQL, MongoDB, MySQL or SQL Server plans, schedule your own dumps - [database backups and restores](https://www.renode.space/blog/database-backups-and-restores) and [database dumps to S3 on a schedule](https://www.renode.space/blog/database-dumps-to-s3-on-a-schedule) show how. None of that makes the nightly backup less useful. Most of the bad days a server owner has are the kind it covers: an update that went wrong last night, a config edited badly this morning, a mod that corrupted a save. It just is not the whole plan, and treating it as the whole plan is how people end up asking for a copy from three weeks ago that does not exist. #### FAQ ##### Do nightly backups count against my plan's backup slots? No. They are system backups, made outside your plan's backup limit, so every slot on your plan stays free for your own copies. Plans with no backup slots get the nightly backup as well. ##### Can I download or restore a nightly backup myself? No. They are hidden from the Backups tab so that nobody with panel access can delete them. To restore from one, open a ticket or use the server chat and say which night and which parts you want back. ##### Are plugin and mod databases included? Databases created in the panel for a game server are dumped separately every night, since the server archive holds files only. Ask for the database to be restored to the same night as the files, or the two will not match. ##### How far back do the nightly backups go? Only a short rolling window of recent nights. They are for recovering from something that went wrong recently. For an older known-good point, lock one of your own backups or keep a copy off-site. ##### If I delete my server, can support bring it back? No. Deleting a server deletes its backups, locked ones included, and the system backups are no exception. The only copy that survives a deletion is one you downloaded or synced somewhere yourself. ##### Do I need my own backups if nightly ones exist? Yes. Take one before every update, wipe or big config change, so you can roll back yourself in one click without waiting for anyone, and keep one locked as a known-good point the nightly window cannot reach. Every RE:NODE server is backed up each night outside your backup slots, with game databases dumped alongside. Your own backups are on demand or scheduled, restored with a button, downloadable and lockable against rotation. [See game server plans](https://www.renode.space/game-servers) --- ### Pay for hosting with crypto: coins, fees and confirmation times Published 2026-10-16 by RE:NODE Team. https://www.renode.space/blog/pay-for-hosting-with-crypto You can pay for a RE:NODE server in crypto. Pick "Pay with crypto" when you order or renew, and you are sent to a NOWPayments invoice page where you choose a coin - USDT, BTC, ETH, LTC and more - and send the amount it shows. The invoice is for exactly the plan's price, in dollars. Confirmation takes roughly 10 to 60 minutes depending on the network, and once the payment confirms the server is created on its own; nobody has to approve it. The things that catch people out are not the coins themselves but the edges: some coins have a minimum that is larger than a cheap plan, wallets and exchanges take fees in ways that make the amount that arrives smaller than the amount you meant to send, and sending to the wrong network can lose the money outright. This guide covers the whole path: how the payment flows from your wallet to a running server, which coin to pick for which amount, what the fees are and who pays them, how long each stage takes, and what happens when something does not go to plan. Most of the coin and network advice applies to paying any merchant in crypto, not just us. #### How crypto checkout works, step by step Crypto is offered in three places: the order popup on the site, the order dialog in the panel's shop, and the renewal dialog for a service you already have. It is also a way to top up your wallet balance from the billing page. The steps are the same in each case. 1. Pick the plan and the term (one month, or 3, 6 or 12 months, which are cheaper per month). The dialog shows the price. 2. Choose "Pay with crypto". The panel opens an invoice with NOWPayments for that exact figure and sends you to NOWPayments' hosted invoice page. 3. On the invoice page, pick a coin and, where a coin exists on several networks, the network. The page shows the amount of that coin to send and the address to send it to. 4. Send the payment from your wallet or exchange. 5. Come back to the panel. A status page follows the payment through "Waiting for your payment", "Confirming on the blockchain" and "Payment confirmed" and updates by itself. 6. When the payment confirms, the money lands on your account balance and the purchase is made from that balance straight away. For a new plan the server is created; for a renewal the service is extended. ```diagram title: From your wallet to a running server wallet = Your wallet | coin + network invoice = NOWPayments | hosted invoice page chain = Blockchain | 10-60 minutes panel = RE:NODE panel | payment confirmed balance = Account balance | credited in USD server = Your server | created automatically wallet -> invoice : send exact amount invoice -> chain chain -> panel : confirmed panel -> balance balance -> server : purchase made ``` That middle step - money onto the balance, then the purchase made from the balance - is deliberate. It means a crypto purchase goes through exactly the same path as paying from your balance with any other method, with the same price, the same term discount and the same provisioning. It also means that if the purchase fails after the money has arrived (a plan withdrawn, a node with no room), the payment is not lost: it sits on your balance, the status page says "Payment received and added to your balance, but the purchase could not be completed", and you can buy from the balance or open a ticket. For the general order flow, including what happens on the panel side after a server exists, see the [ordering section of the guides](https://www.renode.space/guides#order). #### Supported coins and networks The invoice page lists the coins NOWPayments can accept for your amount. USDT, BTC, ETH and LTC are always the ones we name, and the page offers more - TRX among them. We do not publish a complete list because it is NOWPayments' list, not ours, and it changes. What is on the page when you open the invoice is the answer. The important distinction is between a coin and a network. Bitcoin, Litecoin and Tron's TRX live on their own chains, so there is one way to send them. USDT is different: it is a token issued on several chains, including Tron and Ethereum, and each version is effectively a separate asset on a separate network. The same goes for some other stablecoins. The invoice page lists these variants separately, and the address it gives you is for one network only. > [!WARNING] Send USDT on the network the invoice shows. USDT sent on Ethereum to an address that expects USDT on Tron, or the other way round, does not arrive as a payment, and getting it back is not guaranteed by anyone. Exchanges make this easy to get wrong, because their withdrawal form has a network dropdown that often defaults to whatever is cheapest or whatever you used last. Before you press withdraw, check three things against the invoice: the coin, the network and the address. Copy the address rather than typing it, and compare the first and last few characters after pasting. #### Coin minimums and small plans Every coin has a smallest payment that is worth processing once network fees are counted, and those minimums differ a lot. Roughly, USDT needs about $11 and BTC about $20, while LTC, TRX and ETH can carry amounts well under a dollar. The panel tells you this in the dialog: "Some coins have a minimum (USDT about $11, BTC about $20). For smaller amounts choose LTC, TRX, ETH or similar." These minimums matter because many plans cost less than that. A Terraria or Counter-Strike 1.6 server starts at $3 a month, a Valheim server at $6, a Node.js app server at $4. You can pay any of those in crypto, but not in BTC for a single month. You have two options: - **Pick a low-minimum coin.** LTC, TRX and ETH handle small invoices without trouble. For most people paying a few dollars, Litecoin is the simplest: one chain, fast blocks, low fees. - **Pay for a longer term.** A 6 or 12 month term is cheaper per month and pushes the total over the BTC or USDT minimum. If you were going to keep the server anyway, this costs less overall. The invoice is always for the plan's real price. An earlier version of our checkout padded every crypto purchase up to $15 so that USDT would always work, which meant a $5 plan cost $15 in crypto. It no longer does that: you pay what the shop says, and the invoice page offers whichever coins can carry that amount. There is also a floor below which crypto is not offered at all - the dialog says "Crypto is available from" and the figure - and a ceiling per payment. If a long term on a large plan goes over the ceiling, the dialog says so and suggests a shorter term or another payment method. | Amount you are paying | Sensible coins | Why | |---|---|---| | Under about $11 | LTC, TRX, ETH | USDT and BTC minimums too high | | About $11 to $20 | USDT, LTC, TRX, ETH | BTC still below its minimum | | Over about $20 | Any listed coin | Pick on fees and convenience | The minimum figures come from NOWPayments and move with network conditions, so treat them as approximate and trust what the invoice page offers on the day. #### Network fees and who pays them There are two kinds of cost in a crypto payment, and it helps to keep them apart. The first is the **network fee** (on Ethereum, gas). It is paid to the network to include your transaction, by whoever sends it - you. It is not part of the invoice and it does not reach us. How much it is depends entirely on the chain and how busy it is: - **Bitcoin** fees rise and fall with demand for block space. On a quiet day they are small; on a busy day a small payment can cost a noticeable share of its value to send. - **Ethereum** gas varies the same way. Sending ETH is a plain transfer; sending USDT on Ethereum is a token transfer, which uses more gas, and you need ETH in the wallet to pay it. - **Tron** is cheap for USDT, but a token transfer still consumes network resources that are paid in TRX. A wallet holding only USDT on Tron and no TRX may not be able to send at all. - **Litecoin** fees are usually low, which is part of why it is the default advice for small payments. The second is the **exchange or wallet fee**. Exchanges charge a withdrawal fee, and some subtract it from the amount you enter rather than adding it on top. This is the single most common cause of an underpayment. You type the exact invoice amount, the exchange takes its fee out of it, and slightly less arrives than the invoice asked for. > [!TIP] When you withdraw from an exchange, check whether the "amount received" line on the withdrawal form matches the invoice. If the fee is taken out of the amount, raise the amount you enter until what arrives is the full figure. Wallets that let you choose a fee level ("slow", "normal", "fast") are worth a moment's thought. The lowest fee on Bitcoin can mean a transaction that sits unconfirmed for a long time when the network is busy, and the invoice will not wait for ever. For a payment that is meant to create a server today, a normal fee is the sensible choice. #### Confirmation times by network Once you send, two things have to happen: the transaction has to be seen, and then it has to collect enough confirmations for NOWPayments to treat it as final. The panel's status page shows both stages. "Waiting for your payment" means no transaction for the invoice has been seen yet; "Confirming on the blockchain" means it has been seen and is waiting for confirmations, which "usually takes 10-60 minutes". Where you land in that range depends mostly on the chain: | Chain | Block interval | What to expect | |---|---|---| | Bitcoin | about 10 minutes | The slow end of the range | | Litecoin | about 2.5 minutes | Usually quick | | Ethereum | about 12 seconds | Usually quick | | Tron | about 3 seconds | Usually quick | Block interval is not the whole story. The processor needs a number of confirmations, which varies by coin, and a transaction sent with a low fee can wait several blocks before it is included at all. Exchanges add their own delay: many batch withdrawals or hold them for a security check before anything is broadcast, so the clock does not start when you press the button. If you are watching the status page and it still says "Waiting for your payment" twenty minutes after you sent, check the exchange's withdrawal history first. Very often the coins have not left yet. If a payment is slower than usual, the status page says "Still processing" and that it will be credited automatically once confirmed. You do not need to do anything, and you should not send the payment again; a second send creates a different problem, covered below. Compare this with card and PayPal, where the server is created when payment clears, usually inside a minute. Crypto is not the fast option. If you need a server for a session starting in fifteen minutes, it is the wrong method. #### What happens after it confirms When the payment confirms, the panel credits your balance with the invoice's price in US dollars. Note what that means: you are credited the dollar figure you were shown, not the coin amount converted at some later rate. If the coin's price moves while the transaction confirms, that is not your problem and not ours. Then the purchase runs from the balance: - **New plan.** The status page shows "creating your server", then "Your server is ready" with a link to it. Game, app, web and database servers are built automatically, the same way as with any other payment method. VDS orders are prepared by hand, and cannot be paid in crypto at the moment anyway. - **Renewal.** The service's term is extended and the status page says "Service renewed". - **Balance top-up.** The amount appears on your balance ("Funds added") and stays there until you spend it on a purchase or a renewal. A top-up is the most flexible way to use crypto. If your plan costs less than the minimum of the coin you hold, or you want one crypto payment to cover several small renewals, top up the balance with a larger amount and pay from it. The balance pays for plans and renewals exactly like a card would, and renewal invoices are emailed 7 days before expiry and on the day, so you have time to pay from the balance before anything lapses. Every payment produces an invoice in your account, crypto included, so the record of what you paid sits with the rest of your billing. #### When a payment goes wrong Most crypto payments go through without anyone noticing. These are the ones that do not, and what each state on the status page means. | Status | What happened | What to do | |---|---|---| | Partial payment received | Less than the invoice arrived | Wait; support reviews it | | Payment expired | Nothing arrived in time | Start a new payment | | Payment failed | It did not go through | Retry, or ticket if coins left | | Payment not found | The panel cannot match it | Ticket with the reference | | Purchase not completed | Paid, but the order failed | Buy from the balance | ##### Partial payments An underpayment - usually an exchange fee taken out of the amount - is marked "Partial payment received" and nothing is credited automatically. That is on purpose. Crediting the full amount would give money away, and crediting a part of it is a decision about your money that should have a person behind it, so staff review each one and get in touch. You will not lose the amount you sent, but you will wait for a human instead of a machine. Avoiding the fee trap in the section above avoids this entirely. ##### Sending twice to the same address If you send a second payment to an address you already paid - because the first looked stuck, or because you reused an address from an earlier invoice - it is not credited automatically either. A second send to an old address is valued at that day's rate for whatever was sent, which is not what any invoice asked for, so it also goes to staff for review. The rule that follows: one invoice, one payment. For a new purchase, open a new invoice and use the new address. ##### Expired and failed invoices An invoice does not wait for ever. If nothing arrives before it expires, the status page says "Payment expired", nothing was charged, and you start again. If coins did leave your wallet and the page says expired or failed, do not send again - open a ticket with the reference shown on the status page and the transaction hash from your wallet or exchange, and support will look into it. > [!NOTE] Keep the reference from the status page and the transaction hash until the server is running. Those two strings are what support needs to find a payment. There is no refund button for any payment method; refunds go through a ticket. For crypto in particular we do not promise a refund back to a wallet, so if you are unsure whether you want a plan, a short term is a cheaper way to find out. #### Choosing a coin: practical advice If you are paying crypto for the first time, or for the first time in a while, these are the choices that make the difference. - **Small amount, simplest route:** LTC. One network, low fees, quick confirmations, low minimum. - **You hold stablecoins:** USDT on Tron is usually the cheapest way to move dollars, provided the amount is over the USDT minimum and you have a little TRX for the transfer. - **You hold Bitcoin and the amount is over about $20:** BTC is fine, but use a normal fee and expect the slower end of the confirmation range. - **You hold ETH:** sending ETH itself is cheaper than sending a token on Ethereum. Keep enough ETH left over to cover gas. - **You are paying from an exchange:** check the network on the withdrawal form, check whether the fee is deducted from the amount, and expect the exchange's own processing delay before the clock starts. - **The amount is under every coin's comfortable minimum:** pay for a longer term or top up the balance with a round figure and buy from it. And a word on why you might not use crypto. It is slower than card or PayPal, every send costs a network fee, mistakes with networks or addresses are hard to reverse, and bundles and VDS orders cannot be paid in crypto yet. If none of that bothers you, or you would rather not put a card on file with a hosting provider, it works well. If you just want a server in the next minute, a card is quicker. Choosing the plan itself is a separate question, and [how much a game server costs](https://www.renode.space/blog/how-much-does-a-game-server-cost) and [when to upgrade your plan](https://www.renode.space/blog/when-to-upgrade-your-plan) cover that. #### What crypto cannot pay for yet A few things are outside crypto checkout at the moment: - **Bundles.** A bundle - an app server with its database and cache bought together - is paid by cash, wallet balance or PayPal. You can still top up the balance in crypto and then buy the bundle from the balance on the panel shop's Bundles tab. - **VDS orders.** The VDS line is prepared by hand and cannot be bought in crypto directly. - **Amounts over the per-payment ceiling.** A long term on a large plan can go over it; choose a shorter term or another method. Once the server exists, it is the same server whatever paid for it. If it is your first one, the [first game server checklist](https://www.renode.space/blog/first-game-server-checklist) is a good next read, and the full catalogue is on the [game servers page](https://www.renode.space/game-servers). #### FAQ ##### Which crypto coins can I use to pay for hosting? USDT, BTC, ETH and LTC, plus others that NOWPayments lists on the invoice page, such as TRX. The page only shows coins that can carry your amount, so a small invoice may not offer BTC or USDT. ##### How long until my server is ready after paying in crypto? Usually 10 to 60 minutes from when the transaction is broadcast, depending on the network and the fee you chose. Bitcoin is at the slow end. The server is created automatically once the payment confirms; exchange withdrawals can add their own delay before that clock starts. ##### Do I pay more in crypto than by card? The invoice is for the same price the shop shows. What you pay on top is the network fee to send the transaction, and any withdrawal fee your exchange charges. On Litecoin or Tron those are usually small; on a busy Bitcoin or Ethereum network they can be more noticeable. ##### I sent slightly less than the invoice. What happens? The payment is marked as partially paid and nothing is credited automatically. Staff review it and get in touch. The usual cause is an exchange subtracting its withdrawal fee from the amount, so check the amount received next time. ##### Can I top up my balance with crypto and pay later? Yes. A crypto top-up credits your balance in dollars, and the balance pays for new plans and renewals like any other method. It is a good way round coin minimums on cheap plans, and the only way to use crypto towards a bundle. ##### Can I get a refund in crypto? Refunds go through a ticket, not a button, and we do not promise a refund back to a crypto wallet. If you are not sure about a plan, start with a short term. Choose "Pay with crypto" at checkout to pay in USDT, BTC, ETH, LTC and more for exactly the plan's price. Once the payment confirms, game, app, web and database servers are created automatically, with backups, SFTP and the full panel on every plan. [See game server plans](https://www.renode.space/game-servers) --- ### Reading ping and hops on your game server panel Published 2026-10-16 by RE:NODE Team. https://www.renode.space/blog/reading-ping-and-hops-on-your-server The RE:NODE panel shows three network figures, and each answers a different question. **Ping** on the dashboard is the round trip from your own browser to the machine your server runs on, sampled every few seconds. **Average Ping** on the Console tab is the mean round trip to that machine from probes in 12 countries, measured only when you press "Test now". **Hops** is the number of routers between our network and your connection, and "≥N" means the trace went quiet before it reached you. None of the three is the ping a player sees in the scoreboard, and none of them measures the game itself. Used together, they answer the first question in every lag complaint: is this the network, and if so, whose part of it. This post is what each figure is built from, what it misses, and the order to read them in when somebody says the server is lagging. #### Three figures, three different measurements It helps to put all three side by side before going into any of them, because most confusion comes from reading one as if it were another. | Figure | Where it is | Measured from | |---|---|---| | Ping | Dashboard, each server row | Your browser, every 5 seconds | | Average Ping | Console tab, stats strip | 12 probe countries, on demand | | Hops | Console tab, stats strip | Our side, towards your address | The dashboard figure is live and personal. It tells you how your connection reaches the machine right now, and it says nothing about anybody else's. Average Ping is a snapshot of the world, taken the moment you ask for it and not again until you ask. Hops is about the path rather than the time, and like the dashboard figure it describes you, not your players. That last point matters more than any number on the page. A server owner in one city looking at their own hop count learns about their own route. A player on another continent, on another provider, has a different route with a different count. When the complaint comes from a player, the strip gives you the context; the player has to give you their own measurement. We come back to how to ask for it below. #### The dashboard Ping: your browser to the node On the server list, every row carries a Ping metric next to memory, CPU and disk. It is the round trip from the browser you are using to the node that hosts the server. A few details about how it is taken explain why it behaves the way it does. - **It is an HTTP request, timed.** A browser cannot send an ICMP echo the way the `ping` command does, so the panel sends a tiny web request to the node and times how long the answer takes. The content of the answer is never read; any reply proves the round trip. - **Two requests, the faster kept.** The first request of a pair may have to open a fresh connection, which costs extra round trips that are not what anyone means by ping. The second rides the connection the first opened. The panel keeps the quicker of the two. - **The figure is a median.** It is the middle value of the last five samples, so one slow packet does not make the number jump. - **One sampler per node.** Rows for servers on the same node share a single measurement, so a long server list does not multiply the traffic. - **Hidden tabs are not sampled.** A dashboard left open in a background tab stops measuring until you look at it again. - **Over 250 ms it is flagged.** The metric is marked in the alarm style when the figure passes 250 ms. Because it is an HTTP timing in a browser rather than a raw ICMP packet, expect it to sit a few milliseconds above what `ping` prints from the same machine. Browser scheduling, the TLS layer and the web server answering all add a little. The difference is small and constant, so the figure is honest for comparisons: your number this evening against your number last week, or one node against another. What the dashboard Ping is good for is answering "is it me?" quickly. If your own figure doubled since yesterday while nothing changed on the server, the first suspect is your own connection: wifi, a download running on the same line, a VPN you forgot was on. If it sits at its usual value while your players complain, your path is fine and the problem, if it is on the network at all, is on theirs. #### Average Ping: the world, on demand Under the console sits a bar titled "Latency around the world". Press **Test now** and the panel asks the Globalping network (globalping.io), a free network of volunteer probes, to ping the server's node from one probe in each of 12 countries spread across Europe, the Middle East, the Americas, Africa, Asia and Oceania. Each probe sends three packets. Results arrive over a few seconds; the panel stops waiting after about 25 seconds and shows whatever has come back. The grid shows one cell per country with its average in milliseconds, sorted fastest first, plus a "You" cell with your own browser figure for comparison. Cells are toned by speed: under 100 ms reads as good, 100 to 199 ms as middling, 200 ms and over as slow. If a probe lost packets, hovering the cell shows the percentage lost. A probe that never answered shows "no reply" instead of a number. The Average Ping in the stats strip above the console is the mean of the probes that answered, rounded to a whole millisecond. Probes that failed are left out of the average rather than counted as zero or as infinity. A few things to keep in mind when reading it: - **It only runs when you press the button.** The test sends the node's address to a third party, so the panel never runs it on page load. Until you test, the strip shows a dash and its tooltip tells you to press "Test now". After a test there is a 20-second pause before the next one will start. - **The free network has a limit.** If too many tests are run in a short time, Globalping refuses and the bar says "The free test limit was reached. Try again in a few minutes." That is their limit, not a fault on the server. - **Probes are real devices on real connections.** Some sit in data centres, some on home lines. A single country showing a figure far above its neighbours may be that one probe's connection on that minute. Run the test again before reading anything into one odd cell. - **Three packets is a snapshot.** It tells you the round trip at that moment. It does not show jitter over time or loss that comes and goes every few minutes. For that you need a longer test from the player's side, which is the subject of a later section. ##### Why the average looks high and is still fine A world average is an average over the whole planet. Any single server, wherever it is, is close to some of those 12 countries and far from others, and the far ones pull the mean up. A server can be excellent for its own region and still show a three-digit Average Ping, because Australia and Brazil are a long way from almost everywhere. That is arithmetic, not a fault. So read the grid, not just the average. The useful questions are: what do the countries your players actually live in show, and has that changed since the last time you looked? The bands in our post on [game server ping by region](https://www.renode.space/blog/game-server-ping-by-region) give you a feel for what each distance should cost. If your players are mostly in two countries and both show two-digit figures with no loss, the network is doing its job, whatever the average says. #### Hops: counting the routers The Hops figure in the stats strip is the number of routers between our side and the address you are visiting the panel from. A browser cannot see its own route, so the trace runs the other way: our side walks the path towards your address with `tracepath`, which sends UDP probes with increasing TTL values and notes which router answers at each step. It is the same principle as the traceroute tools you may already know. What a trace looks like (illustrative): ```text 1?: [LOCALHOST] pmtu 1500 1: 10.0.0.1 0.412ms 2: 192.0.2.17 1.006ms 3: 198.51.100.4 4.880ms ... 14: 203.0.113.9 31.207ms reached Resume: pmtu 1500 hops 14 back 14 ``` When the destination answers, `tracepath` prints a `Resume:` line with the real hop count, and the strip shows a plain number: `14`. When it does not, the panel takes the last numbered line that had an address on it and shows that as a lower bound: `≥11`. The tooltip says exactly that: "≥" means the last routers did not answer, so the real count is at least that many. A `≥` figure is normal. Most home routers and many mobile networks drop the probes a trace depends on, so the trace runs into silence a hop or two before the end even though your connection is perfectly reachable. The panel stops a trace after four silent hops in a row at the end, and never traces further than 24 hops. Some practical details: - **It is cached for ten minutes.** A trace can take up to about twenty seconds, and routes do not change by the minute, so the result for an address is kept for ten minutes and the strip asks again on that interval. A route change will show up on the next refresh, not instantly. - **It shows a dash when it cannot measure.** If your address is private or reserved (you are on the same network as the panel, or behind certain proxies), or a trace is still running, the strip shows a dash and tries again shortly. - **A VPN changes what is measured.** If you browse through a VPN, the trace ends at the VPN's exit, not at your home. The count is then the distance to the VPN server. - **Your address is not stored.** The cache is keyed on a hash of the address and holds only a count. ##### Why hops matter, and why they are not the whole story Hop count does not translate into milliseconds directly. A modern router forwards a packet in well under a millisecond, so ten extra hops inside one city cost almost nothing. Distance costs far more: light in fibre covers roughly 200 km per millisecond, so a path that runs 3,000 km out of its way adds around 30 ms to the round trip whether it crosses five routers or fifteen. Hops still matter, for three reasons: 1. **They expose detours.** If a player in a neighbouring country has 25 hops to the server while someone further away has 12, the first player's provider is probably sending traffic the long way round, through an exchange in another country. That is the classic cause of "my ping is bad but my friend's is fine". 2. **Every hop is a queue.** Each router is a place where packets can wait behind other traffic at a busy hour. More hops means more places for jitter and loss to come from, especially where traffic crosses between networks. 3. **Comparison is useful even when the absolute number is not.** Your count today against your count last week is a cheap way to notice that a route changed. If the hop count jumped and your ping rose with it, the route changed and you know where to look. What hops cannot tell you is which hop is slow. For that you need a per-hop view, which is what MTR gives you. Our post on [reading traceroute and MTR](https://www.renode.space/blog/reading-traceroute-and-mtr) covers how to read one without being fooled by routers that deprioritise probe replies. #### When players say the server lags "Lag" covers four or five unrelated problems, and the panel figures help with only one family of them. Before looking at any network number, rule out the server itself. The reasoning is simple: if the server is struggling, every player feels it at once, whatever their ping; if it is the network, the complaint follows particular players, places or times of day. A working order: 1. **Is it everyone or some people?** If everyone rubber-bands at the same moment, look at the server first. If one player or one country is unhappy, it is almost certainly the network between them and the server. 2. **Check the server graphs.** The Console tab draws memory, CPU and disk against the plan's limits. A CPU line pinned at the limit while players complain means the server cannot keep up its tick rate; that feels like lag to every player and no network fix will touch it. Our post on [what tick rate actually means](https://www.renode.space/blog/what-tick-rate-actually-means) has the in-game commands that show it per game. 3. **Check your own dashboard Ping.** If your figure is normal, the node is reachable and responsive from at least one place. 4. **Run the world test.** Press "Test now" and look at the countries your players come from. Normal figures and no loss mean the node's connectivity to that part of the world is fine at this moment. 5. **Ask the complaining player for their own measurement.** This is the step that actually locates the problem, because their path is the one in question. If steps 2 to 4 are clean and one player still suffers, the problem is somewhere on that player's path: their wifi, their provider's routing, a congested link between networks at peak time. You cannot fix their provider, but you can give them a clear answer, and they can take a good measurement to their provider. ##### What to ask the player for The panel's figures are measured from places that are not the player. Ask them to run a test from their own machine to the server's address (the IP shown on the panel, without the port, since `ping` does not use ports). On Windows: ```bash $ ping -n 50 203.0.113.10 $ tracert 203.0.113.10 $ pathping 203.0.113.10 ``` On Linux or macOS, with `mtr` installed: ```bash $ ping -c 50 203.0.113.10 $ mtr -rwc 100 203.0.113.10 ``` Ask for the test at the time the lag happens, not the next morning. Evening congestion is real, and a clean test at 10:00 says nothing about 21:00. Fifty pings show the average, the spread between minimum and maximum (a rough read on jitter) and any loss. The `mtr` report or `pathping` output shows where along the path latency or loss starts and whether it carries through to the end. Some networks drop ICMP to the destination, so a ping that times out completely while the game connects fine is not proof of anything. In that case the trace and the game's own ping display are the better evidence. #### Matching numbers to symptoms Once you have the player's figures alongside yours, the common patterns read like this: | What you see | Likely meaning | |---|---| | Player ping high, steady, no loss | Distance or a long route | | Ping jumps around by tens of ms | Jitter: wifi or a busy line | | Loss that reaches the last hop | A real network fault on the path | | Loss at one middle hop only | A router ignoring probes, harmless | | Everyone lags together, CPU at limit | The server, not the network | | Player's hops far above nearby players | Their provider routes the long way | High and steady is the easiest case and the least fixable. A player 150 ms away will always be 150 ms away, and no setting on the server changes the speed of light. Games compensate in different ways; a co-op survival game hides 150 ms well, a competitive shooter does not. Jitter and loss feel much worse than their averages suggest, because the game has to wait for or guess at missing updates. Our post on [latency, jitter and packet loss](https://www.renode.space/blog/latency-jitter-and-packet-loss) goes through what each does to a game and how to tell them apart in a minute of `ping`. The short version for a player: plug in a cable, stop the download running on the same line, and test again. A surprising share of "the server lags" ends there. The long-route case is the one where hop counts earn their place. If two players in the same city on different providers see 15 and 28 hops and a 40 ms difference in ping, the problem is the second provider's routing. The player can report it with their trace attached; providers sometimes change a route when a customer shows them the detour. Some players try a VPN to force a different route. Occasionally that helps, more often it adds distance; our post on [whether a VPN lowers ping in games](https://www.renode.space/blog/does-a-vpn-lower-ping-in-games) covers how to test it rather than guess. #### A worked example Say a group of eight plays on a server most evenings. Six are in one country, two in a neighbouring one. One of the two starts reporting rubber-banding around 21:00 every evening. You open the panel. The CPU graph shows the server comfortably below its limit while the complaints come in, and the other seven are not complaining, so it is not the server. Your dashboard Ping is at its usual value. You press "Test now": the country closest to the struggling player shows a normal two-digit figure with no packet loss. So the node's link to that part of the world is fine, and your own path is fine. The suspect is the player's own path. You ask them to run `mtr -rwc 100` (or `pathping` on Windows) at 21:00. Their report shows clean figures for the first eight hops, then latency rising by 60 ms and 4% loss from hop nine onwards, carried through to the final line. Hop nine is the point where their provider hands traffic to another network. That is congestion at an interconnect at peak hour, and it is entirely outside your server. The useful thing you can do is tell the player plainly, and suggest they send that report to their provider with the time of day on it. A test at 10:00 the next morning would have shown nothing, which is why the timing of the request mattered. Compare that with the opposite outcome: the player's trace is clean all the way, but in-game they still see delays. Then go back to the server side, because something other than the network is the cause: a plugin spiking the tick time, a save running every few minutes, a server sitting at its CPU limit only when that player's base is loaded. #### What the panel figures cannot tell you It is worth being plain about the limits, because a number on a dashboard looks more authoritative than it is. - **None of them is the in-game ping.** Games measure ping in their own way, often including a tick or two of processing on top of the network trip. A game showing 60 ms where `ping` shows 45 ms is normal. - **None of them measures your players' paths.** The world test uses one probe per country, on that probe's provider. Your players use others. - **The world test is a moment.** Three packets per probe, taken when you pressed the button. It does not catch a problem that comes and goes. - **The hop count describes our side to you.** It is traced from our side to the address you browse from, which is a useful indicator of the distance and how straight the route is, but it is your path, not a player's. - **Loss on the world grid is a hint, not a verdict.** A probe losing one of three packets may be that probe's own line. Loss that appears from several countries at once is worth a closer look; loss on one cell is worth a second test. Used for what they are, the three figures save time. They rule out your own connection in a glance, show whether the node is reachable from where your players live, and turn a vague "it lags" into either "it is the server" or "it is somewhere on your path, please run this". That second answer is the one players most need and least often get. #### FAQ ##### Why is my Average Ping over 100 ms when the server feels fast? Because it averages 12 countries spread across the world, and some of them are a long way from any single server. The far probes pull the mean up. Look at the cells for the countries your players live in; those are the figures that describe their experience. ##### What does "≥" in front of the hop count mean? The trace stopped hearing answers before it reached your connection, usually because your home router or mobile network drops trace probes. The count shown is the last hop that answered, so the real figure is at least that. It is common and not a fault. ##### Can I run the world ping test automatically every hour? No. It runs only when you press the button, because each test sends the node's address to a third-party probe network. There is also a short cooldown between tests and a rate limit on the free network, so frequent testing is not what it is for. For trends, run `mtr` on a schedule from a machine you control. ##### Does a lower hop count always mean lower ping? No. Distance matters much more than the number of routers. A route with 18 hops inside one region can be faster than a 10-hop route that crosses a continent. Hops are most useful for spotting a detour or a route change, not for predicting milliseconds. ##### My dashboard Ping is higher than what the ping command shows. Which is right? Both, measuring slightly different things. The dashboard times a small web request from the browser, which carries a few milliseconds of overhead that an ICMP ping does not. Use it to compare against itself over time; use `ping` for an absolute figure. ##### Is my IP address stored when the panel counts hops? No. The result is cached for ten minutes under a hash of the address, and what is kept is a number. The world ping test sends the node's address to Globalping, which sees your address the way any website you call does. Every RE:NODE game server comes with the same panel: live ping on the dashboard, a world latency test and hop count on the Console tab, and CPU, memory and disk graphs against your plan's limits, so you can tell network lag from server lag before anyone opens a ticket. [See game server plans](https://www.renode.space/game-servers) --- ### The RE:NODE panel in Georgian: switching language and what changes Published 2026-10-16 by RE:NODE Team. https://www.renode.space/blog/renode-panel-in-georgian The RE:NODE panel can now be read in Georgian from the login page to the last tab of a server. There is one switch, "EN / ქა", in the sidebar beside the theme toggle and on the login page. Press it and the page changes language at once, without a reload, and the choice is saved on your account so the next sign-in, on any browser, opens in the same language. Everything a customer touches is covered: the server list, the console and its power buttons, files, backups, schedules, databases, the GitHub and deploy tabs, the "Work on this server with AI" bar, the support chat, the shop, billing and invoices, and the account pages. What stays in English is what was never ours to translate - your server's own console output, your file names, the text of messages people write - plus parts of the staff side of the panel, which customers do not see. This post covers how the switch works in detail, what exactly is translated, what deliberately is not, and why we think a Georgian-language panel matters more than it looks for teams that run servers together. #### How to switch the panel to Georgian There are two places to do it, and they behave the same way. 1. On the login page, before you sign in, press `ქა` in the "EN / ქა" control. The login form, the password reset and the two-factor checkpoint switch to Georgian. 2. Once signed in, open the sidebar. The same control sits next to the light and dark theme toggle. Press `ქა` for Georgian or `EN` for English. The change is instant. The panel swaps its text in place, so you stay on the page you were on - halfway through editing a schedule, looking at the console, or in the middle of the shop. Nothing is lost by switching. If you are signed in, the panel also writes the choice to your account. That is the part that makes it stick: the language is a property of your account, not of one browser tab. Sign in tomorrow from a laptop you have never used and the panel opens in Georgian. If the panel cannot save the choice to your account (a dropped connection, for instance), it switches the page back to the language it was in. We decided a switch that visibly did not happen is better than one that seems to work and silently reverts on the next load, which is the kind of bug people report as "the language setting does nothing". > [!TIP] Registration remembers the language you read the sign-up page in. If you switch to Georgian before you create the account, the account starts in Georgian and you never have to touch the switch again. #### How the panel decides which language to show Every page request picks a language in a fixed order. Knowing the order explains every case where you might see a language you did not expect. | Order | Source | When it applies | |---|---|---| | 1 | Your account's saved language | You are signed in | | 2 | A browser cookie, `renode_lang` | Signed out, but you chose before | | 3 | Your browser's language setting | Nothing above exists | Only a language the panel actually ships is ever used, and today that means English or Georgian. A browser set to Georgian (`ka`) on a first visit sees the login page in Georgian without anyone pressing anything. A browser set to Russian or German falls through to English. The cookie is there for one specific moment: signing out. The login page has no account to ask, so without the cookie somebody who had chosen Georgian would be shown English the second they signed out. The cookie lasts a year and holds nothing but the two-letter code. It is a reading preference and nothing about it is sensitive. ```diagram title: Which language a page opens in req = Page request acct = Account setting | signed in cookie = renode_lang cookie | signed out browser = Browser language | first visit page = Panel page | en or ka req -> acct : signed in req -> cookie : no account cookie --> browser : no cookie acct -> page cookie -> page browser -> page ``` Dates follow the language as well. Relative times such as "3 days ago" and full dates on invoices, backups and the activity log are written with Georgian month names and the `ka-GE` format when the panel is in Georgian, and switch back with the language. #### What is translated The short version is every page a customer sees. The longer version, area by area, is below, with the Georgian name you will see in the sidebar so you can find your way if you are reading this in English and helping someone who uses the panel in Georgian. | Area | English | Georgian | |---|---|---| | Server list | My servers | ჩემი სერვერები | | Shop | Buy servers | სერვერის ყიდვა | | Billing | Finances | ფინანსები | | Support | Support | მხარდაჭერა | | Account | Account | ანგარიში | | Connected AI | Connected AI | დაკავშირებული AI | Inside a server, the tabs are translated too: | Tab | Georgian | |---|---| | Console | კონსოლი | | Files | ფაილები | | Databases | მონაცემთა ბაზები | | Schedules | განრიგები | | Backups | სარეზერვო ასლები | | Startup | გაშვება | | Settings | პარამეტრები | ##### Console and power controls The console page is where most people spend their time, so it got the most care. The power buttons are `ჩართვა` (Start), `გადატვირთვა` (Restart), `გამორთვა` (Stop) and `იძულებით გაჩერება` (Kill), and the kill confirmation explains in Georgian that forcing a stop can damage data. The status badge reads `მუშაობს` when the server is running, `გამორთულია` when it is offline and `ინსტალირდება` while it installs. The memory, CPU and disk graphs, the hints shown when the console is idle, the Ping and Hops strip and its "Test now" button are all in Georgian. See [reading the console](https://www.renode.space/blog/reading-the-console) for what the output itself means. ##### Files, SFTP and backups The file manager's toolbar, upload dialogs, editor, archive actions and error messages are translated, as is the SFTP details card. On the Backups tab, creating, locking, restoring and downloading a backup is all in Georgian, including the warnings - the ones that matter most, such as the confirmation before a restore, are the ones you most want to read in your own language. Our longer notes on the file manager are in [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) and on backups in [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore). ##### Schedules, databases, network and startup The Schedules tab, including the task editor with its console command, backup and power action types, is translated. Cron expressions are not, because they are not words: `0 4 * * *` means the same in every language, and our guide to [cron expressions](https://www.renode.space/blog/cron-expressions-explained) applies unchanged. The database slot page, the Network tab for ports, the Startup tab and its variables, the proxy slot, the GitHub tab with the pre-flight check, and the deploy history are all in Georgian. ##### Shop, billing and invoices The shop - categories, plan cards, the order dialog, payment methods - and the Finances area with subscriptions, invoices, the wallet and renewals are translated. The currency switcher above the shop's prices has a Georgian label, but the rates, currency codes and symbols are not translated, because they come from the published rates. The panel shows lari at the National Bank of Georgia rate and marks it as approximate; USD stays the base. ##### The AI bar and Connected AI The "Work on this server with AI" bar above the console reads `იმუშავე ამ სერვერზე AI-ით`. The purpose dropdown, the Connect AI button (`AI-ს დაკავშირება`), the share link help and the warning on links that can control the server are all in Georgian. The OAuth consent page that an assistant opens when you connect it is available in both languages. The Connected AI page in the account area, where you revoke links and disconnect assistants, is translated as well. There is more on the feature itself in [connecting Claude to your game server](https://www.renode.space/blog/connect-claude-to-your-game-server) and [AI access without leaking secrets](https://www.renode.space/blog/ai-access-without-leaking-secrets). ##### Support chat The Chat button in the server header (`ჩატი`), the floating panel, unread counts, "Seen by", whether support is online and the rating card are translated. This matters more than it seems, because the chat is the one thing a suspended server or a failed install still answers, which is exactly when someone is stressed and least wants to decode English interface text. ##### Account and security Profile, two-factor setup and recovery codes, API keys, SSH keys, teams, roles, subusers, the activity log and referrals are translated. Setting up two-factor authentication for the first time is a place where people make mistakes, and losing both the authenticator and the recovery codes means the account cannot be recovered - so reading those screens in your own language is not a cosmetic point. Our walk-through is in [two-factor on your panel account](https://www.renode.space/blog/two-factor-on-your-panel-account). #### What stays in English, and why Some things are not translated on purpose. Knowing which ones saves confusion. - **Your server's own output.** The console shows exactly what the game or the app prints. If Minecraft says `Done (4.2s)!` or Node says `Error: Cannot find module`, that is the program speaking, not the panel. We never filter or rewrite console output, in any language. - **Your files and their contents.** File names, config keys such as `max-players` or `view-distance`, environment variable names and the text inside your files stay as you wrote them. - **Messages people write.** In the support chat, the interface is Georgian but each message is shown as it was typed. You can write to us in Georgian or English. - **The prompt copied for an AI assistant.** When you press the AI bar's "Server won't start" option, the panel copies a ready-to-paste prompt with the console tail. That prompt is written for the assistant to read, not for you, and is left in English deliberately - the assistant understands it, and the console tail inside it is in whatever language your server logs in anyway. You can still talk to the assistant in Georgian. - **Brand and product names.** GitHub, SFTP, MCP, phpMyAdmin, Valkey and the names of games are names, not words. - **Parts of the staff side.** The staff area of the panel is partly translated and partly English. Customers do not see it, but if you ever wonder why a screenshot from our side looks half English, that is why. There is also a safety net. If a single Georgian string is missing somewhere - a new button added before its translation - the panel shows the English word for that one label rather than a broken page or a raw key. A missing translation is a missing word, never a missing page. If you spot one, tell us in a ticket or the chat and we will fix it. #### Why a Georgian panel matters for teams A hosting panel in English works fine for the person who set the server up. It works less well for everyone else, and on most Georgian teams there is an everyone else. Think about who actually touches a server over its life. A game community has an owner, a couple of admins who restart things and edit configs, maybe a moderator who only needs the console. A small company has a developer who deployed the app and someone in the office who pays the invoice. A school or club has a teacher and a handful of students. The owner may be comfortable in English. The rest often are not, and the price of that is not inconvenience - it is the admin who does not dare press anything, or presses the wrong thing because "Kill" and "Stop" read alike to someone guessing. The language is set per account, not per server. That means a mixed team needs no compromise: the owner can keep the panel in English while every [subuser](https://www.renode.space/blog/subusers-and-least-privilege) they invite reads the same server in Georgian. Permissions do not change with language; a subuser who can only use the console sees only the console, in whichever language they picked. Three places where this pays off in practice: 1. **Delegation.** Giving someone console-only access is far easier when they can read what each button does. Fewer messages along the lines of "which one restarts it?" 2. **Billing.** The person who pays is often not the person who runs the server. Invoices, renewals and the lari estimate in Georgian mean they can pay without a technical person standing behind them. 3. **Incidents.** When a server crashes, its owner gets a warning on the server page and, after repeated restarts, an automatic ticket. Reading that warning and the support chat in your own language is faster at exactly the moment speed counts. The public site has been readable in Georgian for a while, under `/ka`. Until now that meant a Georgian visitor read about the product in Georgian and then signed in to an English panel. That gap is closed. #### Switching back, and other questions of mechanics Switching back to English is the same switch: press `EN`. It saves the same way. There is no separate setting buried in account preferences that you also need to change. Each person on a team has their own language. Changing yours does not change it for anyone else on the server, and an owner cannot force a language on a subuser. The theme is separate from the language. The light and dark switch sits beside the language switch, and both are remembered independently, so Georgian in dark mode is as available as English in light mode. Nothing about your servers changes when you switch. No restart, no reinstall, no change to files or variables. It is a reading preference and the server does not know or care which language you read the panel in. If the page looks half-translated for a second after switching, that is the panel fetching the Georgian text for the parts of the page it had not loaded yet. It settles within a moment. If a label stays empty or English for longer, a hard refresh will load the latest strings; if it is still English after that, it is a missing translation and worth reporting. #### Troubleshooting the language switch A few situations people may run into, with the cause in each case. - **The login page opens in English although I chose Georgian.** You are on a browser that has never seen your choice and is set to a language other than Georgian, or the cookie was cleared. Press `ქა` on the login page; once you sign in, the account setting takes over. - **The login page opens in Georgian and I did not ask for it.** Your browser lists Georgian as its preferred language. Press `EN`, and the choice is remembered from then on. - **I switched, but it went back on the next page.** The save to your account failed and the panel undid the switch rather than pretend it worked. Check your connection and try again. If it keeps happening, contact support. - **A colleague sees English on the same server.** Language is per account. They need to press the switch on their own account. - **The console is still in English.** The panel around it is Georgian; the lines inside it are your server's own output and are not translated. - **Prices in lari differ slightly from the bank's rate today.** The lari figure is converted from USD at the published National Bank of Georgia rate and is marked as approximate - treat it as an estimate, not a quote. #### FAQ ##### Does switching to Georgian cost anything or change my plan? No. The language switch is available on every plan and every account, and it changes only the text you read. Your servers, billing and permissions are untouched. ##### Can I write to support in Georgian? Yes. The support chat and tickets accept whatever you type. The chat interface itself is translated, and messages are shown exactly as written. ##### Is the panel available in Russian? No. The panel ships in English and Georgian. The public website also has a Russian version at `/ru`, but the panel does not, and a browser set to Russian sees the panel in English. ##### Will my game server's console be translated? No, and it should not be. The console shows the game's or app's own output, unchanged. Only the panel's controls around it - buttons, graphs, status and hints - are in Georgian. ##### Does the language affect AI assistants connected to my server? Only on your side. The AI bar, the share-link help and the OAuth consent page are in Georgian. What the panel sends to the assistant is the same in either language, and passwords and tokens are withheld either way. ##### Can I set a different language for each subuser? Each subuser sets their own language on their own account. The owner does not choose it for them, and changing it never affects anyone else. Every RE:NODE plan comes with the same panel, now in English and Georgian, with the switch in the sidebar and the choice saved per account. Pick a game, or see app, web and database hosting from the same place. [See game server plans](https://www.renode.space/game-servers) --- ### Free trial server: how RE:NODE trials work, no card needed Published 2026-10-16 by RE:NODE Team. https://www.renode.space/blog/try-before-you-pay-free-trial A RE:NODE free trial is a real server on a real plan, built by the same machinery that builds a paid one, with no card asked for. You press "Try free" under a plan, sign in or register, confirm your email, and start it. Game and database lines usually run for 24 hours; app, web and one-click lines usually run for 30 days, but pause every 24 hours until you press **Renew**. Each account gets one trial, ever. When you pay, the trial becomes the paid plan - same server, same files, same address - and nothing has to be rebuilt or uploaded again. When you do not pay, the server is suspended, kept with its files for 7 days, and then deleted. That is the whole mechanism. The rest of this post is the detail: which plans offer a trial, what the two modes actually do hour by hour, the limits a trial runs under, and - the part most people skip - how to spend a short trial so that at the end you know whether to pay. That last section applies to a trial on any host. #### What you get, and what it costs you A trial is not a demo account or a shared sandbox. The panel creates an ordinary server on the plan you clicked, with the same console, file manager, SFTP and settings a paying customer has. Every plan gets the same panel and nothing is gated by tier, so the thing you are judging is the thing you would be buying. What it costs you is an account with a verified email address and nothing else. There is no card on file, so there is nothing to forget to cancel. A trial that runs out does not turn into a charge - it turns into a suspended server, and then into no server. What it does not give you: - **More than one.** One trial per account, for ever. Choose the plan you are actually considering. - **The big tier.** Trials are offered on the smallest tier of each line only. A game that needs the third tier to run well will not be shown at its best on the first one - more on that below. - **A renode.space address.** Trial servers cannot take a renode.space subdomain. You can connect to the server's own address, or point a domain you already own at it. - **Every product.** VDS and S3 object storage have no trial, because they are not servers the panel builds for you on the spot. #### Which plans have a trial The site draws a "Try free" button under a plan's buy button only when the panel says that plan offers one, and the button states the length: "Try free for 24 hours" or "Try free for 30 days". Under it is one line, "No card needed." If a plan has no button, it has no trial. On the home page, the "Start free" button opens a picker, "Pick a server to try", that lists every plan with a trial grouped by category. The rules behind the button: | Rule | What it means for you | |---|---| | Smallest tier of each line | The first plan the shop lists for that game or runtime | | Panel-built plans only | No trial on VDS or S3 storage | | Mode set per line | The button tells you 24 hours or 30 days | | One per account | Checked against the account and the email | The usual split is by category. App hosting, web hosting and the one-click lines (WordPress, Ghost, Strapi) default to the 30-day mode, because a website or an API is something you judge over a couple of weeks of edits and deploys. Game servers and databases default to the 24-hour mode, because whether a game runs well for your group is something you find out in an evening. The mode can be set differently for a particular plan, so read the button rather than assuming. There is also a cap on how many trial servers can exist at once. If it is full, starting one fails with "There is no room for a new trial right now. Please try again later." That is a capacity answer, not a judgement about your account - try again later the same day. #### Starting a trial: the /try link and what happens next Every "Try free" button is a plain link to the panel at an address of the form `https://panel.renode.space/try/`, where `` is the plan's number. Opening that link creates nothing. Link previews in chat apps and browser prefetchers open links nobody clicked, and a server should not appear because a URL was pasted into Discord. The link only decides where you go next. What happens depends on whether you are signed in: 1. Signed out: the panel remembers which plan you clicked and sends you to the login page. Sign in, or register from there. After signing in - including with a social sign-in, or after registering in the same browser - you land back on the same plan. 2. Signed in: you go straight to the trial page for that plan. 3. If your email is not verified yet, the page tells you so and offers "Resend verification email". A trial needs a verified address. 4. The dialog, "Start your free trial", shows the plan, the length, the hold period, "One free trial per account." and "Trial servers cannot use a renode.space address." Press **Start free trial**. 5. The panel builds the server. The clock starts when the trial starts, not when you first log in to the server. That last point matters for a handful of games. CS2 and Unturned need a Steam game-server token, FiveM a Cfx.re key, Don't Starve Together a Klei token, BeamMP an auth key, and Arma 3, DayZ, Project Zomboid and 7 Days to Die a Steam login. On those, the server is built at once but the install waits on the Setup tab until you supply the credential. On a 24-hour trial, have the token ready before you press start - our posts on [Steam game-server tokens](https://www.renode.space/blog/steam-game-server-tokens-gslt) and [the BeamMP auth key](https://www.renode.space/blog/beammp-keymaster-auth-key) cover getting one. If the start is refused, the message says why in one sentence. The ones you can act on: ```text Verify your email address to start a free trial. You have already used your free trial. This plan has no free trial. There is no room for a new trial right now. Please try again later. ``` #### The 24-hour mode The 24-hour mode is the simple one. The server runs for 24 hours from the moment the trial starts. Two hours before the end you get an email. At the end the server is suspended and enters a 7-day hold: it is stopped, nothing runs, but every file is still on the disk. The bar on the server page changes to "Trial ended. Your files are kept until" a date, with a count of the days left. Twenty-four hours before deletion you get a second email, the one with the buy button. At the end of the hold the server is deleted, and with it its backups. ```diagram title: A 24-hour trial from start to deletion start = Start free trial | server built run = Running | 24 hours hold = Suspended | files kept 7 days paid = Paid plan | same server gone = Deleted | backups included start -> run run -> hold : time runs out run -> paid : pay any time hold -> paid : pay during hold hold -> gone : no payment ``` The useful thing about the hold is that you do not have to decide inside the 24 hours. If you spent the evening setting up a world, got everyone connected, and then went to bed, you have a week to come back and pay, and the world is where you left it. #### The 30-day mode and the daily Renew The 30-day mode is where people get confused, so here it is exactly. The trial lasts 30 days in total, but the server does not run for all of them by itself. Every 24 hours it pauses: it is suspended and stops answering. You press **Renew** on the server page and it runs for another 24 hours. The pauses happen inside the 30 days and never extend them. The reason is honest enough to state plainly. A month of a server running unattended is a free month with no reason to come back. A trial you renew each day is a trial you are actually using, and it is the point where the panel can tell you how long is left. The details that decide whether you get caught out: - **When Renew works.** Once the server has paused, or in the last 2 hours before the next pause. Pressing it at nine in the morning for a pause due at eleven at night does nothing useful, so the button waits. The bar above the server shows "Pauses in", then "Renew opens in", and then the button itself, "Renew 24 h". - **No reminder per pause.** There is no email for each daily pause - thirty mails in a month is how mail gets filtered as spam. The one email is 2 hours before the 30 days run out. - **The last day is not longer.** The next pause is either 24 hours away or the end of the trial, whichever is sooner. - **Abandoning it.** A 30-day trial left paused for 7 days without a renew goes to the hold early, exactly as if it had ended. - **After the 30 days.** The same 7-day hold as the 24-hour mode, the same deletion email 24 hours before the end, then deletion. While a 30-day trial is paused, the server is stopped. A website on it is down and a bot on it is offline until you renew. That makes the 30-day mode a fair test of how a site or an API behaves, but not a place to run something people depend on overnight. Renewal is the owner's job: a subuser on the server sees "Only the owner can buy or renew this trial." #### Keeping the server when you pay When you pay, the trial is converted, not replaced. It is the same server - the same files, the same database contents, the same address and port. The point of converting rather than building fresh is that someone who has spent a week on a site should not lose it on the day they buy it. You pay through the normal renewal paths: the **Buy now** button on the trial bar or on the trial's card on the billing page, using wallet balance, PayPal, or a bank-transfer invoice. The ordinary renewal arithmetic then gives the server a fresh paid term starting from the moment you pay, with the invoice a renewal produces. If the server was suspended, paying brings it back on the plan's normal settings. A bank transfer takes longer than a click, so the panel does not delete a held trial while an invoice for it is still pending. A trial only converts to the plan it is on, and that plan is the smallest tier. If the trial showed you the server needs more memory, pay for it and then change plan: changing plan does not rebuild the server, so the files stay where they are. Our post on [when to upgrade your plan](https://www.renode.space/blog/when-to-upgrade-your-plan) covers how to read the numbers before you do. > [!WARNING] Deletion at the end of the hold is a real deletion. The server goes, its backups go with it, - do not count on getting it back. If you want the files but not the plan, download them during the hold. #### The limits a trial runs under A trial runs at its plan's size and has the same panel, but a free server attracts a particular kind of user, so there are three rules a paid server does not have. ##### No renode.space subdomain Trial servers are refused a name under renode.space. The name is the company's to hand out, and a free trial is the one place it is not. For a game server you connect by address and port, which is what most players do anyway. For a site on an app or web trial, point an A record for a domain you own at the address the panel shows - see [your domain and its certificate](https://www.renode.space/blog/your-domain-and-its-certificate) - or test on the bare address until you pay. ##### The CPU guard A trial server that sits at 90% or more of its own CPU limit for ten minutes in a row is killed and flagged to our staff. The threshold is against the plan's own share, not the machine, and ten minutes is deliberate: a game generating a world or a build compiling spikes for a minute or two, a miner runs flat out for ever. Killed means the process is stopped, not that the trial is suspended. You can start it again, and a person reads the flag and decides whether anything else should happen. If a legitimate workload trips it - a big build on a small app tier, say - that is information too: the smallest plan cannot carry it, and on a paid plan it would be slow, not stopped. A server at 100% of its CPU is slow, never grounds for suspension on a paid plan. ##### Pauses are not crashes The panel watches every server for crashes and acts on repeated restarts. A trial pause is the panel stopping the server on purpose, and it is excused exactly as a restart you asked for is, so thirty daily pauses do not count as thirty crashes. #### What to test during a trial A trial is only useful if at the end you can answer "would this host do the job". On any host, these are the things worth checking, roughly in order of how often they decide the question. ##### On a game server (24 hours) 1. **Does it start clean.** Read the console from the first line. A server that starts with warnings about its own configuration on a host's default install tells you something. Our guide to [reading the console](https://www.renode.space/blog/reading-the-console) covers what matters. 2. **Can everyone connect.** Get the whole group on, not just you. Most connection trouble is ports and versions - [why players cannot connect](https://www.renode.space/blog/why-players-cannot-connect-to-your-server) walks through it. 3. **What the latency looks like from where your players are.** On RE:NODE the Console tab has an Average Ping figure measured from 12 countries when you press "Test now", and a Hops count traced from our side. Your players' own numbers matter more; ask each of them. 4. **What memory does under load.** Watch the memory graph while everyone is on and the world is busy. If it rides near the plan's limit on the smallest tier, you already know which tier you would buy. 5. **Can you get your files in and out.** Upload a mod or a world over SFTP, download a backup. If a host makes your own files hard to reach on day one, it will not be easier on day ninety. For the memory question, a rough guide by game is in [how many players fit on a server](https://www.renode.space/blog/how-many-players-fit-on-a-server). The trial will not always be the right size for a full group, and that is the point of watching the graph. ##### On an app or website (30 days) You have time, so test the things that only show up over days: - **Deploys.** Link a GitHub repository and push a change. The app lines pull on start and can deploy on push; see [deploying a Node app from GitHub](https://www.renode.space/blog/deploy-a-node-app-from-github) and the [deploys guide](https://www.renode.space/guides#deploys). - **Your real stack.** Connect the database you would actually use, not a toy. - **Restarts.** Every daily pause is a stop and a start. If your app does not come back cleanly after a restart, you will find out on day two instead of in production. - **Backups.** Take one and restore it. A backup nobody has restored is a hypothesis - [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) is the long version. A quick way to check the SFTP side from your own machine, with the host, port and username copied from the server's SFTP details in the panel: ```bash $ sftp -P @ sftp> ls sftp> get -r config ./config-backup ``` If that works on day one, moving off the host later is a download, not a negotiation. ##### On a database (24 hours) Connect from where the application will run, with the generated credentials, and run a real query against real-sized data. Check that your client and driver are happy with the engine version. Twenty-four hours is enough to find out whether the connection string works and whether import is painless; it is not enough to judge performance under months of growth, so be realistic about what the day can tell you. #### Common problems and their answers Most trouble with trials falls into a few cases. - **"You have already used your free trial" on a new account.** The rule is one per account and per email, and the email is normalised: a `+tag` is ignored on every provider, and for Gmail the dots in the name are ignored too. A deleted account still counts. This is deliberate. - **"This plan has no free trial."** You followed a link to a plan other than the smallest tier, or one with trials off. Go back to the plan list and use the button that is there. - **The trial page keeps asking for verification.** Check spam for the verification mail, then use "Resend verification email". The trial cannot start until the address is confirmed. - **The server stopped and the bar says "Paused".** That is the 30-day mode's daily pause. Press Renew. - **The server stopped and nothing says why.** If you were running something that held the CPU at its limit for ten minutes, the CPU guard killed it. Start it again; if it happens again, the workload does not fit the smallest tier. - **A teammate cannot renew or buy.** Only the server owner can. - **You paid but the server is still suspended.** A bank transfer converts the trial when it clears, not when you send it. Balance and PayPal payments convert it straight away. If it is still stuck, open the Chat panel from the server header - it works on a suspended server. #### FAQ ##### Do I need a credit card to start a free trial? No. A trial needs an account with a verified email address and nothing else. Nothing is charged when it ends; the server is suspended, held for 7 days, and then deleted unless you pay. ##### Can I have a free trial on more than one game or plan? No. It is one trial per account, ever, across every line. Pick the plan you are most likely to buy. If you want to compare two games, use the trial on the one with more unknowns and read the plan specs for the other. ##### Why is my 30-day trial stopping every day? Because the 30-day mode pauses every 24 hours by design and waits for you to press Renew. The 30 days are counted from the start whether or not the server was running, so a pause costs you running time, not trial length. ##### Will I lose my world or my site when I upgrade from the trial? No. Paying converts the trial server in place, so the world, the files and the address are the ones you already have. If you then change to a bigger plan, that does not rebuild the server either. ##### What happens if I forget to pay before the trial ends? The server is suspended with its files intact for 7 days, and you get an email 24 hours before it is deleted. Paying at any point in that week brings it back as a paid server. After the week, it and its backups are gone. ##### Can I use my own domain on a trial? Yes, a domain you own can be pointed at a trial server. What a trial cannot have is a renode.space subdomain. Plans with a free trial carry a "Try free" button with the length on it. No card, one per account, and paying keeps the same server and files. [Find a plan to try](https://www.renode.space/game-servers) --- ### SteamCMD errors and fixes: a reference for server admins Published 2026-10-15 by RE:NODE Team. https://www.renode.space/blog/steamcmd-errors-and-fixes Most SteamCMD failures come down to five causes: the login does not own the app, the disk is full, the user cannot write to the folder, the network dropped mid-download, or Steam's cached data about the app is stale. The error text names one of these, but usually in a way that points somewhere else. This page takes the messages people actually search for, says what each one means, and gives the fix in the order worth trying. It assumes you already know the basic install line. If you do not, [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) covers app ids, anonymous login, `validate`, beta branches and update scripts. This post is about what to do when that line fails. #### How to read a SteamCMD failure A failed `app_update` ends with one of two kinds of line, and they tell you different things. ```text ERROR! Failed to install app '896660' (Disk write failure) Error! App '896660' state is 0x202 after update job. ``` The first kind has a reason in brackets. That reason comes from the Steam client's own content system and is the closest thing to a diagnosis you get. The second kind only reports the state the app was left in, as a hexadecimal set of flags. It tells you the update stopped, not why it stopped. Both are covered below. Before you start changing things, get three facts: 1. **The full output, not the last line.** Scroll up. A login that quietly failed, or a warning about the install directory, is often fifty lines above the error everyone quotes. 2. **Free space and inodes on the volume you install to.** `df -h /srv/valheim` and `df -i /srv/valheim` on Linux. A full inode table produces the same error as a full disk while `df -h` shows plenty of room. 3. **Who owns the install directory, and who is running SteamCMD.** `ls -ld /srv/valheim` and `whoami`. If they differ, you have probably found the problem. SteamCMD also keeps logs of its own under its Steam directory - on Linux usually `~/Steam/logs/`, on Windows the `logs` folder next to `steamcmd.exe`. `content_log.txt` in that folder records each update job in more detail than the console shows, including which file failed to write. Exact paths vary with how SteamCMD was installed (a distribution package puts things in a different home than the tarball), so search for the file if it is not where you expect. One setting changes what you see. In a script run with `+runscript`, `@ShutdownOnFailedCommand 1` makes SteamCMD stop at the first error. Without it, a failed `app_update` is followed by `quit`, the process exits, and a wrapper that only checks the exit code reports success. If your errors are being discovered by players rather than by you, fix that first. The habit of grepping for `Success! App 'X' fully installed.` is explained in the main SteamCMD post, and [reading the console](https://www.renode.space/blog/reading-the-console) covers the general skill of telling the cause from the noise. #### Missing configuration ```text ERROR! Failed to install app '90' (Missing configuration) ``` This is the most searched SteamCMD error and the least specific. It means SteamCMD could not get a usable configuration for that app - the information about which depots to download for this platform and this login. The causes, roughly from most to least common: - **A stale app info cache.** SteamCMD keeps cached metadata for every app in an `appcache` folder inside its own directory. When that cache disagrees with what Steam currently publishes, the install fails before it downloads anything. - **The wrong app id.** Passing a game's id where the dedicated server tool's id belongs, or a typo that lands on an unrelated app. - **A login with no access to that configuration.** The app may report this rather than `No subscription` when the login cannot see its configuration. - **A platform with no depots.** Some apps report a missing configuration rather than `Invalid platform` when there is simply no build for your operating system. - **Something transient on Steam's side.** It happens, and a retry ten minutes later works. Work through the fixes in order: 1. Run the same command again. Not as a superstition - a first run that refreshed the app info cache often succeeds on the second attempt. 2. Check the app id against the server tool's id, not the game's. Valheim's server is `896660`, the game is `892970`, and only the first installs. 3. Stop SteamCMD and delete its `appcache` folder (not `steamapps`, and not your install directory). The next run rebuilds it from scratch. 4. Try a forced platform if the app only ships for another OS - see below. 5. If it needs an owning account, log in with one. ```bash $ cd ~/steamcmd $ rm -rf appcache $ ./steamcmd.sh +force_install_dir /srv/hlds +login anonymous \ +app_update 90 validate +quit ``` ##### The Half-Life Dedicated Server special case App `90` - the old GoldSrc server used by Counter-Strike 1.6 and other Half-Life mods - is famous for this error. It has been unreliable for years, and the long-standing community workaround is to tell SteamCMD which mod you want with `app_set_config` and then run `app_update 90 validate` several times until it reports success: ```bash $ ./steamcmd.sh +force_install_dir /srv/cs16 +login anonymous \ +app_set_config 90 mod cstrike \ +app_update 90 validate +app_update 90 validate +quit ``` Behaviour has changed over time and differs by mod, so treat this as the thing to try rather than a guarantee. If you only need a running CS 1.6 server, a prepared install is less painful than fighting app `90` - the [Counter-Strike 1.6 server guide](https://www.renode.space/blog/counter-strike-1-6-server-guide) covers what the server needs once the files are in place. ##### Invalid platform ```text ERROR! Failed to install app '556450' (Invalid platform) ``` This one is unambiguous: the app has no build for the operating system SteamCMD is running on. The Forest's dedicated server is the usual example, because it only ships a Windows binary. On Linux you can download the Windows build anyway and run it under Wine: install-forest.txt: ```text @ShutdownOnFailedCommand 1 @sSteamCmdForcePlatformType windows force_install_dir /srv/theforest login anonymous app_update 556450 validate quit ``` The setting has to come before `app_update`, and it applies to the rest of that run. Running a Windows server on Linux is a separate decision with its own costs; [Linux vs Windows game servers](https://www.renode.space/blog/linux-vs-windows-game-servers) lists which games need it. #### No subscription ```text ERROR! Failed to install app '223350' (No subscription) ``` Clearer than it looks: the logged-in identity does not hold a licence for that app. There are three ways to get there. - **Anonymous login against an app that refuses it.** DayZ (`223350`), Arma 3 (`233780`) and Project Zomboid's server are the common ones. You need a Steam account that owns the game. - **The right account, the wrong app.** An account that owns the game but is installing something it has no licence for - often the result of a mistyped id. - **A login that did not actually happen.** If the `login` step failed, every command after it runs as nobody, and an app that needs an owner reports `No subscription`. Scroll up and look for the login line ending in `OK`. The fix is to log in as an account that owns the game, interactively the first time so Steam Guard can be satisfied, and then keep using that account in scripts. Use a spare account that holds nothing but the game: a server is a poor place to keep the credentials of the account you buy things with. On RE:NODE, games that need your own Steam login - Arma 3, DayZ, Project Zomboid and 7 Days to Die among them - are created immediately and then wait on the Setup tab until you enter the credentials. They are stored as typed, which is why the advice about a spare account applies there too. #### Disk write failure and Missing file permissions ```text ERROR! Failed to install app '896660' (Disk write failure) ERROR! Failed to install app '896660' (Missing file permissions) ``` These are two different messages for overlapping problems, and a permissions problem can surface as either. Check these four things, in this order: | Check | Command or place | What fixes it | | --- | --- | --- | | Free space | `df -h ` | Free 20-30% above the install size | | Free inodes | `df -i ` | Delete small files, old logs | | Ownership | `ls -ld ` | `chown -R` to the SteamCMD user | | Read-only mount | `mount`, kernel log | Fix the filesystem, then validate | Space is the most common cause, and it is less obvious than it sounds. SteamCMD stages downloaded chunks on the same volume before committing them, so an update needs room for the changed files on top of the existing install. A disk with 2 GB free can fail a 1.5 GB update. Old Workshop content, crash dumps and rotated logs are the usual things filling it; [what to do when the disk is full](https://www.renode.space/blog/game-server-disk-space-full) has a cleanup list. Ownership is the second. The classic route is running SteamCMD once as root "to get it working", which leaves root-owned files the service user cannot replace on the next update. Fix it once: ```bash $ sudo chown -R steam:steam /srv/valheim /home/steam/steamcmd $ sudo -u steam /home/steam/steamcmd/steamcmd.sh \ +force_install_dir /srv/valheim +login anonymous \ +app_update 896660 validate +quit ``` Then never run it as root again. [File permissions and ownership](https://www.renode.space/blog/game-server-file-permissions-and-ownership) goes through the general case, including servers that write files as a different user from the one that installs them. On Windows the usual causes are an install directory under `C:\Program Files` without elevated rights, a file locked because the server is still running, and antivirus quarantining a freshly written executable mid-update. Stop the server before updating, install outside `Program Files`, and exclude the install directory from real-time scanning if the failures always land on `.exe` and `.dll` files. > [!WARNING] > Do not try to fix a disk write failure by deleting `steamapps` inside your install directory. That removes the app manifest and Workshop records, and on some games it sits next to save data. Free space elsewhere first, then run the update with `validate`. #### State codes: 0x202, 0x402, 0x602 and friends ```text Error! App '740' state is 0x602 after update job. ``` The hexadecimal number is a set of flags describing the app's state, added together. Knowing what the bits mean turns a mystery code into a plain sentence. These are the flags you will see in these errors: | Flag | Meaning | | --- | --- | | `0x2` | Update required | | `0x4` | Fully installed | | `0x200` | Update paused | | `0x400` | Update started | Read the codes against that table: - **`0x202`** = update required plus update paused. The job stopped and the app still needs the update. In practice this is overwhelmingly a disk space problem; check `df -h` before anything else. - **`0x402`** = update required plus update started. The job began and did not finish. Network interruptions and timeouts are the usual cause. - **`0x602`** = required, paused and started. The update got going and then stopped. It is the generic "something went wrong mid-update" state: disk space, permissions, a dropped connection, or a process that was killed. - **`0x6`** = update required on an installed app, with no update in progress. Usually seen when a job never got as far as starting - look for a login or app info failure earlier in the output. None of these codes contains the reason. That is why the three checks at the top of this page - space, ownership, network - are the answer to all of them, and why `content_log.txt` is worth opening when the obvious checks pass. The same flags live in the app manifest as a decimal number. Open `steamapps/appmanifest_.acf` in the install directory and look for `StateFlags`. A healthy install reads `"StateFlags" "4"`. Anything else means SteamCMD considers the install unfinished, and the next `app_update` with `validate` is the right move. Progress lines during a download use a different set of codes, which confuses people who search for them: ```text Update state (0x5) verifying install, progress: 12.40 (512 / 4130) Update state (0x61) downloading, progress: 45.22 (1868 / 4130) Update state (0x101) committing, progress: 98.10 (4052 / 4130) ``` These are phases, not errors. The word after the code is the part to read. A progress line that sits on the same number for minutes during `downloading` is a network or disk throughput problem; during `committing` or `verifying` on a slow disk it is often just slow, and interrupting it is how you get a `0x602`. #### Timeouts, connection failures and login errors Network problems show up in a few distinct shapes. **SteamCMD cannot update itself.** On first launch, or after a long gap, the bootstrapper checks for its own update before doing anything. If it cannot reach Steam's content servers it stops there, with a message along the lines of `Steam needs to be online to update`. Check DNS resolution on the host, outbound HTTP and HTTPS through any firewall, and a proxy if your network requires one. A host with broken IPv6 routing but a working IPv4 path is a frequent culprit. **Login hangs or fails.** The login line ends in `OK` or `FAILED` with a reason. The ones you will meet: ```text Logging in user 'spareaccount' to Steam Public...FAILED (Invalid Password) Logging in user 'spareaccount' to Steam Public...FAILED (Rate Limit Exceeded) Logging in user 'spareaccount' to Steam Public...FAILED (Two-factor code mismatch) ``` `Invalid Password` is what it says, though check for a shell eating a special character if you passed it on the command line. `Rate Limit Exceeded` means too many attempts in a short time; the only fix is to stop and wait, and every retry pushes the window out. `Two-factor code mismatch` means a Steam Guard code was wrong or expired, which also happens when the host's clock has drifted. Running one interactive login by hand, approving it, and letting SteamCMD cache the credential is how unattended runs avoid all three. **Downloads that time out.** Large app updates occasionally stall, and Workshop downloads time out far more often: ```text ERROR! Timeout downloading item 463939057 ``` Big Workshop items routinely need two or three attempts on a slow link. Retry the same item before assuming anything is wrong. If the same item fails every time, delete `steamapps/workshop/appworkshop_.acf` and the item's folder, then fetch it again. A different message, `ERROR! Download item 463939057 failed (Failure).`, more often means the item is private, removed, or needs an owning login. [Steam Workshop mods on dedicated servers](https://www.renode.space/blog/steam-workshop-mods-on-dedicated-servers) covers the Workshop side in depth. #### Linux: 32-bit libraries and steamclient.so SteamCMD on Linux is a 32-bit program. On a fresh 64-bit system without 32-bit support, the failure is confusing because the file it complains about plainly exists: ```text steamcmd.sh: line 38: /home/steam/steamcmd/linux32/steamcmd: No such file or directory ``` "No such file" here refers to the 32-bit loader the binary needs, not the binary itself. The other common form names a library: ```text linux32/steamcmd: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory ``` Both are fixed the same way: ```bash # Debian and Ubuntu $ sudo dpkg --add-architecture i386 $ sudo apt update $ sudo apt install lib32gcc-s1 # lib32gcc1 on older releases $ sudo apt install lib32stdc++6 # if libstdc++.so.6 is still missing # RHEL, Rocky, AlmaLinux $ sudo dnf install glibc.i686 libstdc++.i686 ``` Package names change between distribution releases, which is why guides disagree. If `apt` cannot find `lib32gcc-s1`, you are on an older release that calls it `lib32gcc1`. A related problem appears after a successful install, when the game server starts rather than SteamCMD: ```text [S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.so. ``` The game server is looking for `steamclient.so` in `~/.steam/sdk64/` (or `sdk32` for a 32-bit server) and not finding it. SteamCMD ships the library in its own `linux64` and `linux32` folders. Linking it into place is the standard fix: ```bash $ mkdir -p ~/.steam/sdk64 $ ln -sf ~/steamcmd/linux64/steamclient.so ~/.steam/sdk64/steamclient.so ``` Some servers instead expect the file next to their own executable, and their start scripts set `LD_LIBRARY_PATH` to find it. If a game's own start script does that, use it rather than launching the binary directly. #### Messages you can ignore SteamCMD is noisy, and several lines look like errors on every run without meaning anything. Knowing them saves an evening: - `Redirecting stderr to '.../logs/stderr.txt'` - informational. - `ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".` - printed on early runs, harmless. - `dlmopen steamservice.so failed: steamservice.so: cannot open shared object file` - SteamCMD does not need it; printed every run on Linux. - `Unable to determine CPU Frequency. Try defining CPU_MHZ.` - cosmetic, common in containers and VMs. - `Please use force_install_dir before logon!` - not ignorable in the same way. Current builds warn when `force_install_dir` comes after `login`, and the install may not go where you meant. Move it first. The rule of thumb: if the run ends with `Success! App 'X' fully installed.` or `Success! App 'X' already up to date.`, the lines above it were noise. #### When validate fixes it, and when it does not `validate` re-hashes every file in the install against Steam's manifest and replaces what does not match. It fixes: - an install left half-written by a full disk, a killed process or a dropped connection - the `0x602` family; - a server that crashes at startup right after an update that "succeeded"; - files corrupted on disk. It does not fix: - anything on the list above about logins, licences, platforms or app ids - it runs after those checks pass; - a disk that is still full, or a directory the user still cannot write to; - a broken mod, plugin or config file you added, since those are not in the manifest. Use [what to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) instead; - a version mismatch with clients. That is a branch question, covered in [version pinning and rollbacks](https://www.renode.space/blog/game-server-version-pinning-and-rollbacks). Also remember that it reverts any file that shipped with the app, including a start script or default config you edited in place. Keep a copy. When `validate` itself keeps failing on the same app, the last resort before a clean reinstall is to delete `steamapps/appmanifest_.acf` in the install directory and run the update again. SteamCMD then has no record of the install and re-downloads everything, keeping files that are not part of the app. Back up saves first. On a container-based host there is one more cause to name. If a server hits its memory limit during an install or update, the container is stopped rather than left to swap - on RE:NODE it restarts clean - and what remains is a half-written install with a `0x602`-style state. Re-running the update with `validate` repairs it. If it keeps happening, the plan is too small for that game's install step; [why your game server keeps restarting](https://www.renode.space/blog/why-your-game-server-keeps-restarting) explains how to tell. The panel console shows SteamCMD's output line for line and graphs disk use against the plan's limit, which is usually enough to see which of the causes above you hit; the [console guide](https://www.renode.space/guides#console) shows where. #### FAQ ##### Is "Missing configuration" a problem with my server? Usually not. It means SteamCMD could not get a usable configuration for that app from Steam - most often a stale app info cache, the wrong app id or a transient failure. Retry once, check the id is the dedicated server's rather than the game's, then delete the `appcache` folder in SteamCMD's directory and run again. ##### What does "state is 0x202 after update job" mean? The update stopped while the app still needs it: flag `0x2` is "update required" and `0x200` is "update paused". In practice it is almost always a disk that ran out of space during the download. Free space on the install volume, leave 20-30% headroom, and run the update with `validate`. ##### Why does SteamCMD say "No subscription" when the server is free? Because the server tool for that game is not free to anonymous logins. DayZ, Arma 3 and Project Zomboid need a Steam account that owns the game. The same message appears if the login silently failed earlier in the output, so check that the login line ended in `OK`. ##### Should I run SteamCMD as root to stop permission errors? No. It makes the next update fail instead, because the files it writes belong to root and the service user cannot replace them. Run SteamCMD as the same ordinary user that runs the server, `chown` the install directory to that user once, and the permission errors stop. ##### Can I safely delete SteamCMD's appcache folder? Yes. It is a cache of app metadata that SteamCMD rebuilds on the next run, and it holds no game files, saves or credentials. Do not confuse it with `steamapps` inside your install directory, which holds the app manifest and Workshop records. ##### How do I fix SteamCMD on a fresh 64-bit Linux install? Enable 32-bit packages and install the 32-bit C and C++ runtime: on Debian and Ubuntu, `dpkg --add-architecture i386` followed by `apt install lib32gcc-s1` (or `lib32gcc1` on older releases), and `lib32stdc++6` if it still complains. On RHEL-family systems, `glibc.i686` and `libstdc++.i686`. On RE:NODE the SteamCMD install runs when the server is created, usually inside a minute of payment clearing, with app ids and launch values exposed on the Startup tab. Games that need your own Steam login wait on the Setup tab, and the console shows every line SteamCMD prints, next to graphs of disk use against your plan's limit. [Browse game servers](https://www.renode.space/game-servers) --- ### SteamCMD login and Steam Guard: anonymous vs account Published 2026-10-15 by RE:NODE Team. https://www.renode.space/blog/steamcmd-login-and-steam-guard Most dedicated servers install with `+login anonymous` and need nothing from you. A handful - DayZ and Arma 3 are the ones you will meet first - refuse an anonymous session, and SteamCMD then wants a real Steam username and password, answers a Steam Guard challenge once, and caches a login token so later updates run unattended. That token, and the password you typed to get it, end up on the server. So the whole security story fits in one sentence: use a spare Steam account that owns the game and nothing else, and treat the machine that runs SteamCMD as somewhere that account's credentials now live. The rest of this post is the detail: which servers need an account, what each Steam Guard prompt looks like and how to answer it, where the cached credential is stored and how long it lasts, how to set up the spare account properly, and what the login errors mean. The basics of SteamCMD itself - install, `force_install_dir`, `validate`, scripts - are in [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained), and this post does not repeat them. #### What the login actually decides SteamCMD always logs in before it downloads anything. The login is not about the server you are going to run - a game server never uses this session once it is running. It decides one thing: which licences the download session holds. - **Anonymous** is a session with no account behind it. It holds a licence for every app the publisher has marked as free for anonymous download, which covers most dedicated-server tools. No password, no Steam Guard, nothing stored. - **An account login** holds whatever that account owns, plus the free tools. It is needed when the publisher has restricted the server tool, or its Workshop content, to accounts that own the game. Two consequences follow, and both surprise people. First, the credential is only needed at install and update time. The running DayZ or Arma 3 server does not log in to Steam with your account; it is SteamCMD, run before the server starts, that does. Second, the credential is needed again on every update, which is why it is cached rather than typed once and forgotten. A server that updates on every restart is a server that logs in to Steam with that account every restart. The login is also a separate thing from a game server login token. A [GSLT](https://www.renode.space/blog/steam-game-server-tokens-gslt) is what a running server presents so that Steam lists it in the browser; it is created on a web page and is never typed into SteamCMD. People mix the two up because both are "a Steam credential the host asks for", but one installs the files and the other identifies the running server. A few games need both. #### Which servers need a real account There is no flag you can read in advance that says "this one refuses anonymous". You find out from the publisher's documentation, from the Valve developer wiki's dedicated servers list, or from SteamCMD itself, which answers an anonymous attempt on a restricted app with `No subscription`. | Game | Server tool needs an account | Workshop needs an owning account | | --- | --- | --- | | DayZ | Yes, one that owns DayZ | Yes | | Arma 3 | Yes | Yes | | Project Zomboid | Varies - see below | Mods download through the server | | 7 Days to Die | Usually anonymous | Mods are installed as files | | Most others (Valheim, CS2, Palworld...) | No | Depends on the game | DayZ is the clear case. The `DayZ Server` tool (app `223350`) will not install for an anonymous session or for an account that does not own the game, and its Workshop items are fetched against the game's app id, `221100`, which needs the same owning account. [DayZ server and mods](https://www.renode.space/blog/dayz-server-and-mods) covers the rest of that install. Arma 3 is the case where sources disagree in an instructive way. Valve's list marks the server tool (`233780`) as not available anonymously, and Bohemia's own server documentation tells you to log in with a real username and suggests a separate account for the job. Bohemia also describes the server package as free, so whether the account has to own Arma 3 just to fetch the server has varied by time and by who you ask. Workshop mods are a different matter: `workshop_download_item 107410 ` needs an account that owns Arma 3. Since nearly every real Arma 3 server runs mods, plan on an owning account either way. [Arma 3 server and mods](https://www.renode.space/blog/arma-3-server-and-mods) has the full mod workflow. Project Zomboid and 7 Days to Die are the grey zone. Their server tools have been widely installed with `login anonymous` for years, yet hosts and guides differ on whether a login is wanted, and publishers can change an app's access without announcement. The practical test is quick: try anonymous first. If it installs, you need no account for the server itself. If you get `No subscription`, you do. [SteamCMD app IDs and beta branches](https://www.renode.space/blog/steamcmd-app-ids-and-beta-branches) has the server and game ids for thirty titles if you are unsure which number to test. > [!NOTE] > Passing the game's app id instead of the server's to `app_update` with an account that owns the game does not fail. It downloads the full game client into your server folder - many gigabytes of textures and sound, and nothing that starts as a server. If an install with a real account is suspiciously large, check the id first. #### Logging in for the first time The first login with an account should always be interactive - you, at a terminal, able to read what SteamCMD asks. Start SteamCMD with no arguments and log in at its prompt, so the password never appears on a command line: ```bash $ ./steamcmd.sh Steam> login myserveraccount password: ``` What happens next depends on how Steam Guard is set up on the account, covered in the next section. Once the login succeeds you will see a line confirming it and the `Steam>` prompt returns. From there, install as normal: ```text Steam> force_install_dir /srv/dayz Steam> app_update 223350 validate Steam> quit ``` That one interactive session does two jobs: it satisfies Steam Guard, and it leaves a cached credential behind. Every later run - a cron job, a restart script, a panel update - can then log in with the username alone: ```bash $ ./steamcmd.sh +force_install_dir /srv/dayz \ +login myserveraccount \ +app_update 223350 +quit ``` No password, no code. SteamCMD finds the cached credential for that username and uses it. If it cannot find one, it says so and either prompts (in an interactive run) or fails (in a script with `@NoPromptForPassword 1`), which is exactly what you want from an unattended job: a loud failure rather than a hang. Avoid the shortcut of `+login user password` on the command line. It works, but the password lands in your shell history, in the output of `ps` for anyone else on the machine while SteamCMD runs, and often in whatever logs the job's output. In a container it is worse: a password passed as an environment variable is readable by anyone who can inspect the container. [Environment variables and secrets](https://www.renode.space/blog/environment-variables-and-secrets) covers why that is a weaker hiding place than people assume. #### Steam Guard: email codes, mobile codes and approvals Steam Guard is Steam's second factor, and SteamCMD meets it the same way the desktop client does when it signs in from a new device. There are three states an account can be in, and each produces a different experience. ##### Email Steam Guard The account has Steam Guard but no mobile authenticator. On the first login from a new machine, Steam emails a short code to the account's address, and SteamCMD asks for it: ```text Steam Guard code: ``` Type the code from the email. The code is tied to that login attempt, so request it and use it in one go; an old code from an earlier attempt is rejected. If the email never arrives, check the spam folder before retrying - repeated attempts are how you end up rate-limited. ##### Mobile authenticator The account has the Steam Mobile app set up as its authenticator. SteamCMD asks for the rotating code from the app: ```text Two-factor code: ``` The code is five characters and changes every 30 seconds. Type it promptly; a code that rolled over while you were typing produces a mismatch, and you simply try again with the new one. Recent Steam builds can also offer approval on the phone instead of a typed code, the way the desktop client does - if SteamCMD tells you to confirm the sign-in in the app, do that and it continues. Whether you see the prompt or the approval depends on the SteamCMD build, so read what it prints rather than assuming. SteamCMD also accepts the code as a third argument to `login` (`login user password code`), which is how people answer Steam Guard from a script. It works, but it puts the password on the command line, so use it only for a one-off from a terminal you control, never in a file. ##### Steam Guard turned off No prompt at all. This is the setup people reach for after the first frustrating Steam Guard loop, and it is the wrong fix. An account with Steam Guard off is protected by its password alone, and the password is precisely the thing you have just typed into a server. Leave Steam Guard on; it only asks once per machine. ```diagram title: First login versus every later update first = First run | interactive, by hand guard = Steam Guard | email or mobile code cache = Cached credential | config.vdf later = Later updates | username only steam = Steam | licences for the session first -> guard : password guard -> cache : token saved later -> cache : reads token cache -> steam : login without a code ``` #### Cached credentials: where they live and when they stop working After a successful login SteamCMD stores a login token for that account in its configuration, in `config/config.vdf` under SteamCMD's data directory. On Windows that is the `config` folder beside `steamcmd.exe`. On Linux it depends on how SteamCMD was installed: the Valve tarball and the distribution packages keep their data in different places, commonly under `~/Steam` or `~/.steam`. If you are not sure, search the SteamCMD user's home directory for `config.vdf`. Older builds also left `ssfn` sentry files beside it, which played the same role. What matters about that file: - **It is a credential.** It is not your password, but it lets SteamCMD on that machine log in as the account without one. Anyone who can copy it can, in practice, do the same - which is why it belongs to a spare account and nowhere else. - **It belongs to the user that ran SteamCMD.** Run the first interactive login as the same Unix user that the cron job or service uses. Logging in as yourself and then running updates as a `steam` service user is the most common reason a cached login "does not work". - **In a container it must persist.** If SteamCMD runs inside a container whose filesystem is thrown away on restart, the cached credential goes with it, and every start asks for Steam Guard again. Put SteamCMD's config directory on a persistent volume. The cache does not last for ever. It stops working when: 1. **The password changes.** Steam ends existing sessions, and SteamCMD needs the new password and, usually, a fresh Steam Guard challenge. 2. **You deauthorise devices.** "Deauthorize all other devices" on the account's Steam Guard page logs out every machine that holds a cached login, SteamCMD included. That is also the right move if a server holding the credential may have been compromised. 3. **The token simply expires.** Cached logins are long-lived but not permanent. When one lapses, the next unattended update fails at the login step. That third case is the one that bites in production, because it happens at a random time months after setup. An unattended update must therefore be able to fail safely: check for the `Success! App 'X' fully installed.` line rather than trusting the exit code, and start the server on the existing files if the update did not happen. [Automating game server updates](https://www.renode.space/blog/automating-game-server-updates) covers wrapping SteamCMD so that a failed login means a stale server rather than a dead one. > [!WARNING] > Never fix a failing unattended login by writing the password into the update script. The day the cache expires is a day to log in by hand once, not a reason to store the password in plain text for ever. #### Setting up the spare account A spare account is not a nice-to-have here. The password and a long-lived login token sit on a machine that, for a rented server, someone else administers, and that runs mods and plugins written by strangers. If that account is also the one with your library, wallet balance, saved payment cards and fifteen years of friends, all of that is one leak away. Setting one up properly: 1. **Create a new Steam account** with its own email address - a mailbox you use for nothing else. If the email is shared with your main account, compromising the mailbox compromises both. 2. **Buy or gift the game to it** if the server needs an owning account (DayZ, and Arma 3 for Workshop). This costs one copy of the game, and it is the price of keeping your main account off the server. 3. **Do not add a payment method** and do not top up a wallet. Nothing on this account should be spendable. 4. **Turn on Steam Guard.** Email Steam Guard on the dedicated mailbox is fine; the mobile authenticator is stronger. The Steam Mobile app can hold more than one account, so the spare one can live beside your main account on the same phone. 5. **Give it a unique, generated password** from a password manager. It will be typed into a server, so assume it may be seen, and make sure it opens nothing else. 6. **Do not play on it.** The account exists to download files. Keeping it out of play keeps it out of trades, friend requests and the phishing that follows them. A spare account also helps with Workshop downloads for heavily modded servers, because Workshop subscriptions and downloads attach to that account rather than to your personal one. The download mechanics, including what happens when an item is removed from the Workshop, are in [Steam Workshop mods on dedicated servers](https://www.renode.space/blog/steam-workshop-mods-on-dedicated-servers). #### The security risks, stated plainly Typing a Steam login into a server is a trust decision, and it helps to be specific about who can see it afterwards. | Who | What they can reach | | --- | --- | | Anyone on the same machine | Passwords in `ps` output, shell history, logs | | Anyone with file access to SteamCMD's folder | The cached token in `config.vdf` | | The host | Whatever it stores to run SteamCMD for you | | A malicious mod or plugin | Any file the server process can read | | Anyone you send a screenshot to | Whatever was on the screen | The host line deserves the most honesty. Any host that runs SteamCMD on your behalf for a game that needs a login has to hold your credentials in a form it can use, which means it can read them. There is no clever arrangement that avoids this. What differs between hosts is whether they say so. On RE:NODE the games that need your own Steam login - Arma 3, DayZ, Project Zomboid and 7 Days to Die - are created as soon as payment clears, and the install waits on the Setup tab until you enter the credentials there. They are stored as you typed them, and that is the reason this whole post keeps returning to the spare account. The other lines are the ones you control: - **File access is credential access.** A subuser who can browse the server's files may be able to read the cached login. Give staff console access without file access where they do not need files - [subusers and least privilege](https://www.renode.space/blog/subusers-and-least-privilege) shows how to build roles like that. - **Mods run with the server's permissions.** A plugin can read anything the server process can. [Malicious plugins and mods](https://www.renode.space/blog/malicious-plugins-and-mods) covers what that looks like in practice. - **Support conversations leak.** Never paste a password or a Steam Guard code into Discord, a forum or a public channel while asking for help. On RE:NODE a support ticket takes private attachments, which is the right place for anything sensitive. - **Your panel account is the front door.** Whoever can sign in to the panel can see the Setup tab. Turn on [two-factor on your panel account](https://www.renode.space/blog/two-factor-on-your-panel-account) so the Steam login is not one leaked panel password away. If you think the spare account's credentials have been exposed, the response takes five minutes: change the password, use "Deauthorize all other devices", and log in once by hand on the servers that should still have access. Because the account holds nothing but a game licence, that is the full extent of the damage. #### Login errors and what they mean SteamCMD reports login failures on the line that starts `Logging in user`, with the reason in brackets at the end. | Message contains | What it means | | --- | --- | | `Invalid Password` | Wrong password, or a username typo | | `Two-factor code mismatch` | Mobile code expired or mistyped; use the current one | | `Invalid Login Auth Code` | Email Steam Guard code wrong or from an older attempt | | `Account Logon Denied` | Steam Guard wants an email code before it will continue | | `Rate Limit Exceeded` | Too many attempts; stop and wait | | `No subscription` | Logged in, but this identity does not own the app | `Rate Limit Exceeded` is the one to respect. It is triggered by repeated failed logins, typically a script retrying in a loop with a stale password, and every further attempt extends the lockout. Stop whatever is retrying, wait - often an hour or more - and then log in once, by hand, correctly. `No subscription` after a successful login is never a password problem. Either the account does not own the game, or you passed an app id that belongs to something else. For DayZ, confirm the account owns DayZ itself; for an Arma 3 Workshop download, confirm it owns Arma 3 and that you used `107410`, not the server's `233780`. A login that works by hand and fails from cron is almost always the user mismatch described above: the cached credential belongs to whichever user ran the interactive login, and the scheduled job is someone else. #### FAQ ##### Can I install a DayZ server without owning DayZ? No. The DayZ server tool refuses anonymous logins and accounts that do not own the game, and its Workshop mods need the same owning account. Buy a copy on a spare account rather than putting your main account on the server. ##### Do I have to enter a Steam Guard code every time the server updates? No. Steam Guard is answered once per machine. SteamCMD then caches a login token and later runs log in with the username alone. You will be asked again only after a password change, a device deauthorisation, or when the cached login eventually expires. ##### Is it safe to give a host my Steam login? It is as safe as the host, which is why you should only ever give one a spare account. Any host that installs DayZ or Arma 3 for you has to store a usable credential. Choose a host that tells you so, and make sure the account behind it owns nothing you would miss. ##### Should I disable Steam Guard on the spare account to stop the prompts? No. The prompt only appears on the first login from each machine, so disabling Steam Guard saves you one code and removes the only protection left once the password has been typed into a server. Keep it on, ideally with the mobile authenticator. ##### Does the running server use my Steam account? No. The account is used by SteamCMD to download and update files. The running server does not log in with it. If the game also needs a server listing token, that is a separate credential created on Steam's game server account page. ##### How do I make a machine forget the login? Delete the cached credential from SteamCMD's `config/config.vdf`, or, if you do not control the machine any more, use "Deauthorize all other devices" in the account's Steam Guard settings and change the password. Either way the next login on that machine needs the password and Steam Guard again. DayZ, Arma 3, Project Zomboid and 7 Days to Die servers on RE:NODE are created as soon as payment clears, and the install waits on the Setup tab for your Steam login - stored as you type it, so bring a spare account that owns the game. The console shows SteamCMD's output line for line, support tickets take private attachments, and subuser roles let staff work the console without file access. [See DayZ plans](https://www.renode.space/game-servers/dayz) --- ### SteamCMD on Windows: install, scripts and updates Published 2026-10-15 by RE:NODE Team. https://www.renode.space/blog/steamcmd-on-windows SteamCMD on Windows is one zip file: download `steamcmd.zip` from Valve, unpack it into a short path such as `C:\steamcmd`, and run `steamcmd.exe` once with `+quit` so it can update itself. After that, every server install is the same line - `+force_install_dir` with an absolute path, `+login anonymous`, `+app_update validate`, `+quit` - which you move into a script file and call from a batch file, and then hand to Task Scheduler for unattended updates. The Windows-specific parts are where things go wrong: paths with spaces, folders under `Program Files` or your profile, a scheduled task that runs as a different user from the one you tested with, and Defender scanning thousands of small files during every update. This post covers those parts. The arguments themselves, the error table and how app ids work are in [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained), and branch switching is in [SteamCMD app IDs and beta branches](https://www.renode.space/blog/steamcmd-app-ids-and-beta-branches). #### Downloading SteamCMD and the first run There is no installer and nothing to add to the Start menu. Valve publishes a zip containing a single small executable, and that executable downloads the rest of itself. 1. Create a folder for it. `C:\steamcmd` is the convention, and the short path matters later. 2. Download `https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip` and extract `steamcmd.exe` into that folder. 3. Open Command Prompt or PowerShell, change to the folder, and run `steamcmd.exe +quit`. The same three steps from an ordinary (not elevated) PowerShell window: ```text PS> New-Item -ItemType Directory -Path C:\steamcmd PS> Invoke-WebRequest -Uri https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip ` -OutFile C:\steamcmd\steamcmd.zip PS> Expand-Archive C:\steamcmd\steamcmd.zip -DestinationPath C:\steamcmd PS> C:\steamcmd\steamcmd.exe +quit ``` The first run is the self-update. SteamCMD reports that it is checking for updates, downloads its packages, extracts them, and relaunches itself before it gets to `Loading Steam API...OK` and a prompt. On a normal connection this takes a minute or two. The exact lines change between releases, but they look roughly like this: ```text [ 0%] Checking for available updates... [----] Downloading update (...) [----] Extracting package... [----] Installing update... [----] Cleaning up... [----] Update complete, launching Steamcmd... Loading Steam API...OK ``` Let it finish. Interrupting the first run - closing the window, or a scheduled task that times out - leaves a half-unpacked client that fails in confusing ways on the next launch. If that happens, delete everything in the folder except `steamcmd.exe` and run `+quit` again. That is also the standard repair for a SteamCMD that has started crashing on startup after months of working: the bootstrapper rebuilds what it needs from scratch, and nothing you care about lives in those files unless you have been installing servers into the default location (see the next section). SteamCMD checks for its own updates on every launch, not only the first. When Valve has shipped a new client, your next scripted update will spend its first minute updating SteamCMD before it touches the game. Plan timeouts around that. ##### Runtimes the server will want SteamCMD itself needs nothing extra. The servers you download with it often do. Many Windows dedicated servers are built against the Microsoft Visual C++ Redistributable, and a missing one shows up as the server refusing to start with a message about a DLL such as `VCRUNTIME140.dll` or `MSVCP140.dll`. Some older or Unreal-based servers also want pieces of the DirectX runtime. These are per-game requirements, not SteamCMD's, so check the game's own server documentation. Installing the current x64 Visual C++ Redistributable from Microsoft before your first server is a reasonable default on a fresh Windows Server machine, which ships without most of what a desktop picked up from games over the years. #### Where things go: the folder layout After the first run, `C:\steamcmd` holds a few dozen files and folders. The ones worth knowing: | Path | What it holds | | --- | --- | | `steamcmd.exe` | The bootstrapper. The only file you need to keep | | `package\` | The client packages from the self-update | | `config\config.vdf` | Settings and the cached login for real accounts | | `logs\` | Text logs, including `content_log.txt` for downloads | | `steamapps\` | Default install location and SteamCMD's own state | Two of those deserve a comment. `config\config.vdf` is where SteamCMD keeps the cached credential after a real-account login has passed Steam Guard. For anonymous installs it does not matter; for Arma 3 or DayZ it is the file that makes unattended updates possible, and it should be treated like a password. `logs\content_log.txt` records every download, every state change and every failure with a timestamp. When an update fails overnight and the batch file's own log says nothing useful, this is the one to read. If you never set `+force_install_dir`, servers land in `C:\steamcmd\steamapps\common\`. That works for one server and becomes awkward for several, because the game files sit inside the tool's folder, a SteamCMD repair has to step around them, and backups of "the server" accidentally include the client. The layout that stays manageable keeps SteamCMD, servers and scripts apart: ```text C:\steamcmd\ SteamCMD only C:\servers\valheim\ one folder per server install C:\servers\satisfactory\ C:\servers\scripts\ .txt runscripts, .cmd files, logs ``` Keep the root short and free of spaces. Windows still has a 260-character path limit for many programs unless long paths are switched on in policy and the program opts in, and game servers are not reliably among the programs that opt in. A Workshop item several folders deep inside `C:\Users\Administrator\Documents\Game Servers\...` gets surprisingly close to that limit. Avoid three places in particular: - **`C:\Program Files`** and **`C:\Program Files (x86)`**. Writing there needs elevation, so either every update runs as administrator or the update fails with a permissions error part-way through. - **Your user profile**, including Desktop, Documents and Downloads. A scheduled task running as another account cannot see it, and Defender's Controlled folder access, if it is on, blocks unrecognised programs from writing to those folders. - **A OneDrive-synced folder.** Sync clients lock and upload files while SteamCMD is replacing them, and a game server writing its world every few minutes turns into constant sync traffic. Every server install also gets its own `steamapps\appmanifest_.acf`, holding the installed build id. That file is how you tell which version a server is on; [SteamCMD explained](https://www.renode.space/blog/steamcmd-explained) goes through it. #### force_install_dir on Windows `+force_install_dir` takes an absolute path, and on Windows the details are paths and quotes. ```text C:\steamcmd\steamcmd.exe +force_install_dir C:\servers\valheim +login anonymous ^ +app_update 896660 validate +quit ``` The `^` is the line continuation character in Command Prompt and batch files. In PowerShell the continuation character is the backtick instead, and in either shell it is safer to keep the whole command on one line until it works. Order matters. Recent SteamCMD builds print a warning along the lines of "Please use force_install_dir before logon!" if `+login` comes first, and depending on the version the directory is then ignored and the files go to the default location. Put `+force_install_dir` first, then `+login`, then `+app_update`. The same order applies inside script files. If the path contains a space, quote it: `+force_install_dir "C:\Game Servers\valheim"`. Quoting works, but it is one more thing to get wrong in batch files, where a variable holding a quoted path picks up a second set of quotes when you use it. The simpler fix is a path without spaces. Do not use relative paths. A relative directory is resolved against SteamCMD's own folder rather than the folder your batch file or shell is in, so `+force_install_dir ..\valheim` lands somewhere different depending on where SteamCMD lives. A mapped network drive is also a bad target: drive letters are per logon session, so a drive mapped in your desktop session does not exist for a scheduled task, and SteamCMD over SMB is slow and fragile even when it does. One SteamCMD folder can manage any number of server installs, because each one is a separate `force_install_dir`. What it should not do is run twice at the same time. Two instances share `package\`, `config\` and the self-update, and a second launch while the first is updating itself is a reliable way to corrupt the client. If several servers update on a schedule, update them one after another in a single script, or stagger their tasks by enough time for each to finish. #### Script files and +runscript A long command line in a batch file becomes a maintenance problem the first time you need to change one argument in six places. SteamCMD reads commands from a text file instead, one per line, without the `+` prefix: C:\servers\scripts\update-valheim.txt: ```text // Valheim dedicated server, app 896660 @ShutdownOnFailedCommand 1 @NoPromptForPassword 1 force_install_dir C:\servers\valheim login anonymous app_update 896660 quit ``` ```text C:\steamcmd\steamcmd.exe +runscript C:\servers\scripts\update-valheim.txt ``` Lines starting with `//` are comments. The two `@` lines are settings: `@ShutdownOnFailedCommand 1` stops at the first failing command instead of carrying on to `quit`, and `@NoPromptForPassword 1` stops an unattended run hanging forever on a password prompt nobody will answer. Both should be in every script that runs without you watching. Pass the script with an absolute path, for the same reason as `force_install_dir`. Note what is not in that script: `validate`. A routine update fetches only changed chunks; `validate` reads and hashes the whole install, and replaces any shipped file you have edited. Keep a second script with `validate` for repairs, and run it by hand when you need it. The reasoning is in [automating game server updates safely](https://www.renode.space/blog/automating-game-server-updates). A script file is also where you would put more than one app. Several `force_install_dir` and `app_update` pairs can follow one `login`, which runs the updates in sequence under one SteamCMD launch and sidesteps the two-instances problem above: C:\servers\scripts\update-all.txt: ```text @ShutdownOnFailedCommand 1 @NoPromptForPassword 1 login anonymous force_install_dir C:\servers\valheim app_update 896660 force_install_dir C:\servers\satisfactory app_update 1690800 quit ``` That order puts `login` before the directory, which the warning above complains about. In practice later `force_install_dir` lines are honoured for the `app_update` that follows them, but behaviour has changed between SteamCMD versions, so check where the files land after the first run. If the warning matters to you, run one script per server instead. #### A batch file that stops, updates and checks SteamCMD cannot replace files a running server holds open. Updating a running server either fails with a file-in-use error or, worse, half-succeeds and leaves an install that crashes on its next start. So the wrapper's job is: stop the server cleanly, update, check the result, start the server. This example assumes the server runs as a Windows service named `Valheim` (NSSM is the usual way to do that - the [Valheim on Windows guide](https://www.renode.space/blog/valheim-windows-dedicated-server-install) sets one up with a proper Ctrl+C stop so the world saves). `net stop` waits for the service to stop before returning, which is what you want. C:\servers\scripts\update-valheim.cmd: ```text @echo off setlocal cd /d "%~dp0" set LOG=%~dp0update-valheim.log echo ==== %DATE% %TIME% ==== >> "%LOG%" net stop Valheim >> "%LOG%" 2>&1 C:\steamcmd\steamcmd.exe +runscript "%~dp0update-valheim.txt" > "%~dp0last-run.log" 2>&1 type "%~dp0last-run.log" >> "%LOG%" findstr /C:"Success! App '896660'" "%~dp0last-run.log" >nul if errorlevel 1 ( echo UPDATE FAILED - server left stopped >> "%LOG%" exit /b 1 ) net start Valheim >> "%LOG%" 2>&1 exit /b 0 ``` A few lines need explaining. - `cd /d "%~dp0"` changes to the folder the batch file is in. `%~dp0` expands to that folder with a trailing backslash. Task Scheduler starts tasks in `C:\Windows\System32` unless told otherwise, and any relative path in a script that "worked when I double-clicked it" breaks there. - The success check reads SteamCMD's output, not its exit code. The exit code has not been a reliable signal across versions, and a failed download can exit with a code that looks fine. The line SteamCMD prints after a good update or install is `Success! App '' fully installed.`, and when it is already up to date it prints `Success! App '' already up to date.` Matching on the common prefix accepts both. - On failure the script leaves the server stopped. That is a choice. Starting a server on a half-updated install risks corrupting the world; leaving it down means players notice and somebody looks. For a server where downtime is worse than risk, change that branch to start the service anyway and alert you some other way. - `%DATE%` and `%TIME%` are formatted by the system locale, so do not try to build file names from them; the format changes between machines. If you want one log file per run, get the timestamp from PowerShell with `Get-Date -Format yyyyMMdd-HHmm` instead. If the server is not a service but a console window started from a batch file, there is no clean way for a script to stop it. Closing the window or `taskkill /F` ends the process without letting it save. Run game servers as services if you intend to update them unattended; it is the only arrangement where "stop" means a clean stop. > [!WARNING] > Test the batch file by running it the way Task Scheduler will - as the same account, from a different working directory - before you trust it. A script that only works from your own desktop session will fail at four in the morning, and the first you will hear of it is players asking why the server is down. #### Scheduled updates with Task Scheduler Task Scheduler is Windows' cron. It can be driven from the GUI (`taskschd.msc`) or from the command line with `schtasks`, which is easier to document and repeat. ```text schtasks /Create /TN "Servers\Update Valheim" ^ /TR "C:\servers\scripts\update-valheim.cmd" ^ /SC WEEKLY /D MON /ST 05:00 /RU SYSTEM /RL HIGHEST ``` That creates a task in a `Servers` folder that runs every Monday at 05:00 as the built-in `SYSTEM` account with highest privileges. Test it immediately, then read its last result: ```text schtasks /Run /TN "Servers\Update Valheim" schtasks /Query /TN "Servers\Update Valheim" /V /FO LIST ``` `Last Result: 0` means the batch file exited with `0`, which in the script above means the success line was found. `1` means the script's own failure branch ran. Anything else - a large hexadecimal number - usually means the task never got as far as running the script: a wrong path in `/TR`, or an account without permission to the folder. The account the task runs as is the decision that matters. | Run as | Good for | Watch out for | | --- | --- | --- | | `SYSTEM` | Anonymous installs, services | Full control of the machine | | A dedicated local user | Real-account logins | Needs folder rights | | Your own account | Testing | Password changes break it | `SYSTEM` is the simplest: it can stop and start services and write anywhere. It is also the most powerful account on the machine, so a script it runs should live in a folder that only administrators can write to. For servers that need a real Steam login (Arma 3, DayZ), a dedicated local user is cleaner. Log in once as that user, run SteamCMD by hand to pass Steam Guard, and the cached credential in `config\config.vdf` lets the scheduled task log in without a prompt afterwards. That user needs Modify rights on `C:\steamcmd` and `C:\servers`, the "Log on as a batch job" right (granted automatically when you save a task with its password), and the right to control the service if the script stops and starts it. Options worth setting in the task's properties, whichever account you use: - **Run whether user is logged on or not.** Otherwise the task only runs while someone is signed in at the console. - **Stop the task if it runs longer than** something sensible, such as two hours. The default is three days, which hides a hung SteamCMD for a long time. - **Do not start a new instance** if the task is already running. This is the default and it prevents two SteamCMD runs overlapping. - **Run task as soon as possible after a scheduled start is missed.** Useful if the machine was rebooting for Windows updates at 05:00 - though a weekly server update colliding with Patch Tuesday is worth avoiding in the first place. How often to run it depends on the server. A vanilla server can update weekly or on every restart; a modded server should not update itself at all on the day of a game patch, because the update breaks mods until their authors catch up. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) covers the recovery, and [scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having) covers what else belongs on the same schedule. ```diagram title: A scheduled update on Windows task = Task Scheduler | weekly, 05:00 cmd = update-valheim.cmd | stop, update, check svc = Valheim service | net stop / net start steam = steamcmd.exe | +runscript log = last-run.log | Success! App task -> cmd cmd -> svc : stop first cmd -> steam : update.txt steam -> log : output log -> svc : start only on success ``` #### Windows Defender exclusions Microsoft Defender's real-time protection scans files as they are written. An update writes thousands of them, and a `validate` reads every file in the install, which Defender may scan again. On a large install that is the difference between a validate finishing in a few minutes and one that takes much longer. Defender can also hold a freshly written file open for a moment while it scans, which occasionally collides with SteamCMD moving it into place. Excluding the SteamCMD folder and the server folders from scanning removes both problems. From an elevated PowerShell window: ```text PS> Add-MpPreference -ExclusionPath "C:\steamcmd" PS> Add-MpPreference -ExclusionPath "C:\servers" PS> Get-MpPreference | Select-Object -ExpandProperty ExclusionPath ``` The last line lists the current exclusions so you can confirm they took. On a machine managed by Group Policy or Intune, local exclusions may be ignored or overwritten, and the policy has to carry them instead. Be honest with yourself about the trade. An exclusion means Defender will not look at anything in those folders, including a malicious plugin someone sends you or a mod downloaded from a site you should not have trusted. Keep exclusions to the folders that need them, never exclude a downloads folder or a whole drive, and scan mods and plugins before they go into an excluded folder. [Malicious plugins and mods](https://www.renode.space/blog/malicious-plugins-and-mods) explains why that is not paranoia. Defender exclusions are separate from Windows Defender Firewall. SteamCMD itself needs only outbound internet access, which Windows allows by default. The game server needs inbound rules for its ports, and the first time it starts Windows will ask whether to allow it on private or public networks. Answer for the network the server is actually on, or create the rules yourself with `New-NetFirewallRule` - the Valheim Windows guide linked above walks through both. #### Troubleshooting SteamCMD on Windows **SteamCMD closes immediately when double-clicked, or the window flashes and vanishes.** It probably updated itself and relaunched, or hit an error and exited. Run it from an open Command Prompt so the output stays on screen, and read `logs\bootstrap_log.txt`. **`Failed to install app 'X' (Disk write failure)`.** The target folder is not writable by the account running SteamCMD, or the disk is full. Check the account first if it only fails from Task Scheduler. On a full disk, remember an update needs free space on top of the existing install - [what to do when the disk is full](https://www.renode.space/blog/game-server-disk-space-full) covers how much. **`Failed to install app 'X' (Missing file permissions)` or access denied.** A file in the install is in use (the server is still running), read-only, or owned by an account the current one cannot modify. Stop the server, then compare the folder's permissions against the account the task runs as. **The update says success but the server did not change.** The task ran a different script, the install directory in the script differs from the one the service starts from, or `force_install_dir` came after `login` and the files went to `C:\steamcmd\steamapps\common`. Look for a second copy of the server there. **The task's Last Result is non-zero but the log is empty.** The batch file never started, or started in `System32` and wrote its log there. Check the path in the task's action and the `cd /d "%~dp0"` line. **SteamCMD hangs at login in a scheduled task.** It is waiting for a password or a Steam Guard code that will never come. Run SteamCMD once by hand as the task's account to cache the credential, and keep `@NoPromptForPassword 1` in the script so the next failure ends instead of hanging. **Everything stopped working after a Windows update.** Usually not SteamCMD. Confirm the service still starts by hand and the task still exists; then delete everything in `C:\steamcmd` except `steamcmd.exe` and the `config` folder (if you use a real account), and run `+quit` to rebuild the client. #### When you do not want to run Windows at all Most of this post exists because Windows was not designed around unattended command-line tools, and every step above - service wrappers, task accounts, Defender exclusions - is there to make it behave like one. Some servers only ship a Windows build, and for those it is worth it, or worth reading [Linux vs Windows for game servers](https://www.renode.space/blog/linux-vs-windows-game-servers) and the [Wine and Proton route](https://www.renode.space/blog/wine-and-proton-for-windows-only-servers). For the rest, the question is whether you want to maintain the machine at all. On RE:NODE the SteamCMD step runs when a game server is created, usually inside a minute of payment clearing, and the install output appears line for line in the console. Game variables and launch settings are fields on the Startup tab, so there is no script to maintain. The Schedules tab runs cron-style tasks with ordered steps - a backup, then a restart, with delays between them - which covers the job Task Scheduler does above; the [guides](https://www.renode.space/guides#schedules) show how it is set up. Games that need your own Steam login wait on the Setup tab until you add it. #### FAQ ##### Do I need to run SteamCMD as administrator? No, as long as it and the server folders are somewhere the account can write to, such as `C:\steamcmd` and `C:\servers`. Needing administrator rights is usually a sign the files are under `Program Files`. The only part of this setup that needs elevation is adding Defender exclusions and creating tasks that run as `SYSTEM`. ##### Can I use the Steam client's Tools library instead of SteamCMD? For some servers, yes: dedicated servers listed under Tools in the Steam library install like any game. That needs the full Steam client signed in on the machine and updates whenever Steam decides to, which suits a home PC that also plays games. A machine that only runs servers is better served by SteamCMD, which needs no desktop session. ##### Where are the SteamCMD logs on Windows? In the `logs` folder inside the SteamCMD directory, for example `C:\steamcmd\logs`. `content_log.txt` records downloads and install failures and is the first file to read when an update fails. Your own batch file's log is separate and only holds what you redirected into it. ##### Can I download the Linux build of a server from Windows? Yes. Add `@sSteamCmdForcePlatformType linux` at the top of the script before `login`. The files download but will not run on Windows; it is useful for preparing an install to copy to a Linux machine or a host's file manager. ##### How do I uninstall SteamCMD? Delete its folder, and delete any scheduled tasks and Defender exclusions you created for it. SteamCMD does not write to the registry or install services of its own. Server installs in other folders are untouched and keep working; they only lose their updater. ##### Why does the update take longer every time a new SteamCMD is released? Because SteamCMD updates itself before running your commands whenever Valve ships a new client. The first scheduled run after a client release spends extra time on that. It is normal, and the reason a task's time limit should be generous. On RE:NODE game servers are installed with SteamCMD when they are created, usually inside a minute of payment clearing, with game variables and launch settings as fields on the Startup tab. Scheduled backups and restarts run from the Schedules tab, and backup slots come with every game plan. [Browse game servers](https://www.renode.space/game-servers) --- ### Choosing a hosting provider: what to look at, from the inside Published 2026-10-14 by RE:NODE Team. https://www.renode.space/blog/choosing-a-hosting-provider-from-the-inside When we pick a host, we look at six things, in this order: what CPU the workload actually lands on and how fast one core of it is, what every "unlimited" on the page turns into once the terms are read, whether the status page tells the truth on a bad day, who restores your data and how, how much of the machine you can reach without asking anyone, and whether a person answers when you write in. Price comes after all of that, because a cheap plan that fails on any of the six is not cheap. We run the RE:NODE platform - the orchestration that provisions, scales and recovers customer servers, the game, VDS, web, database and storage lines, and the monitoring and backup automation around them. That gives us an uncomfortable view of how hosting is sold versus how it is run. Most of what follows is the stuff operators know and the plan page does not say. It applies to any host, including us, and some of it is deliberately unflattering to small providers like ours. There is a shorter checklist version in [choosing game server hosting](https://www.renode.space/blog/how-to-choose-game-server-hosting). This one is the reasoning behind it. #### Why the spec sheet lies by omission A plan page is written to be compared, so it lists the things that compare easily: gigabytes of RAM, gigabytes of disk, a number of cores, a price. None of those is false. The trouble is what they leave out, and from the inside we can tell you the omissions are not random. RAM is easy to sell and easy to deliver honestly, because memory is either there or it is not. Disk size is the same. Cores are where it gets slippery, because "2 vCPU" says nothing about which CPU, how old it is, how fast one thread runs, or how many other customers are queued on the same physical cores. Bandwidth is slipperier still. And the things that decide whether you stay - backups, access, support, what happens at 3am - rarely appear on the plan page at all. So the rule we ended up with is simple: the numbers on the page are the floor of what you need to know, not the answer. Everything below is about the questions those numbers do not answer. #### CPU: generation and single-thread speed beat core counts This is the single most misunderstood thing in hosting, and it matters most for game servers. Most game servers do their important work on one thread. The simulation tick - moving entities, running game logic, deciding what every player sees next - runs on a main thread, and the other cores help with networking, chunk loading, saving and the like. Minecraft is the famous example, but the pattern is broad: when a server lags, it is usually one core at 100% while the rest sit idle. We wrote that up properly in [reading game server CPU usage](https://www.renode.space/blog/reading-game-server-cpu-usage-single-thread), and [game server CPU requirements](https://www.renode.space/blog/game-server-cpu-requirements) covers it game by game. What that means for choosing a host: - A newer CPU at a high clock usually beats an older CPU with more cores. Per-clock performance has moved a lot between generations, so "3.0 GHz" on a CPU from many years ago and "3.0 GHz" on a recent one are not the same speed. - Many-core server chips are excellent at running many things at once and often unremarkable at running one thing fast. That is the right trade for a host packing in web apps. It is the wrong one for a single busy game server. - A "vCPU" is usually one hardware thread, not one physical core. Two vCPU may be the two hyperthreads of a single core, which is less than two full cores when both are busy. The question to ask any host is "which CPU model does this plan run on?" A good answer names a model. A fair answer says "it varies by node, here are the models we use". An evasive answer - "enterprise-grade processors" - tells you they would rather you did not know. In fairness to hosts, not all of them can promise a model, because nodes get replaced. But they can tell you what is in the fleet today. On RE:NODE, the VDS line names its CPU (the Intel i9-9900K), and on the shared lines the plan's CPU figure is a percentage of one core enforced as a hard limit - 250 means 2.5 vCPU of throttled share, not 2.5 cores you get to burst past. A server sitting at its limit is slow, never suspended for it. We do not publish a model for the shared nodes, so if that matters to you, that is a question to ask us too. ##### How to check what you actually got On a VDS you have a shell, so look: ```bash $ lscpu | grep -E 'Model name|^CPU\(s\)|Thread' $ sysbench cpu --threads=1 --time=30 run $ vmstat 1 10 ``` The first line tells you the model and how many threads you have. The `sysbench` run with one thread gives you an events-per-second number you can compare between hosts - run it on every candidate the same way. In `vmstat`, watch the `st` column: steal time is CPU your virtual machine wanted and the hypervisor gave to someone else. A few percent now and then is normal on shared hardware. Steal that sits high while your own load is low means a crowded host, and [shared CPU and noisy neighbours](https://www.renode.space/blog/shared-cpu-and-noisy-neighbours) explains what you can and cannot do about it. On a game panel you usually have no shell, but the host's `/proc/cpuinfo` is often visible from inside the container, and the console's CPU graph against the limit tells you whether you are bounded by the share you bought. #### What "unlimited" means From the operator's side, nothing is unlimited. Every resource we work with has a physical ceiling: uplink capacity, disk throughput, inodes, power. When a plan says "unlimited", it means one of three things, and you want to know which. | The page says | What it usually means | What to ask | |---|---|---| | Unlimited bandwidth | Not billed per GB, under a fair-use clause | What happens at the fair-use line? | | Unlimited slots | No slot count enforced in software | What does the CPU and RAM handle? | | Unlimited disk or sites | Limited by inodes, I/O or file count | Where is the inode or I/O limit? | "Unmetered" is the honest word for bandwidth: you are not charged per gigabyte. It is not a promise that you can saturate a shared uplink all month. Every host with an unmetered plan has a point at which someone's traffic starts hurting other customers, and the only real question is whether they tell you where it is and what happens when you reach it - a throttle, an email, a suspension. Our own wording is that unmetered means not billed per gigabyte, not a licence to saturate a shared uplink, and [bandwidth and fair use](https://www.renode.space/blog/bandwidth-and-fair-use) goes into what that means in practice. "Unlimited player slots" on a game server is the one that annoys us most, because it is technically true and practically meaningless. The game, the CPU and the RAM decide how many players fit, not a number in the panel. A host advertising unlimited slots on a small plan is selling a number you cannot use. The test we apply: if a plan says unlimited, search the terms of service for "fair use", "acceptable use", "excessive" and "inode". Whatever the terms say is the real plan. If the terms say nothing at all, the limit exists anyway - it is just enforced by whoever is on shift, by judgement, without warning. #### How to read a status page Every host has a status page now, and most of them are green almost all the time. That alone tells you very little. Here is what we look at instead. 1. Who measures it. A status page fed by automated checks from outside the host's network is worth more than one somebody edits by hand after the fact. A hand-edited page is green until a human decides it should not be. 2. How fine-grained it is. One "All systems operational" banner for an entire company hides the fact that your node can be down while everything else is up. Per-node or per-service components are more honest. 3. The history. Scroll back. A page with no incidents in a year is either describing a remarkably lucky operation or not being updated. Real infrastructure has bad days, and the honest pages show them. 4. What the incident notes say. "We are investigating" followed by "resolved" with nothing in between teaches you nothing. Notes that say what broke, what was affected and what changed afterwards tell you how the team thinks. 5. Where it is hosted. If the status page lives on the same infrastructure it reports on, it goes down at exactly the moment you need it. On uptime percentages: they are only meaningful with the measurement interval and the definition next to them. 99.9% over a 30-day month allows about 43 minutes of downtime; 99.99% allows about four. If the check runs every five minutes, anything shorter than that may never be seen. And an SLA usually means a partial credit off your bill, not your downtime back - read what the remedy is before you are impressed by the number. For what it is worth, RE:NODE's [status page](https://www.renode.space/status) samples availability every five minutes and we do not publish an uptime percentage or an SLA. We would rather say that plainly than print a figure. You should weigh that the same way you would weigh it on any host. #### Backups, and who restores them This is where we have the strongest opinions, because backup automation is a large part of running a platform, and because the gap between "we do backups" and "you can get your data back" is where most hosting disappointment lives. There are two different things a host can mean by "backups": - Platform backups - the host copies its own disks so it can recover the machine if hardware fails. You usually cannot see these, cannot choose what is in them and cannot restore a single file from them yourself. They protect the host's ability to rebuild, not your ability to undo a mistake. - Customer backups - copies of your server that you can make, schedule, restore and download. You want to know which one a plan includes, and you want the second kind. Then you want answers to these: - Can I restore it myself, or do I file a ticket and wait? - Can I download it, so a copy exists outside this host entirely? - Where is it stored? A backup on the same disk as the data it protects is a convenience, not a backup. - What happens to backups when I cancel or delete the server? - Has anyone restored one recently? That last one matters most. As the house line goes, a backup nobody has restored is a hypothesis. We have strong views on testing restores before you need them, and they are in [testing a restore before you need it](https://www.renode.space/blog/testing-a-restore-before-you-need-it) and [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore). On RE:NODE, every plan has backup slots: on demand or scheduled, restored with a button, downloadable, lockable against rotation and stored off the machine they protect. Deleting a server deletes its backups, locked ones included - which is exactly the kind of detail you should look for on any host, because people learn it the wrong way. Separately, the platform takes nightly backups copied to separate hardware. Neither replaces a copy you keep yourself, and we would say that about any host's backups, RE:NODE's included. #### Panel, file and console access The question here is how much of your own server you can reach without asking anyone. The less you can reach, the more every small problem becomes a support ticket, and the harder it is to leave. For a game server or app host on a panel, the minimum we would accept: - A live console with the raw, unfiltered output and a command line. If a host only shows you a cleaned-up log or a "server is running" badge, you cannot diagnose anything yourself. - A file manager and SFTP. The file manager is for quick edits; SFTP is how you move a whole world, a modpack or a site in and out. No SFTP is a red flag on its own. - The startup command or at least its variables. You will eventually need a launch flag, a JVM option or a different branch. - Resource graphs against the limits, so you can see whether you are hitting the CPU share or the memory ceiling. - Control over who else gets access, with permissions narrower than "everything". For a VDS, the minimum is root, a way to reinstall, and some out-of-band console (VNC or serial) for when you lock yourself out with a firewall rule. Ask what you get if SSH stops answering. "Open a ticket" is a weak answer. There is also an exit question hiding in here. Can you get all of your data out, in a normal format, without the host's help? If the answer is yes, a bad host costs you a weekend. If it is no, it costs you whatever they decide. What the RE:NODE panel gives every plan, without tiers: an unfiltered live console with a command line, a file manager, SFTP with credentials per server rather than per account, a Startup tab for game and environment variables, CPU, memory and disk graphs against the limits, and subusers with granular permissions. It is built on Pterodactyl and Wings with our own panel on top, so if you know Pterodactyl, the shape will be familiar - [what Pterodactyl is](https://www.renode.space/blog/pterodactyl-panel-explained) covers that. #### Support you can reach The thing nobody can tell from a plan page is what support is like, and it is the thing that decides whether you stay. Hosting is a support business with servers attached. What to look for: - More than one channel, and at least one that leaves a written trail. A ticket system where your attachments stay private beats a public Discord channel for anything involving credentials or logs. - A clear statement of when people are actually there. "24/7 support" from a small host often means "someone gets a notification". That is not dishonest, but it is not the same as a person on shift. We would rather a host told you its real hours. - Answers written by someone who read the question. A pasted knowledge-base link in reply to a specific question is a sign of a team triaging by keyword. - Whether support can do things, not just relay them. Can the person answering restore a backup, open a port, move a server? Or do they open an internal ticket and wait for an engineer? Here is the uncomfortable thing from the operator side: small hosts are often better at support than large ones, because the person answering frequently wrote the code, and worse at coverage, because there are fewer of them. Big hosts tend to be the reverse. Decide which you need. A hobby server can wait until morning; a paid community or a business app may not. RE:NODE support is a ticket from the panel (it reaches all staff, with private attachments), Discord and email. We do not advertise round-the-clock staffing, and we would not trust a host our size that did. #### Testing a host in the first week You learn more in the first week on a host than from any amount of reading reviews. Treat the first payment as the cost of a test, and run the test deliberately. Where a host offers a short term, take it. | When | Test | What a pass looks like | |---|---|---| | Day 1 | Route from your players | Low, steady ping and little loss in `mtr` | | Day 1 | CPU and disk benchmark | Numbers close to other hosts on the same tier | | Days 1-7 | Load at your peak hours | No steal or slowdown at busy times | | Day 2 | Support question | A specific answer from a person | | Day 3 | Backup and restore | You restore and download it yourself | | Day 5 | Data export | Everything comes out over SFTP or a dump | The route test matters first, because no amount of CPU fixes a bad path between the machine and your players. Run it from where your players actually are, not from where you are: ```bash $ mtr -rwc 100 203.0.113.10 $ fio --name=rand --rw=randread --bs=4k --size=1G --iodepth=32 \ --ioengine=libaio --direct=1 --runtime=30 --time_based ``` The address there is a documentation example - put in your server's. [Reading traceroute and mtr](https://www.renode.space/blog/reading-traceroute-and-mtr) explains how to read the output, and the most common misreading: loss on a middle hop that does not continue to the last hop is usually a router deprioritising the probes, not real loss. Then load the server the way you will use it, at the hours you will use it. A machine that benchmarks well at 10am on a Tuesday and crawls on Saturday evening has a capacity problem that a single benchmark will not show. Repeat the one-thread `sysbench` run at a few different times and compare. Ask support one real question you already know the answer to, and note how long the reply takes and whether it is right. Take a backup, delete a file you can live without, restore it, download the archive, and open it on your own machine. Pull your data out the way you would if you were leaving. If any of these is hard in week one, it will be worse in month six. #### Red flags Some of these are dealbreakers; some are just a reason to ask harder questions. We have tried to only list things we would also hold our own platform to. - No CPU model anywhere, and evasion when you ask. - "Unlimited" everything, with no fair-use section you can find. - A status page that has never shown an incident. - A DDoS protection claim with a large number and no explanation of what is filtered. Real protection drops obvious volumetric floods; attacks that look like real players are much harder, and anyone promising to stop everything is selling you a sentence, not a service. There is more on that in [DDoS attacks on game servers explained](https://www.renode.space/blog/ddos-attacks-on-game-servers-explained). - No SFTP, no raw console, or backups you can only restore through a ticket. - No way to export your data, or an export locked behind a cancellation. - Lifetime plans, or prices so far below everyone else's that the arithmetic cannot work. Hardware, power and bandwidth cost the same for everyone in a given market; a plan priced below that is subsidised by something - overselling, a short life, or both. - Terms that let the host suspend you for using the resources you paid for. Running at 100% of your CPU share should make your server slow, not get it removed. - Pressure to buy a long term up front before you have tested anything. None of these is proof a host is bad. Several together usually are. #### The trade-offs we would make again A few opinions, stated plainly, from running one of these. We would take a host that admits its limits over one that hides them. Every host has a ceiling on bandwidth, a support rota with gaps, a location that suits some players and not others. The ones that write those down are the ones you can plan around. RE:NODE runs on hardware we run, and we would rather you checked latency from your own players before you paid than found out afterwards. We would take fewer features and more access. A panel with an honest console, SFTP and real backups beats one with a hundred one-click buttons and no shell. We would always keep our own copy of anything that matters, on someone else's infrastructure. Not because hosts are careless, but because the failure you are protecting against might be the host itself - a billing mistake, a closed account, a company that stops trading. And we would test before committing. Every host, including ours, looks better on its own website than it does at 3am. The first week is where you find out which ones look the same. If you want the wider view on what kind of server to rent in the first place, [VPS vs VDS vs dedicated server](https://www.renode.space/blog/vps-vs-vds-vs-dedicated-server) is the place to start. #### FAQ ##### Is a higher core count always better for a game server? No. Most game servers are limited by how fast one core is, because the main simulation loop runs on a single thread. A plan with fewer cores on a newer, higher-clocked CPU will usually run a busy game server better than more cores on an older or many-core chip. Extra cores help with mods, plugins, chunk generation and running several servers side by side. ##### What is the difference between unmetered and unlimited bandwidth? Unmetered means you are not billed per gigabyte transferred. Unlimited is a marketing word for the same thing and should never be read as no ceiling at all - every host has a shared uplink and a fair-use point. The useful question is what the host does when you reach it: throttle, warn or suspend. ##### Should I trust a 99.9% uptime guarantee? Treat it as a statement about compensation, not about reliability. It allows about 43 minutes of downtime in a 30-day month, the measurement interval decides what counts, and the remedy is usually a partial credit. A status page with real incident history tells you more about how a host operates than the percentage does. ##### Are the host's backups enough on their own? They are a good first line and nothing more. Make sure you can restore and download them yourself, and keep at least one recent copy somewhere else entirely - your own machine or separate object storage. If the problem is the host account itself, backups stored with that host do not help. ##### How long should I test a new host before committing? A week of normal use, including your busiest hours, is enough to find most problems: route quality, CPU contention at peak, support response, and whether restores and exports actually work. Avoid paying for a long term until that week is behind you, even if it is cheaper per month. ##### Is a small host riskier than a big one? Differently risky. A small host is more likely to have support from people who built the system and less likely to have staff on shift at every hour. A big host has more coverage and more layers between you and an engineer. Your own backups and an easy way to export your data make either choice much safer. Every RE:NODE plan gets the same panel: an unfiltered console, a file manager, SFTP per server, and backups you restore with a button and can download. Game, app, web and database servers are usually ready inside a minute of payment, on NVMe. [See RE:NODE plans](https://www.renode.space/game-servers) --- ### Game server backups to S3: off-site world copies on a schedule Published 2026-10-08 by RE:NODE Team. https://www.renode.space/blog/game-server-backups-to-s3 The reliable way to get a game server's world into S3 storage every night is a small job on a machine you control that pulls the world over SFTP and pushes it to a bucket, timed a few minutes after the server has been told to save. rclone does both halves in one command, because it speaks SFTP and S3 natively; restic adds encryption and deduplication if you want months of history in little space. The panel's own backups stay your first line - they are quick to take and one button to restore - and the S3 copy is the one that survives the things panel backups do not: a deleted server, a mistake that was backed up over, or an account you can no longer reach. This post builds that job end to end: what to copy, how to get a clean copy, how to keep history without versioning, how to prune, and how to prove it restores. #### Why a second copy, and what it protects against Panel backups and an S3 copy fail in different ways, which is the whole reason to have both. | Risk | Panel backup | Copy in S3 storage | Copy at home | | --- | --- | --- | --- | | Griefing, bad plugin, corrupt save | Yes | Yes | Yes | | Backup slots rotated past the good copy | Only if locked | Yes, with longer retention | Yes | | Server deleted (backups go with it) | No | Yes | Yes | | Loss of the whole location | Depends | No, if in the same location | Yes | | You lose access to the hosting account | No | Only if it is a separate account | Yes | On RE:NODE, game plans include backup slots that are stored off the machine they protect, can be locked against rotation and restore with a button - but deleting a server deletes its backups, locked ones included. A copy in a bucket outlives that. Be honest about the other row, though: RE:NODE's S3 storage keeps one copy of your data on NVMe in one location, the same place as the game servers. It protects against deletion and mistakes, not against losing the site. For a world you would be heartbroken to lose, the third column matters too, and the same rclone job can drop a copy on your own disk. [Backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) covers the 3-2-1 reasoning in full, and [S3 storage sizing and the 3-2-1 rule](https://www.renode.space/blog/s3-storage-sizing-and-the-3-2-1-rule) applies it to buckets. #### The shape of the setup A game server on a panel is a container running the game, not a general-purpose machine: you get a console, a file manager, SFTP and a scheduler that runs console commands, backups and power actions - not arbitrary shell scripts. So the copy job runs somewhere else and reaches in over SFTP. ```diagram title: A nightly pull from the game server to a bucket panel = Panel schedule | save at 03:55 game = Game server | world files puller = Backup job | rclone on a VDS or PC bucket = S3 bucket | game-backups home = Local disk | optional third copy panel -> game : save command puller -> game : SFTP read at 04:00 puller -> bucket : S3 upload puller --> home : optional ``` The puller can be anything that runs on a timer: a Linux VDS, a home server or Raspberry Pi, or a Windows PC that is on at night. It needs rclone, the game server's SFTP details, and the bucket's keys. It never needs to run a game or keep files between runs unless you choose restic, which keeps a small cache. If the game runs on a VDS or a machine of your own instead, skip the SFTP half: the job runs on the same machine and reads the world folder directly. #### What to copy Copy state and configuration; skip anything that can be downloaded again. The world folder is usually megabytes to a few gigabytes, while the game files around it are often tens of gigabytes that SteamCMD will reinstall in minutes. | Game | Copy | Skip | | --- | --- | --- | | Minecraft (Paper) | `world*/`, `plugins/`, `server.properties`, `*.json` lists | `cache/`, `libraries/`, `versions/`, server jar | | Valheim | the save folder's `worlds_local/`, the three list files | the game install | | Palworld | `Pal/Saved/` | everything else | | Project Zomboid | `Zomboid/Saves/`, `Zomboid/db/`, `Zomboid/Server/` | the game install, `Zomboid/Logs/` | | Terraria | `.wld` files, `serverconfig.txt`, `tshock/` | the server binaries | | Factorio | `saves/`, `data/server-settings.json`, `mods/` | the game install | These paths move if the server is started with a custom save directory, so check yours against the startup line. [Game server backup strategy](https://www.renode.space/blog/game-server-backup-strategy) has the longer list, including the games where the obvious folder is not the whole story - Project Zomboid's player database being the classic. Write the choice down as an rclone filter file. It doubles as documentation of what your backup actually contains: minecraft.filter: ```text + /world/** + /world_nether/** + /world_the_end/** + /plugins/** + /server.properties + /*.json - /plugins/*.jar.old - /plugins/**/logs/** - * ``` Rules are read top to bottom, the first match wins, and the final `- *` excludes everything not listed. Keeping plugin jars in the copy is deliberate: a world restored next to a newer plugin version is a common way to break it, and the exact jar you were running may not be downloadable later. #### Setting up the rclone remotes Install rclone on the puller (`sudo apt install rclone` is often old; the install script or a release binary from rclone.org gets the current version), then define two remotes - one for the game server's SFTP, one for the storage. ~/.config/rclone/rclone.conf: ```ini [mc] type = sftp host = sftp.example-node.net port = 2022 user = yourname.a1b2c3d4 pass = [store] type = s3 provider = Other access_key_id = AKIA... secret_access_key = ... endpoint = https://s3.example.com region = us-east-1 force_path_style = true ``` Take the SFTP host, port and username exactly as the panel shows them for that server - on Pterodactyl-based panels the username carries a server suffix and the port is usually not 22. The `pass` field must hold the output of `rclone obscure`, not the plain password. `rclone obscure` is reversible encoding, not encryption, so protect the file itself with `chmod 600`. [SFTP and the file manager](https://www.renode.space/blog/sftp-and-the-file-manager) explains where the credentials come from. For the storage remote, `provider = Other` is the generic S3-compatible setting and `force_path_style = true` is already rclone's default. The endpoint is the HTTPS hostname you pointed at the storage plan's proxy slot; the raw plain-HTTP port works too, but then your world travels unencrypted. Test both remotes before anything else: ```bash $ rclone lsd mc:/ $ rclone ls mc:/ --filter-from minecraft.filter | head $ rclone lsd store: $ rclone mkdir store:game-backups ``` The second line is the important one: it lists exactly the files the backup will take. If the world folder is not in that list, nothing after this point matters. [rclone with S3 storage](https://www.renode.space/blog/rclone-with-s3-storage) covers remotes, flags and bandwidth limits in more depth. #### Getting a clean copy: save first Most games hold the world in memory and write it on a timer. Copy files while the game is halfway through writing and you get a backup that looks complete and does not load. The answer is to tell the game to save shortly before the copy starts, using the panel's scheduler. On RE:NODE the Schedules tab runs ordered tasks with delays from a cron expression. For Minecraft, a nightly schedule at 03:55 would be: Schedule: pre-backup save, 55 3 * * *: ```text Task 1 command save-off Task 2 command save-all flush (delay 5 s) Task 3 command save-on (delay 600 s) ``` `save-off` stops autosaves so the game does not start rewriting region files mid-copy, `save-all flush` writes everything to disk and waits for it, and `save-on` re-enables autosave ten minutes later, after the puller has finished at 04:00. For a world that copies in a minute, ten minutes is generous; for a multi-gigabyte world, time a run and widen the gap. Other games have their own save command - `save` in Project Zomboid and Terraria, `saveworld` in 7 Days to Die, `/server-save` in Factorio - and some, like Valheim and DayZ, have no server console command and are safest copied from a scheduled panel backup or after a clean restart. [Scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having) and [cron expressions explained](https://www.renode.space/blog/cron-expressions-explained) cover the scheduler. The puller's clock and the panel's schedule must agree on the time zone. Write both in UTC, or check what each one assumes, before trusting a five-minute gap. #### Keeping history without versioning A single `rclone sync` keeps the bucket identical to the server - which means that when the world gets griefed at 21:00, the 04:00 sync faithfully copies the griefed world over the good one. A backup needs history. Without bucket versioning to lean on, there are three ways to get it. **Dated full copies.** Each night goes into its own prefix. Simple, obvious to restore, and costs a full world's size per day. ```bash $ rclone copy mc:/ store:game-backups/mc/daily/$(date -u +%F) \ --filter-from minecraft.filter --transfers 4 --log-file /var/log/mc-backup.log ``` **Sync with a backup directory.** The bucket holds one current copy, and every file that sync would overwrite or delete is moved into a dated folder first. History costs only the files that changed, which for a Minecraft world is the region files players actually visited. ```bash $ rclone sync mc:/ store:game-backups/mc/current \ --backup-dir store:game-backups/mc/changed/$(date -u +%F) \ --filter-from minecraft.filter ``` Restoring a past day this way means taking `current` and laying the dated folders back over it, newest first down to the day you want - possible, but fiddly under pressure. **restic.** Pull the files to a local staging folder with rclone, then let restic take a snapshot to the bucket. restic deduplicates at the chunk level and encrypts everything, so thirty daily snapshots of a world that changes a little each day cost little more than one. Restoring any snapshot is one command. It is the best option if you can spare the puller some local disk. ```bash $ rclone sync mc:/ /srv/stage/mc --filter-from minecraft.filter $ restic -r s3:https://s3.example.com/game-backups/restic backup /srv/stage/mc --tag mc ``` restic reads `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `RESTIC_PASSWORD` (or `RESTIC_PASSWORD_FILE`) from the environment. Lose the restic password and the repository is unreadable - by design. [restic backups to S3](https://www.renode.space/blog/restic-backups-to-s3) covers initialising the repository and the rest. #### Retention and cleanup Storage without lifecycle rules does not delete anything on its own, so retention is part of your job script. The obvious command is the wrong one. `rclone delete --min-age 14d` filters on each object's modification time, and rclone preserves the source file's modification time when it uploads (it stores it in the object's metadata). A config file nobody has touched for a month arrives in tonight's dated folder already "a month old", and `--min-age 14d` deletes it the moment the job finishes. Your newest backup quietly loses every file that had not changed recently - exactly the files you would not think to check. Delete whole dated prefixes by their name instead. The folder name is the date the copy was taken, which is what you mean by age: ```bash CUTOFF=$(date -u -d '14 days ago' +%F) rclone lsf --dirs-only store:game-backups/mc/daily | while read -r d; do d=${d%/} if [[ "$d" < "$CUTOFF" ]]; then rclone purge "store:game-backups/mc/daily/$d" fi done ``` ISO dates (`2026-10-08`) sort the same way as text and as time, which is why the plain string comparison works. `date -d` is GNU date, standard on Linux; on macOS use `date -u -v-14d +%F`. The same applies to the `--backup-dir` layout: prune the dated `changed/` folders by name, never with `--min-age`. For restic, retention is a policy: ```bash $ restic -r s3:https://s3.example.com/game-backups/restic forget \ --tag mc --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune ``` A sensible policy for most game servers is a week of dailies, a month of weeklies, and a copy before every major update kept indefinitely. Size the bucket from that: a 2 GB Minecraft world with dated full copies for fourteen days needs about 28 GB; the same history in restic is usually a small multiple of one world. [How much storage a game server needs](https://www.renode.space/blog/how-much-storage-does-a-game-server-need) helps with the world side of that sum. #### Scheduling the job Put the whole thing in one script so the schedule is one line: /usr/local/bin/mc-backup.sh: ```bash #!/usr/bin/env bash set -euo pipefail DAY=$(date -u +%F) CUTOFF=$(date -u -d '14 days ago' +%F) rclone copy mc:/ "store:game-backups/mc/daily/$DAY" \ --filter-from /etc/rclone/minecraft.filter --log-file /var/log/mc-backup.log rclone lsf --dirs-only store:game-backups/mc/daily | while read -r d; do d=${d%/} if [[ "$d" < "$CUTOFF" ]]; then rclone purge "store:game-backups/mc/daily/$d"; fi done curl -fsS -m 10 https://hc.example.com/ping/mc-backup > /dev/null || true ``` Then `crontab -e` and `0 4 * * * /usr/local/bin/mc-backup.sh`. `set -euo pipefail` stops the script at the first failure, so a failed copy never goes on to delete old backups. The last line pings a dead-man's-switch monitor (Healthchecks.io and similar services), which alerts you when the ping does not arrive - the only reliable way to notice a backup job that silently stopped. On a Windows puller, Task Scheduler runs the same rclone commands from a `.bat` file; rclone behaves identically there. #### Restoring from the bucket A backup nobody has restored is a hypothesis. Restore one before you need to: 1. Pick a day and download it to your PC: `rclone copy store:game-backups/mc/daily/2026-10-07 ./restore-test`. 2. Open the world in a local copy of the game, or on a test server, and walk around the main base. 3. For a real restore, stop the game server, move the damaged world folder aside, upload the restored one with rclone or the file manager, and start the server. Pushing the restore straight back over SFTP works the same way in reverse - `rclone copy store:game-backups/mc/daily/2026-10-07 mc:/` - but only with the server stopped, or the game's next save overwrites what you just put back. [Testing a restore before you need it](https://www.renode.space/blog/testing-a-restore-before-you-need-it) turns this into a quarterly habit. #### FAQ ##### Can the game server push to S3 by itself? Not from a panel game server: its scheduler runs console commands, backups and power actions, not shell scripts. Some games have plugins that upload backups to S3, and those work if you trust the plugin. Otherwise pull from outside with rclone, as above. ##### How often should I copy the world off-site? Daily is right for most servers, timed for the quietest hour. Add a manual copy before every game update and every major plugin change. Hourly copies of a large world cost more than they protect. ##### Is the panel's backup not enough? It is enough for most mistakes, and it is the fastest restore. It does not survive the server being deleted, and slots rotate. The S3 copy exists for the cases panel backups cannot cover. ##### Should I encrypt game world backups? restic encrypts everything by default. With rclone you can wrap the storage remote in a `crypt` remote. For a game world the main reason is that configs often contain RCON and database passwords. ##### Will copying the world slow the server down? Reading a few hundred megabytes over SFTP is light, but a big world on a busy server can cause a brief stutter. Run the job at the quietest hour and use `--bwlimit` in rclone if players notice. RE:NODE's S3 storage works with rclone and restic as they are: an access key and secret key generated for your server, a first bucket created, path-style addressing and any region name, with HTTPS through the plan's proxy slot. It keeps one copy on NVMe - a good second home for your worlds, alongside a copy of your own. [See S3 storage plans](https://www.renode.space/object-storage#s3-storage) --- ### Announcing server maintenance to players Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/announcing-maintenance-and-downtime Tell players about planned maintenance at least a day ahead, with the exact start time in their own timezone, how long it will take, what changes, and whether they need to do anything. Remind them an hour before, warn in game at ten, five and one minute, and post again the moment the server is back. For unplanned downtime the order reverses: acknowledge it within minutes even if you do not know the cause, post an update on a fixed cadence until it is resolved, never promise a time you cannot keep, and finish with a short note on what happened. Players forgive downtime far more readily than silence, and most of the warning work can be automated so it happens even when you are busy. Restarts themselves - when they help and when they only hide a problem - are covered in [restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help). This post is about the people on the other end. #### Planned and unplanned downtime need different messages | | Planned maintenance | Unplanned outage | | --- | --- | --- | | Examples | Game update, mod update, wipe, plan change, migration | Crash loop, broken update, host incident, attack | | First message | Days or a day ahead | Within minutes of noticing | | What you know | Start time, duration, changes | Often only that it is down | | Updates | Reminder, start, finish | On a fixed cadence until fixed | | Last message | "Back up, here is what changed" | "Back up, here is what happened" | | Tone | Routine, brief | Calm, factual, no guessing | Most communities are good at the first column and bad at the second. A planned update gets a polished announcement; a crash at 21:00 gets nothing for forty minutes while the owner fixes it, and by then a dozen people have asked in chat and two have decided the server is dead. The fix is to treat the first message of an outage as part of the fix, not something to do after it. #### What every maintenance announcement must say Five facts, in this order, and nothing a player has to work out themselves: 1. **What** - "Update to the new game version", "Monthly map wipe", "Moving to a bigger plan". 2. **When** - the start time in every reader's timezone, using a Discord timestamp. 3. **How long** - a realistic estimate, rounded up. "About 30 minutes" when you expect fifteen. 4. **What changes** - for players, not for you. "Clients must update before joining", "Inventories are kept, builds are wiped", "Nothing - this is invisible". 5. **What to do** - update the game, re-import the mod profile, nothing at all. Planned maintenance template: ```text Maintenance: game update to version 1.2 When: () Expected downtime: about 30 minutes What changes: you need to update your game before rejoining. Worlds, inventories and builds are not affected. What to do: update through your launcher, then join as usual. We will post here when the server is back. ``` Discord renders `` as a full date and time in each reader's own timezone, and `` as a live countdown. Get the Unix time from any converter, or `date -d "2026-01-01 20:00 CET" +%s` on a Linux machine. The other formats are `t` and `T` for short and long time, `d` and `D` for dates, and `f` for short date and time. Leave out everything else. Players do not need to know which config file you are editing. If there is a reason worth telling them - "the update fixes the crash on the bridge" - one sentence is enough. #### When to announce | Change | First notice | Reminders | | --- | --- | --- | | Routine weekly or nightly restart | A pinned schedule, once | In game: 5 and 1 minute | | Game or mod update, under an hour | 24 hours | 1 hour, then in game 10, 5, 1 minute | | Wipe or reset | At least a week | 24 hours, 1 hour, in game | | Migration or long maintenance | Several days | 24 hours, 1 hour, in game | | Emergency fix with the server up | As soon as decided | In game 10, 5, 1 minute minimum | Routine restarts do not need an announcement each time. Publish the schedule once - "the server restarts every day at 05:00 CET" - pin it, and let the in-game warnings handle the rest. A ping for every routine restart trains players to mute the announcements channel, and then they miss the one that matters. Wipes are different. Players plan around them, sometimes for weeks, and a wipe moved or announced late costs more goodwill than almost anything else you can do. [Wipes without losing your players](https://www.renode.space/blog/rust-wipes-without-losing-your-players) is mostly about this. Avoid starting maintenance at your peak hour. Your player-count history shows when the server is quietest - often early morning in the server's timezone - and that is when routine work belongs. For a server in Western Europe, early morning is also late evening in the Americas, so check whether a part of your community plays then. #### Warning players in game A Discord announcement reaches people who read Discord. The in-game countdown reaches the people who are about to lose their progress. Most games have a console command that broadcasts to everyone: | Game | Broadcast from the console | | --- | --- | | Minecraft | `say Restarting in 5 minutes` or `tellraw @a` with JSON text | | CS2, TF2, Garry's Mod, other Source games | `say Restarting in 5 minutes` | | 7 Days to Die | `say "Restarting in 5 minutes"` | | Project Zomboid | `servermsg "Restarting in 5 minutes"` | | Factorio | Type the text without a leading slash; it is sent as chat from the server | | FiveM | txAdmin's scheduled restarter warns players automatically before each restart | | Valheim | No broadcast command in the vanilla server; use Discord, or a server-side mod | Minecraft: a more visible warning: ```text tellraw @a {"text":"Server restarting in 5 minutes - find somewhere safe.","color":"gold"} title @a actionbar {"text":"Restart in 1 minute","color":"red"} ``` Palworld's admin `Broadcast` command also exists; on some versions it mangles spaces in the message, so test it before relying on it. Whatever the game, send the warnings at fixed offsets - ten minutes, five, one - and say whether progress is safe. "The world saves before the restart" stops people logging out in a panic in the middle of a fight. The last warning should go out shortly before the server stops, not at the moment it stops, and the stop itself should be a clean one that saves the world. A kill does not save. [Graceful shutdown and health checks](https://www.renode.space/blog/graceful-shutdown-and-health-checks) explains the difference. #### Automating the countdown with a schedule A restart that relies on someone typing warnings at 05:00 will eventually happen without them. Put the whole sequence in a schedule: warnings, a pause, a backup, the restart. On RE:NODE the Schedules tab takes a cron expression and an ordered list of tasks, each with a delay: a console command, a backup, or a power action. A daily restart with warnings looks like this: Schedule: daily restart at 05:00, cron 0 5 * * *: ```text 1. Console command say Restarting in 10 minutes. The world saves first. delay 0 2. Console command say Restarting in 5 minutes. delay 300 s 3. Console command say Restarting in 1 minute. delay 240 s 4. Console command save-all delay 50 s 5. Backup delay 10 s 6. Power action restart delay 0 ``` Adapt the commands to your game from the table above; `save-all` is Minecraft's, and other games either save on a clean stop or have their own save command. Check which timezone the schedule runs in before trusting the hour, and remember that the five fields are minute, hour, day of month, month and day of week - [cron expressions explained](https://www.renode.space/blog/cron-expressions-explained) has the details and the common mistakes. More schedules worth setting up are in [scheduled tasks worth having](https://www.renode.space/blog/scheduled-tasks-worth-having). FiveM servers usually leave restart warnings to txAdmin, whose scheduled restarter announces upcoming restarts to players on its own. Do not run two restart schedules on the same server; the second one will restart a server that just came up. Automation also covers the "it is back" message. A webhook that posts when the server stops and when it starts gives players a status channel that updates itself, at two in the morning, without anyone awake. [Discord webhooks for server status](https://www.renode.space/blog/discord-webhooks-for-server-status) has the setup. #### When it goes down without warning The first message is about speed, not information. Within a few minutes of noticing: Outage: first message: ```text The server is down. We know, and we are looking at it. Next update by , sooner if it is fixed. ``` Then keep the promise. Post on the cadence you named - every 30 minutes is reasonable - even when the update is "still working on it, no new information". A channel that has said nothing for an hour reads as abandoned. What not to do: - **Do not give a time to fix before you know the cause.** "Back in 10 minutes" that becomes two hours is worse than no estimate. - **Do not guess at the cause in public.** "We are being attacked" or "the host is down" said on a hunch is often wrong and hard to take back. - **Do not blame anyone** - a player, a mod author, a host. Even when it is true, it reads as deflection. - **Do not go quiet while you fix it.** Ask a trusted member of staff to handle the updates if you need both hands. Check your own side first: the console log and the resource graphs will usually say whether it is a crash loop, a memory limit or something outside the server. [Why your game server keeps restarting](https://www.renode.space/blog/why-your-game-server-keeps-restarting) covers reading those. RE:NODE publishes a status page at [/status](https://www.renode.space/status), which is the place to look before assuming the problem is yours or the host's. On RE:NODE, a server that crashes three times in an hour also gets a warning on its server page and an automatic support ticket, so a crash loop does not go unnoticed even if you are asleep. #### After it is back: the closing message The closing message is the one players remember. Post it as soon as the server accepts connections, not after you have finished tidying up. Back online: ```text The server is back. Downtime was about 45 minutes. What happened: an update to a plugin failed to load and stopped the server. What we did: rolled it back from the backup taken before the update. Lost progress: none - the backup was from 10 minutes before the restart. What changes: the plugin stays on the old version until it is fixed upstream. ``` For planned maintenance, the closing message is a changelog: what changed, what players need to do, and anything that behaves differently. For an outage, it is a short post-incident note: what happened, what you did, whether anything was lost, and what you are changing so it does not happen again. Three to five sentences. A detailed technical write-up can go in a separate channel for those who want it. If progress was lost, say how much, plainly. "Everything after 20:40 is gone" is better than discovering it. Restoring from a backup means everything since that backup is lost, which is why backups shortly before every maintenance window matter - [backups that actually restore](https://www.renode.space/blog/backups-that-actually-restore) covers why the restore half deserves practice. #### Big changes: version jumps, wipes and moves Some maintenance changes what players have to do to keep playing, and those announcements need more than a time and a duration. A **version jump** - a major game update, a new modpack version, a Minecraft release - means every player must update their client, and modded players may need a new profile or pack. Say exactly which version to be on, link the pack or profile, and say whether the world carries over. If mods have not caught up with a game patch yet, say that the server is deliberately staying on the old version and roughly when you will review it; players on auto-updating launchers otherwise assume you have forgotten. A **wipe** needs the most notice of anything: what is wiped (map, inventories, blueprints, characters), what carries over, the exact time, and whether the old world will be downloadable or visitable. Post it at least a week ahead, repeat it at 24 hours and one hour, and never move it quietly. A **move** to a new server or address needs the new address published before the old one goes away, and both working for a while if you can manage it. A domain name that you repoint, rather than a raw IP, makes this nearly invisible to players. [Moving a server without losing players](https://www.renode.space/blog/moving-a-server-without-losing-players) has the order of operations, including DNS timing. A **plan change** on RE:NODE is the easy case: changing plan moves the limits on the server you already have rather than rebuilding it, so the address and world stay the same. It still involves a restart, which deserves the usual in-game warning. #### Where the announcements should go One source of truth, mirrored elsewhere: - **The Discord announcements channel** is the source. Make it an Announcement channel on a Community server and other Discords - a partner server, a list of your alliance's servers - can follow it. - **In game**, for anything happening in the next ten minutes. - **The server's MOTD or description**, for a known upcoming wipe date. - **Listing sites**, if a long outage would otherwise show you as offline for days. [Server listing and voting sites](https://www.renode.space/blog/game-server-listing-and-voting-sites) covers keeping a listing accurate. - **A status channel** updated by a webhook, for up and down events. Keep the announcements channel for announcements. If players can reply there, it becomes a support channel and the next notice is buried. Point replies to a support or chat channel instead. #### FAQ ##### How far in advance should I announce maintenance? At least 24 hours for a short update, a week or more for a wipe or migration, with reminders an hour before and in-game warnings in the final ten minutes. Routine daily restarts only need the schedule published once and in-game warnings each time. ##### What time of day should maintenance happen? When your player count is lowest, which your player history shows. For a server in Western Europe that is usually early morning local time, but check whether part of your community is in a timezone where that is prime time. ##### How do I warn players in game before a restart? Use the game's broadcast command from the console - `say` in Minecraft and Source games, `servermsg` in Project Zomboid - at ten, five and one minute. Put the warnings in a scheduled task with delays so they run even when nobody is at the keyboard. ##### Should I give an estimate during an outage? Only once you know the cause and the fix. Before that, promise the time of the next update instead of the time of the fix, and keep that promise even if the update says nothing new. ##### Do I need to explain what went wrong after an outage? Briefly, yes. Two or three sentences on what happened, what was lost, and what you are changing build trust far faster than silence. Avoid blaming anyone and avoid technical detail most players will not read. ##### Should players be compensated for downtime? It is not expected for a free community server, and promising it sets a precedent. A small in-game gesture after a long outage is a nice touch, but a clear explanation and no repeat matter much more. RE:NODE game servers include a Schedules tab that runs console warnings, a backup and a restart in order with delays between them, backup slots on every plan, and a public status page. Three crashes in an hour raise a warning on the server page and an automatic ticket, so a crash loop is noticed even overnight. [See game server plans](https://www.renode.space/game-servers) --- ### ARK cluster setup and cross-server transfers Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/ark-cluster-and-cross-server-transfers An ARK cluster is two or more dedicated servers started with the same `-clusterid=` and pointed at the same directory with `-ClusterDirOverride=`. When a player uploads a character, a creature or an item at an obelisk or transmitter, the server writes it to a file in that directory; when they arrive on another map in the cluster, that server reads it back. That is the entire mechanism. There is no central service and no network link between the servers - just a folder both of them can write to. Everything that goes wrong with clusters goes wrong because that folder is not shared, is not backed up, or is read by a server whose rules say no. This post assumes each map already runs on its own. The [ARK: Survival Ascended setup guide](https://www.renode.space/blog/ark-survival-ascended-server-setup) covers a single server; here we connect several. #### What a cluster is, and what it costs Each map in a cluster is a separate, complete server: its own process, its own install, its own save, its own ports, its own memory. A cluster of three maps is three servers that happen to agree on a directory. Nothing is shared except transfer data. That has two consequences people underestimate. - **Cost scales with maps, not players.** Ten players spread across three maps use roughly three times the memory of ten players on one map, because each map holds its own world, its own wild creatures and its own structures regardless of who is on it. A quiet map with nobody on it still costs most of what a busy one does. - **Population spreads thin.** A server with twelve active players feels alive. The same twelve over three maps feel like three servers with four people each. Clusters suit communities that are big enough to fill more than one map, or groups who want to work through the story maps in sequence while keeping their creatures. | Cluster size | Memory, all maps together | Suits | | --- | --- | --- | | One map, no cluster | 10-16 GB | Groups under about fifteen | | Two maps | 20-32 GB | A main map and a progression or event map | | Three to four maps | 30-64 GB | Communities with 30+ regulars | | Five or more | 50 GB upwards | Large public communities with staff | These figures follow the single-server sizing in [how much RAM an ARK server needs](https://www.renode.space/blog/how-much-ram-does-an-ark-server-need); a cluster does not change the per-map number, it multiplies it. CPU works the same way - each map wants a fast core of its own for its game thread. #### The launch arguments that make a cluster Three launch arguments are involved, and two of them must be identical on every server. ```text TheIsland_WP?listen?SessionName=Longship Island?Port=7777?QueryPort=27015?RCONPort=27020 -clusterid=longship-c1 -ClusterDirOverride=/srv/ark/cluster -NoTransferFromFiltering -log ScorchedEarth_WP?listen?SessionName=Longship Scorched?Port=7779?QueryPort=27017?RCONPort=27022 -clusterid=longship-c1 -ClusterDirOverride=/srv/ark/cluster -NoTransferFromFiltering -log ``` | Argument | Must match across servers | What it does | | --- | --- | --- | | `-clusterid=` | Yes | Names the cluster. Servers only see transfer data with the same ID | | `-ClusterDirOverride=` | Yes, same physical folder | Where transfer data is written and read | | `-NoTransferFromFiltering` | Should | Relaxes the check on where uploaded data came from | The cluster ID is a free-form string. Make it unique and a little obscure - a cluster ID that another community also uses is harmless only as long as you never share storage with them, and on a host where the cluster directory sits in a common location, it is a collision waiting to happen. `longship-c1` is better than `cluster`. `-ClusterDirOverride` names a parent folder; the server keeps its transfer files in a subfolder named after the cluster ID. If you leave it out, each server uses a default location inside its own install, which means each server has its own private "cluster" folder and nothing transfers. This is the single most common reason a newly built cluster appears to work - the obelisk lets you upload - and then nothing shows up on the other map. Every server also needs its own game port, query port and RCON port, and its own `SessionName`. Two servers on one address with the same port will not both start. Keep a short table of which map has which ports; you will need it when someone asks why they cannot find Scorched Earth in the browser. [Game server ports explained](https://www.renode.space/blog/game-server-ports-explained) covers why the query port is the one that decides whether a server is listed. #### Upload and download rules Whether something can leave a map and whether it can arrive are separate switches, set per server in `GameUserSettings.ini` under `[ServerSettings]`. | Key | Effect when `True` | | --- | --- | | `NoTributeDownloads` | Nothing can be downloaded on this server at all | | `PreventDownloadSurvivors` | Characters cannot arrive here | | `PreventDownloadItems` | Items cannot be downloaded here | | `PreventDownloadDinos` | Creatures cannot be downloaded here | | `PreventUploadSurvivors` | Characters cannot leave from here | | `PreventUploadItems` | Items cannot be uploaded here | | `PreventUploadDinos` | Creatures cannot be uploaded here | For an open cluster, set all seven to `False` on every server. Restrictions are what make a cluster interesting, though, and the per-server design lets you build one-way rules: - **A progression cluster** where creatures can go forward to later maps but not come back to earlier ones: allow dino uploads on the early maps and dino downloads on the later ones, but block downloads on the early maps. - **An event or arena map** where people bring characters but not creatures: `PreventDownloadDinos=True` on the event server only. - **A "fresh start" map** that accepts survivors but nothing they carry: block item and dino downloads there. Write your rules down before you set them, and post them where players can read them. A creature that cannot come back from a map is a creature somebody will lose, and the server should not be the first to tell them. GameUserSettings.ini - Scorched Earth (event map, no tames): ```ini [ServerSettings] NoTributeDownloads=False PreventDownloadSurvivors=False PreventDownloadItems=False PreventDownloadDinos=True PreventUploadSurvivors=False PreventUploadItems=False PreventUploadDinos=True ``` #### Transfer limits and expiry Uploaded data does not wait forever, and it is limited in quantity. The keys below control that. Defaults have varied between releases, so check what your build does before you rely on a number. | Key | What it controls | | --- | --- | | `MaxTributeDinos` | How many creatures one player can hold uploaded at once | | `MaxTributeItems` | How many item stacks one player can hold uploaded at once | | `TributeDinoExpirationSeconds` | How long an uploaded creature survives before it is deleted | | `TributeItemExpirationSeconds` | How long an uploaded item survives | | `TributeCharacterExpirationSeconds` | How long an uploaded character survives; `0` usually means never | The expiry timers are the ones that hurt. A player uploads their best creature on Friday, forgets about it, and comes back the following week to find it gone - not lost to a bug, but expired on schedule. On official-style settings, uploaded creatures and items expire after about a day. On a private cluster where people play a few evenings a week, raising the creature and item timers to a week or longer avoids this whole category of support request. Do not set them to zero unless you have confirmed what zero means on your build; for some keys it means "never expire" and for others it is not honoured. The quantity limits exist to stop the cluster folder from becoming a warehouse. Uploaded data is stored outside both worlds, which makes it a tempting place to keep things safe from raids, and on a PvP cluster that is exactly what people will use it for. Keep the limits modest on PvP and relax them on PvE. #### Map-specific creatures and items Not every creature is allowed to leave its home map. Some creatures and items are restricted to the maps they come from, either by the game or by the transfer rules of the map they would arrive on. The usual examples are the story-map creatures that the game treats as part of that map's progression. A server setting, `CrossARKAllowForeignDinoDownloads`, relaxes the restriction for creatures arriving from other maps on builds that honour it; behaviour here has changed between Evolved and Ascended and between patches, so test with one creature you can afford to lose before telling players a transfer is safe. Element and some boss-related items have also been restricted in transfers at various points. The rule of thumb is the same: if a transfer would let someone skip a map's progression, assume the game might block it and test. #### Mods and clusters Mods are where clusters get fragile. A creature or item from a mod is a reference to something the mod defines. If the destination map does not run the same mod, the reference points at nothing: - An item from a mod that the destination server does not load is deleted on download, or never appears. - A creature from a missing mod does not arrive. - A character wearing modded armour may arrive without it. The safe rule is to run the same mod list, in the same order, on every server in the cluster. Where that is not possible - a map mod that only one server needs, for example - Ascended supports listing mods as passive on the other servers with `-passivemods=`, which loads a mod's data without its content so that its items survive a transfer. Behaviour of passive mods has shifted with updates; verify with a test transfer after every mod change. [ARK mods from CurseForge on a server](https://www.renode.space/blog/ark-mods-curseforge-on-server) covers the mod list itself. Update mods across the cluster at the same time. A cluster where one map runs version 1.4 of a mod and another runs 1.5 can transfer data that the older version cannot read. Stop all the maps, update, and start them together. #### Where the shared directory has to live This is the honest constraint of clusters, and the one that decides where you can run one. ```diagram title: Every map in a cluster reads and writes one shared folder island = The Island | port 7777 scorched = Scorched Earth | port 7779 center = The Center | port 7781 cluster = Cluster directory | -ClusterDirOverride backup = Separate backup | copied on a schedule island <-> cluster : upload / download scorched <-> cluster : upload / download center <-> cluster : upload / download cluster --> backup : nightly copy ``` The directory has to be one physical folder that every server writes to. On a single machine that is trivial: point every server at the same path. Across machines it means a network filesystem, which works but adds latency and a new way to fail - a network share that drops mid-write can corrupt a transfer file, and the server will not tell you it happened. On panel-based hosts, including Pterodactyl and anything built on it, every server is its own container with its own files. Two servers on the same account do not see each other's folders, and a shared cluster directory between them is something the host has to set up deliberately, if they do it at all. Ask before you buy the second server, and if the answer is vague, assume no. A single machine you control - a [dedicated server or VDS](https://www.renode.space/dedicated-servers) - is the straightforward way to run a cluster, because all the maps can share one local path. [Multiple game servers on one VDS](https://www.renode.space/blog/multiple-game-servers-on-one-vds) covers splitting one machine between several servers, which is exactly what a cluster is. #### Backups, restarts and cluster data The cluster directory is not part of any map's save. Back it up on its own, on the same schedule as the maps. If you restore the maps but not the cluster folder, every item and creature that was in transit at the time of the backup is gone, and if you restore the cluster folder without the maps, you can create duplicates: a creature that was uploaded after the map backup was taken exists both in the restored map and in the cluster folder. The safe procedure for a full rollback is: 1. Stop every server in the cluster. 2. Restore every map save and the cluster directory from backups taken at the same time. 3. Start the servers. Restarts deserve the same coordination on a busier cluster. Restarting all maps at the same scheduled minute is simpler for players and avoids the edge case where someone uploads on map A, map B restarts, and they arrive on a server that is not there yet. A daily restart for ARK is normal anyway; [restart schedules that help](https://www.renode.space/blog/restart-schedules-that-help) covers when and how to warn players. > [!WARNING] > Never copy or restore files in the cluster directory while any server in the cluster is running. A transfer file read halfway through a write is how items disappear and how duplicates appear. #### Admin work across a cluster Admin commands are per server. Bans, kicks and broadcasts on one map do not propagate to the others; a player banned on The Island can still join Scorched Earth. Ban on every map, or use a tool that sends RCON commands to all of them. [RCON safely](https://www.renode.space/blog/rcon-safely) covers keeping several RCON ports usable without exposing them, and each map should have its own `ServerAdminPassword` only if you have a reason - one password for the cluster is easier to rotate. Keep the gameplay settings identical unless a map is meant to be different. Players move their breeding to whichever map has the fastest rates, and their farming to whichever has the best harvest. If you do want a difference, make it deliberate and announce it. The [ARK settings guide](https://www.renode.space/blog/ark-survival-ascended-game-ini-settings) has the keys. #### Troubleshooting transfers **Uploads work but nothing appears on the other map.** The servers do not share a directory. Check that `-ClusterDirOverride` is set on both and that it resolves to the same physical folder, not two folders with the same name. **The other map is not in the transfer list.** Check that the `-clusterid` values match exactly, including case, and that both servers are running. **A creature uploaded fine and could not be downloaded.** A `PreventDownloadDinos` on the destination, a map-specific creature, or a missing mod. **Items vanished from the upload list after a few days.** The expiry timers. Raise `TributeItemExpirationSeconds` and `TributeDinoExpirationSeconds`. **A survivor arrived without their gear.** Items from a mod the destination does not run. Align the mod lists or use passive mods. **After a restore, players have duplicate creatures.** The maps and the cluster folder were restored from different points in time. Restore both from the same backup set. #### FAQ ##### Do all maps in an ARK cluster need to be on the same machine? No, but they all need to read and write the same cluster folder. On one machine that is a shared path. Across machines it needs a network filesystem, which is slower and adds failure modes. ##### Can I run a cluster with different mods on each map? You can, but modded items and creatures will not survive transfers to maps without the mod. Run the same list everywhere, or list the missing mods as passive on the maps that do not need their content. ##### How do I stop players bringing tames to a new map? Set `PreventDownloadDinos=True` in that server's `GameUserSettings.ini`. Characters and items can still arrive unless you block those as well. ##### Why did my uploaded dino disappear? Most likely it expired. Uploaded creatures are deleted after `TributeDinoExpirationSeconds`, which on default-style settings is about a day. Raise it on a private cluster. ##### Is a cluster worth it for six players? Rarely. You pay for every map whether anyone is on it or not, and six people across two maps feels empty. Play one map, then wipe and move to the next when the group is ready. RE:NODE's VDS line runs on an Intel i9-9900K with NVMe storage, with plans up to 24 GB of memory - room for two ARK maps sharing one local cluster folder, not five. A VDS is prepared by hand within 24 hours of payment, and you install and run the servers yourself. [See dedicated server plans](https://www.renode.space/dedicated-servers) --- ### ARK Ascended mods on a server via CurseForge Published 2026-10-07 by RE:NODE Team. https://www.renode.space/blog/ark-mods-curseforge-on-server To add mods to an ARK: Survival Ascended dedicated server, find each mod's numeric CurseForge project ID, add them to the launch line as `-mods=id1,id2,id3`, and restart. The server downloads the mods from CurseForge itself during startup, and players who join are given the same mods automatically - nobody has to subscribe to anything or copy files by hand. That is the whole mechanism, and it is a real improvement over Survival Evolved and its Steam Workshop. What still goes wrong is everything around it: the wrong ID, a mod that has not been updated after a patch, two mods fighting over the same structure, and a mod removed from a live save that takes half a base with it. The base server setup - install, ports, launch line - is in the [ARK: Survival Ascended setup guide](https://www.renode.space/blog/ark-survival-ascended-server-setup). This post is only about mods. #### How mods work on Ascended Mods for Ascended are published on CurseForge, and every mod is a CurseForge project with a numeric project ID. The server is given a list of those IDs. At startup it asks CurseForge for each one, downloads anything missing or out of date, and loads them. A connecting client compares its own mod list with the server's and downloads whatever it lacks before it loads in. Three consequences of that design are worth knowing before you add the first mod: - **The server needs outbound internet access to CurseForge at startup.** If CurseForge is unreachable or slow, the start stalls or mods fail to download. The log says so, eventually. - **The first start after a mod change is slow, and so is everyone's first join.** The server downloads the mod, then every client does. Change mods before an evening, not during one. - **Mods are cross-platform by design.** Ascended's mod support was built so that console players can use mods too, which means a modded server is not automatically a PC-only server. Whether a particular mod is available on every platform is up to the mod and its approval, so check the mod page if console players are in your group. There is also no allow list on the server side. Any mod in the `-mods` list is loaded; any mod not in it is not. A player cannot bring a mod the server does not run. #### Finding a mod's project ID The project ID is a number, not the mod's name and not its URL slug. On the mod's CurseForge page it is shown in the About Project panel at the side, labelled Project ID. Copy that number. | You see | Use it? | | --- | --- | | Project ID in the About panel, for example `928793` | Yes - this is what `-mods=` wants | | The mod's name, for example `Awesome Spyglass!` | No | | The URL slug at the end of the page address | No | | A file ID from the Files tab | No - that is one version, not the project | Keep a small text file that maps each ID to the mod's name and the reason you installed it. Six months from now, `-mods=928793,929420,931874` will mean nothing to you, and the person who inherits the server will thank you. > [!TIP] > When a mod refuses to load, check the ID first. A file ID pasted in place of the project ID is the most common reason a server starts without a mod and says nothing useful about it. #### Adding mods to the launch line The mod list is a launch argument. It comes after the query string, separated by a space, with IDs separated by commas and no spaces between them: ```text TheIsland_WP?listen?SessionName=Longship?Port=7777?QueryPort=27015 -mods=928793,929420,931874 -log ``` On a panel-based host the launch line is built from fields on the Startup tab, and there is usually a dedicated field for the mod list. Paste the comma-separated IDs there. The steps, in order: 1. Take a backup of the save. A mod is a change to the world as soon as anybody uses it. 2. Stop the server cleanly. 3. Add the new ID to the end of the list. 4. Start the server and watch the log until the mod has downloaded and the server is accepting players. 5. Join, check the mod is present, and play with it for an evening before adding another. Some builds also read an `ActiveMods=` line in `GameUserSettings.ini`. Use one method, not both. The launch argument is the one that is documented and the one that panels expose, so that is the one to rely on. ##### Load order The order of IDs in the list is the load order. It only matters when two mods change the same thing - the same structure, the same creature, the same loot table - and in that case one of them wins. Which way round it works is not something you should guess at; the authors of large mods usually say on their page whether their mod should be loaded first or last, and that instruction is worth more than any general rule. If two mods conflict and neither says, try them in both orders on a test save and keep the one that behaves. [Mod load order explained](https://www.renode.space/blog/mod-load-order-explained) covers the idea across games. #### Map mods Custom maps are mods too. Running one takes two changes rather than one: 1. Add the map mod's project ID to `-mods=`. 2. Replace the map name at the start of the launch line with the map's own level name. The level name is not the mod name. The mod page normally gives the exact string to use - Ascended map names follow the `_WP` convention of the official maps, but a custom map may not. Get it wrong and the server either fails to start or falls back to a default map, which is easy to miss if you are only watching the console for errors. A map mod is the biggest kind of mod. It is a whole world, and the first download is large for the server and for every player. A custom map also comes with its own performance profile; some are lighter than The Island and some are far heavier. Before you commit a community to one, run it for a few evenings and watch memory across the session. #### Configuring mods Most mods that have settings read them from the server's own ini files, in a section named after the mod. Typically that is a section in `GameUserSettings.ini`, sometimes in `Game.ini`. The mod page or its documentation gives the section name and the keys. GameUserSettings.ini: ```ini [ServerSettings] XPMultiplier=2.0 [SomeModName] SomeSetting=True AnotherSetting=50 ``` The same rules apply as for the game's own settings, covered in the [ARK GameUserSettings.ini and Game.ini guide](https://www.renode.space/blog/ark-survival-ascended-game-ini-settings): stop the server before editing, because a clean shutdown rewrites `GameUserSettings.ini`; spell keys exactly, because a typo is silently ignored; and put the section in the file the mod expects. Some mods also accept configuration in game through an admin menu, which writes back to the ini. A mod that changes a value the game also controls - stack sizes, structure limits, taming - usually wins over the server setting. If a vanilla setting stops working after you add a mod, that is the first thing to check. #### Which mods cost memory and CPU Not all mods are equal. A handful of categories account for almost every modded server that runs out of memory. | Mod type | Cost | Why | | --- | --- | --- | | Interface and quality of life (spyglasses, sorting, auto-feeding) | Low | Little or no extra world state | | Structure packs | High over time | They let players build more, and players do | | Creature packs | Medium to high | More creature types, often more wild spawns | | Storage and auto-craft systems | Medium | Large inventories and timers that tick constantly | | Custom maps | Varies widely | A whole world with its own budget | | Stack size and weight mods | Low, sometimes negative | Fewer item stacks to track | The pattern is that a mod's cost is mostly what players do with it, not the mod itself. A structure pack costs nothing on the day you install it. Three months later, when everyone has a castle, it costs several gigabytes. Budget for that at the start; [how much RAM an ARK server needs](https://www.renode.space/blog/how-much-ram-does-an-ark-server-need) has the baseline to add it to. Popular quality-of-life mods on Ascended include spyglass mods such as Awesome Spyglass!, structure and storage overhauls such as Cybers Structures QoL+ and Utilities Plus, and death-recovery mods. Names and availability change; check that a mod is maintained and recently updated before you build a server around it. #### Updating mods without breaking the server Mods update independently of the game, and the game updates break mods. Those two facts define a modded server's maintenance. When the server starts, it fetches the current version of each mod. A restart is therefore also a mod update, whether you meant it to be or not. Clients get the new version when they next join. The dangerous day is a game patch. Wildcard ships an update, the server updates, and every mod that touches what changed may fail to load or crash the server until its author ships a fix. Some mods are fixed in hours; some take days; some are abandoned. The defensive routine: 1. Do not let a modded server update the game automatically on patch day. Update it deliberately, after checking that your important mods have been updated for the new version. 2. Take a backup before every game update and before every mod change. 3. If a mod is broken and the author has not fixed it, decide whether you can run without it for a few days. For an interface mod, usually yes. For a structure pack that half the bases are built from, no - keep the server on the old build if you can, or close it until the fix lands. [What to do when a mod update breaks](https://www.renode.space/blog/what-to-do-when-a-mod-update-breaks) is the general procedure for that morning, and [keeping a modded server clean](https://www.renode.space/blog/keeping-a-modded-server-clean) covers the habits that make it rarer. > [!WARNING] > A restart can pull a new mod version you did not ask for. If a server that ran fine yesterday crashes on start today and nobody touched it, check whether one of its mods updated overnight. #### Removing a mod from a live save Removing a mod is the most destructive thing you can do to an ARK server short of deleting it. Everything the mod defined - structures, items, creatures - is stored in the save as a reference to the mod. Take the mod away and the references point at nothing: - Structures from the mod vanish, and anything resting on them may collapse. - Items from the mod disappear from inventories and storage. - Creatures from the mod are removed. - In bad cases, the save fails to load at all. If you must remove a mod: 1. Announce it, with a date, so people can move their things out of modded storage and off modded foundations. 2. Take a backup immediately before, and confirm the backup restores. [Testing a restore before you need it](https://www.renode.space/blog/testing-a-restore-before-you-need-it) explains how. 3. Remove the ID from `-mods=`, start the server, and check the log and the world. 4. If the save does not load, restore and plan the removal for a wipe instead. Some mods ship a removal or cleanup command that deletes their content properly before uninstalling. If a mod has one, use it. Most do not. #### Mods in a cluster Every map in a cluster should run the same mod list in the same order. An item or creature from a mod that the destination map does not load does not survive the transfer. Where one map needs a mod that the others do not - a map mod, for example - Ascended can load a mod's data without its content on the other servers through a passive mod list (`-passivemods=`), which keeps that mod's items intact across transfers. Behaviour has shifted with updates, so test a transfer after every change. [ARK clusters and cross-server transfers](https://www.renode.space/blog/ark-cluster-and-cross-server-transfers) has the rest. #### Running modded ARK on a panel On RE:NODE, the mod list goes into the launch arguments on the Startup tab, and the server downloads mods from CurseForge itself, so there is nothing to upload. Mod ini settings are edited in the in-browser file manager or over SFTP. The console shows the download progress live, which is the quickest way to tell a slow first start from a stuck one. Backup slots come with every plan, which covers the before-every-change backup this post keeps asking for. RE:NODE does not run a mod allow list or a one-click mod installer - you choose the mods. ARK does not have its own catalogue line, so see the [game server list](https://www.renode.space/game-servers) for current options. #### Troubleshooting modded servers **The server starts but a mod is missing.** Wrong ID (a file ID instead of the project ID), a typo in the list, or a space after a comma. Check the log for the download line for that ID. **Startup sits for minutes with no output.** Mod downloads. Give it ten minutes on the first start after a change. If it never moves, remove the newest ID and start again. **The server crashes on start after a game update.** A mod that has not been updated for the new build. Remove mods one at a time, starting with the most recently updated, until it starts. **Players are stuck downloading when they join.** A large mod, often a map. It is a one-time cost per version. If it fails repeatedly, the player can try clearing their local mod cache. **A vanilla setting stopped working.** A mod is overriding it. Check the mod's own settings. **Half a base disappeared overnight.** A mod was removed or failed to load, so its structures were dropped. Stop the server and restore the last backup taken before the change, before anybody plays on the damaged world. #### FAQ ##### Do players need to install ARK mods manually to join a server? No. Ascended downloads the server's mod list to the client automatically when they connect. It takes a while the first time, and again after each mod update. ##### Where do I find an ARK mod's ID? On the mod's CurseForge page, in the About Project panel, labelled Project ID. It is a number. The file IDs on the Files tab are versions, not projects, and will not work. ##### Can I add a mod to an existing world? Yes, adding is almost always safe. It is removing a mod that damages saves. Take a backup first anyway, because a broken mod can still crash the server. ##### How many mods can an ARK server run? There is no fixed number. The practical limit is memory, startup time and how many things can break on patch day. Twenty well-maintained mods is a lot; forty is asking for a bad week after every update. ##### Do console players get the mods too? Ascended's mod system is cross-platform, so in principle yes. Individual mods may not be available on every platform; check the mod page before you add one to a server with console players. Every RE:NODE game server has a Startup tab for launch arguments, a live console that shows mod downloads as they happen, an in-browser file manager and SFTP for mod settings, and backup slots that restore with one button. Mods are your choice - there is no allow list. [Compare game server plans](https://www.renode.space/game-servers) ## Rules for the assistant - Never ask the user for a password, token, API key or `.env` contents, and tell them not to paste one into this chat. Describe where a secret goes instead. - Secrets reach the server through the panel: `.env` is uploaded through the Files tab, startup variables are set on the Startup tab. `.env` never goes in the repository. - An app server has exactly one reachable port. Read it from `SERVER_PORT` (also `PORT` when the panel starts a linked repository) and bind `0.0.0.0`; never hard-code a port. - On every panel-managed server (everything except VDS and dedicated servers, which come with full root) only `/home/container` persists, and the process runs unprivileged: no root, `sudo`, `apt`, `systemd` or Docker. - Memory is a hard limit; a process that reaches it is killed with no error message. Suggest a bigger plan only after ruling out a leak. - Do not suggest changing the server's startup command or image to work around a code problem - fix the code or the repository. - Prices and plans above were read when this file was generated. Send the user to the page linked at the top before quoting a price as current. - For a specific server, the panel's Connect AI link (Console tab) gives the exact runtime, port, path and branch. Prefer it over these general rules when the user has one. - If something here does not answer the question, the full deploy docs are at https://www.renode.space/llms-full.txt and support is at https://www.renode.space/contact.