What happens to your server credentials

The desktop app connects to your game server directly from your own computer over SFTP/FTPS and RCON. There is no code path that uploads server credentials from the desktop build — cloud sync only happens if you sign in on the web and save a server there.

Those credentials live in the app's local configuration file, in your operating system's per-user application data directory. It is protected the same way the rest of your user account is: anything running as you can read it, which is true of most desktop application configs. If that matters for your threat model, full-disk encryption (BitLocker, FileVault, LUKS) is the control that helps, and you should treat the app's settings export the same way you would treat a password file.

When you save a server while signed in on the web, the SFTP password and the RCON password are encrypted before they reach the database, using AES-256-GCM with a fresh random initialisation vector for every value and an authentication tag that makes silent tampering detectable. The encryption key lives in the application environment, not in the database, so a copy of the database alone does not reveal your passwords.

The rest of the connection — host, port, username, plugin path, protocol — is stored as ordinary text, because the app has to show you what it is connecting to.

Worth being precise about: this is encryption at rest, not zero-knowledge encryption. The service decrypts your credentials in order to open a connection to your server on your behalf, which means the operator is technically able to read them. If you want a setup where nobody but you can read the password, use the desktop app.

No credential value is written to a log line. WebRCON connection URLs are actively redacted before anything is logged, because Rust's WebRCON puts the password in the URL itself and an unredacted URL in a log file would be a plaintext password in a log file.

There is also no third-party error-reporting or APM service wired into the application, so there is no external log sink for a credential to end up in.

Every host you enter is validated before anything dials it. Loopback addresses, cloud metadata endpoints, link-local and carrier-grade NAT ranges and private ranges are rejected, and every textual form of an IPv6 address is canonicalised first so an IPv4-mapped address cannot be used to slip past those checks.

Once a hostname resolves, the connection is pinned to the address that was actually validated, across SFTP/FTPS, TCP RCON and WebRCON. That closes the window where a hostname could resolve to a safe address during validation and a different one a moment later — so a hijacked DNS answer cannot quietly redirect your credentials somewhere else.

Every request that touches a stored server is scoped to the account that owns it — the database queries are filtered by user, not merely checked afterwards — and every credential-touching endpoint independently verifies your session rather than relying on page-level routing.

Endpoints that use credentials are rate limited (on the order of ten to twenty requests a minute each), which keeps them from being used as a connection-testing oracle.

The desktop app authenticates with short-lived access tokens that expire after fifteen minutes, backed by a refresh token that is stored only as a SHA-256 hash on our side and can be revoked server-side at any time. Where the operating system offers an encrypted credential store, the desktop app uses it for that refresh token.

Every product has edges. These are ours, with what each one means for you and what to do about it.

• Use a dedicated RCON password — Rust's WebRCON puts it in the URL. The protocol supplies the password as part of the connection URL, and most servers expose WebRCON over unencrypted ws://. That is a constraint of Rust's own RCON implementation rather than a choice we make, and it means the password crosses the network in the clear regardless of which tool you use. Pick an RCON password you use nowhere else, and prefer wss:// if your host offers it.
• SFTP connections are pinned but host keys are not yet verified. We validate the destination and pin the connection to the resolved address, which blocks the redirection attacks that matter most here. We do not currently check the server's SSH host key against a known value, so a party already positioned to intercept traffic between us and your host would not be detected by that mechanism. This is on the list to add.
• Signing in on a new browser sends your saved passwords to that browser. So the settings form can be prefilled without you re-typing credentials you already saved, the web app fetches them once over HTTPS on an authenticated, owner-only, rate-limited endpoint, and they stay in that browser's local storage while you are signed in. Switching accounts or signing out clears them. If you would rather they were never cached, use the desktop app, or sign out on shared machines.
• The desktop configuration file is not separately encrypted. As described above, it relies on your OS user account and whatever disk encryption you have enabled rather than on a second layer of its own.

• Give RCON a password you use nowhere else, so a leak stays contained to one system.
• Do not reuse your hosting panel password for SFTP — where your host supports it, create a separate SFTP user scoped to the plugins folder.
• Rotate credentials after sharing them with anyone, including after pasting them into a support thread. Never paste them into Discord.
• Treat the settings export as a secret. It is a convenience backup and it contains your credentials in readable form, which the export screen also tells you.

If you find a security issue, tell us on Discord before disclosing it publicly and we will work the fix. Please do not include real credentials, tokens or unredacted logs in a report — a description and steps to reproduce are enough.