vs. rustplusplus
Why Rust Pulse stores your Rust+ pairing token safely and rustplusplus does not.
Whenever this comes up, the headline answer is: Rust Pulse can't steal your Steam ID because Steam IDs aren't a secret in the first place. Your Steam64 is on every server roster, every Steam profile URL, every BattleMetrics page. Anyone who has ever played on the same server as you already has it.
What people actually mean when they ask is “can you steal my Rust+ login?” or “can you act as me in-game?” — and the answer there is no, because of how Rust Pulse stores credentials versus how rustplusplus stores them.
How login works
| Rust Pulse | rustplusplus | |
|---|---|---|
| Auth method | Steam OpenID 2.0 | OS user / file permissions |
| Sees your Steam password | No (Steam handles auth on their own page) | n/a |
| Session | Encrypted httpOnly, secure, sameSite cookie | n/a (CLI / Discord token) |
How Rust+ pairing tokens are stored
When you pair a server, the Rust+ app sends a notification through Google FCM that contains a playerToken — the long-lived secret that lets a client pretend to be your Steam account on that Rust server's Rust+ socket.
Rust Pulse:
- The
playerTokenand the FCM credential bundle are encrypted with AES-256-GCM before they hit Postgres. - The encryption key (
CREDS_ENCRYPTION_KEY, 32 bytes) lives only in the server environment and is never in the database. A database leak by itself yields opaque ciphertext. - The schema even labels these columns “ENCRYPTED — do NOT store raw” so future contributors can't accidentally write plaintext.
- The blob is decrypted in memory only when the relay needs to open a Rust+ connection on your behalf, then dropped.
- When you upload FCM creds, Rust Pulse rejects the upload if the Steam ID inside the payload doesn't match the Steam ID on your session — meaning even an attacker who hijacked your dashboard couldn't paste in someone else's Rust+ creds and re-bind them to your account.
rustplusplus:
- Stores credentials as plaintext JSON files on disk (
credentials/<steamId>.json). - Anyone with shell access to the machine running the bot can read those files: the host, the VPS provider, anyone who has ever SSH'd in, anyone with a backup tarball.
- Public / shared rustplusplus instances are particularly bad: the operator of that instance literally holds your
playerTokenand can sign in as you to the Rust+ socket whenever they want — turn off your turrets, read your team chat, fake messages from you, drain Storage Monitors. - There's no encryption, no key separation, no “decrypt only at the moment of use” behavior, no Steam-ID-match guard on uploads.
Other hardening Rust Pulse ships
| Surface | Rust Pulse | rustplusplus |
|---|---|---|
| Stripe webhooks | Signature-verified, replay-protected | n/a |
| Worker calls | Per-deployment HMAC X-Internal-Signature | n/a |
| Relay | Short-lived JWTs (~5min) | n/a |
| Device pairing codes | 10min TTL, max 3 outstanding, token returned once | n/a |
| Admin endpoints | Session + Steam ID allowlist; empty allowlist → 503 | n/a |
| Open redirect | Steam callback validates ?return= against allowlist | n/a |
When rustplusplus is the right choice anyway
- You want full control + you genuinely understand the credential risk.
- You're on a private VPS only you have access to.
- You don't need the dashboard, overlay, web push, Discord routing, BattleMetrics integration, or any other “everything else” Rust Pulse adds.
If you fit that description, run rustplusplus — it's a fine project. We just don't recommend it for everyone, and we definitely don't recommend public / shared instances of it.
One-sentence pitch
Rust Pulse uses Steam OpenID for login and AES-256-GCM with a server-side key for your Rust+ pairing token, so even a full database leak doesn't expose what an attacker actually wants — versus self-hosted bots that keep that same token in a plaintext file on whoever's computer is running them.