Is it safe to put your Roblox cookie on a shared VPS?

What the cookie actually is

When you log into Roblox, the site hands your browser a session token stored in a cookie called .ROBLOSECURITY. Every request you make carries it, and Roblox trusts it as proof of who you are. That is convenient for you and dangerous in the wrong hands, because the token has three uncomfortable properties:

• It works without your password. Possession is the whole authentication.
• It works past two-factor authentication. 2FA guards the login step; an already-issued session token has cleared that gate.
• It stays valid until the session is invalidated - by you changing your password or signing out all sessions, not by time alone.

In other words: handing someone your cookie is closer to handing them your logged-in account than to sharing a username. Any farm that runs your account needs the cookie, so the real question is never "should I share it" but "where does it live and who can read it".

The shared-VPS trust problem

On a plain VPS - especially the cheap shared boxes common in the farming scene - your cookie is typically pasted into a config file, a launcher, or an account manager in plaintext on disk. That creates three exposures stacked on top of each other:

• The host is root. Whoever runs the machine can read anything on it, including your cookie file, at any time.
• Shared hardware widens the blast radius. If multiple customers sit on one box, a misconfiguration or a nosy neighbour is a real path to your file.
• No audit trail. You usually cannot see what touched your account, so a quiet theft looks identical to normal farming until the account is gone.

None of that requires the host to be malicious. It just requires you to be wrong about how careful they are, once.

The sealed-box model

The fix is to never store the cookie in a form the host can read. idlerig uses a sealed-box scheme (libsodium crypto_box_seal, X25519 keys) that works like this:

1. Your browser encrypts the cookie locally against the public key of the specific farm box that will run your account.
2. Only ciphertext is uploaded. The panel database and the CDN in front of it store nothing but the encrypted blob.
3. Decryption happens only on that one farm box, which holds the matching secret key on disk and nowhere else.

The practical result: the platform you uploaded through never sees a usable cookie, and neither does anyone inspecting traffic or database rows in the middle. The marketing version is "only your farm box can open it, we cannot" - and unlike most slogans, that one is a property of the cryptography rather than a promise.

What encryption does and does not protect

Be clear-eyed about the boundary. Sealed-box encryption removes two big exposures: the cookie at rest, and any middleman between your browser and the farm. It does not remove runtime trust - the cookie is decrypted in memory on the farm box at the moment a client launches, so a fully compromised running machine is still a risk. No host can honestly claim otherwise. What you are buying with encryption is the elimination of the easy, passive thefts, which are exactly the ones that happen most.

A checklist for any host

• Is the cookie encrypted before it leaves your browser, or pasted in plaintext?
• Can the host read your cookie from disk if they wanted to? If yes, you are trusting a person, not a system.
• Is your hardware shared with other customers' accounts?
• Can you revoke access yourself? (You always can - changing your password kills the cookie everywhere.)
• Is there any record of what ran on your account?