Subusers and least privilege: sharing a server safely

The usual way to let somebody help run a server is to give them the account password, which also gives them billing, every other server you own, and the delete button. Subusers exist so that the answer to "can you restart it" is not "here is everything". The model is simple enough to set up in five minutes, but the permissions are not all equally safe, and a few of them quietly hand over far more than their name suggests. This post goes through each group, the escalation paths people miss, four role definitions you can copy, and what to do on the day somebody stops being involved.

Why the account password is the worst option#

It is worth listing what actually travels with a shared password, because people underestimate it every time.

• Billing. Invoices, payment method, wallet balance, the ability to buy things.
• Every server on the account, not just the one the conversation was about.
• Deletion. Deleting a server deletes its backups with it, locked ones included. There is no undo and no copy left behind.
• Subuser management, which means they can add their own friends without telling you.
• Your second factor, or the ability to change your password out from under you if they get there first.

And two things you lose rather than give away. The first is attribution: every action in the log is you, so "who stopped it" has no answer. The second is revocation. Taking the access back means changing the password for everybody at once and re-establishing your own logins, which is why people put it off and why shared passwords outlive the friendships they were built on.

There is also a transitive problem. Your hosting is now as safe as their password habits, their laptop and whether they use a second factor. Two-factor on your panel account applies to them as much as to you, and you have no way to check.

Against all that, "restart the server when it hangs" is a single permission.

The permission groups and what each really allows#

Panels built on Pterodactyl group permissions the same way, though the exact names shift between versions. What follows is the grouping and, more usefully, the reason each one is bigger than it looks.

Two facts hold across all of them. A subuser can never be granted more than the account owner has, and billing is not a server permission at all - it lives on the account, so no subuser sees it under any configuration. Everything else is yours to decide.

The escalation paths people miss#

Least privilege only works if the permissions do what their names say. Several of these do not, and the combinations are where people get caught.

Schedules beat a console denial. A scheduled task can be a console command. If you grant somebody the ability to create schedules but not to use the console, they can still run any console command by scheduling it a minute out. Treat schedule creation as console access with a delay, because that is what it is.

Files beat almost everything. Whoever can write to the server's files controls the process the next time it starts. Replacing a plugin jar, adding a .dll to a mod folder, editing a Lua script or dropping a Python file into an app is code execution inside your container, with your network access and your file system. File access is the permission that deserves the most thought, and it is the one people grant most casually because "they just need to upload a plugin".

Backup download is exfiltration. An archive of the server contains every configuration file, which contains the database password, the RCON password, any API token, and on a bot the token itself. Granting create-and-restore without download is a coherent position; granting download is granting a copy of your secrets.

Startup variables hold real credentials. Several games need a credential of yours to install at all: a Steam game server token for CS2 and Unturned, a Cfx.re key for FiveM, a Klei token for Don't Starve Together, a BeamMP auth key. Arma 3, DayZ, Project Zomboid and 7 Days to Die need a Steam login, which is stored as typed - which is exactly why the advice is to use a spare Steam account rather than your main one. Anybody with startup access can read all of it.

Database password display. The panel shows the generated password on request. If the database is reachable from outside the panel, that is a direct connection from anywhere, forever, until you rotate it. Environment variables and secrets covers keeping these out of the places people look.

Allocations and reinstall. Adding a port lets somebody expose a service you did not put there. Reinstall, on many game images, replaces the installed files and is a very fast way to lose work if the person misreads a button.

Roles, teams and grants#

The model on RE:NODE separates three things that most panels mash together, and once it clicks it saves a lot of repeated clicking.

A role is a named set of permissions and nothing else: "Moderator" is console and power, with no idea who holds it. A team is a set of people and nothing else: "Staff" is five names, with no idea what they can do. A grant joins a role and a team to one server, optionally with an end date.

The payoff is in maintenance. Change the Moderator role once and every moderator on every server changes with it. Remove somebody from the Staff team and they lose access everywhere at the same instant, with no chance of missing the one server you forgot. People are invited by link, by join code or by email, and every server keeps its own activity log of what was done and by whom.

Access is per server, so somebody can help with the survival server without seeing the Discord bot, the database or the second Minecraft world you are testing on. That pairs well with the pattern in staging and production on one account, where the test server is where people are allowed to be careless.

Four roles worth copying#

Moderator, or the night shift. Console read and send, power start, stop and restart, activity read. Nothing else. This covers the overwhelming majority of what "can you help run it" means: restart it when it hangs, read the error, kick somebody, see what happened. No files, no backups, no startup.

The catch is that console commands are admin commands. On Minecraft, op is a console command, and so is whitelist add. On Garry's Mod, lua_run is a console command and it executes arbitrary Lua. Console access on a Source game is effectively total control of that game. Decide whether that is acceptable for this person before you grant it, and pair it with in-game permissions rather than assuming the panel is the only gate.

Plugin and mod administrator. Files, SFTP, backup create, power, console. Not backup delete, not backup download, not database password, not users, not settings. This is the person who installs and configures things, and it is real trust - see the file access point above. Make a rule that they take a backup before every change, which the create permission lets them do and the delete permission means they cannot undo.

Trusted co-owner. Everything except users, settings and backup delete. Those three are the ones that end things: inviting more people, renaming or reinstalling, and destroying the record of what the server used to be. Somebody can run the whole community day to day without any of them.

Contractor, or one-off help. Exactly the permissions the job needs, with an end date set to the length of the job. Take a backup before they start, so the worst case is a restore rather than an argument, and rotate the credentials they could have seen when they are done. Backups that actually restore is worth reading before you rely on that plan rather than after.

What you keep in every case: billing, server deletion, subuser management. Those three are ownership rather than administration, and there is no version of helping out that requires them.

Offboarding, which is the part everybody skips#

People leave communities. The access usually does not, because removing it is nobody's job and nothing breaks when you forget. A short checklist, run on the day rather than the month after:

1. Remove the person from the team, not just from one grant. A grant removed leaves them in the team and one click from being re-added by anybody with user permission.
2. Rotate the RCON password on every server they could reach. It is a shared secret, so removing their account does not remove their copy of it.
3. Rotate database passwords, and any API token or bot token that lived in a config file or a startup variable they could read.
4. If a Steam login was stored in a startup variable, change that Steam account's password. It was stored as typed, and they could read it.
5. Remove their in-game admin separately: ops.json on Minecraft, adminlist.txt on Valheim, users.ini for AMX Mod X, admins.cfg for SourceMod, the group in LuckPerms. The panel does not know about any of these.
6. Read the activity log for the last few weeks before you close it out, so you know what state you are in.
7. Take a backup and label it, so there is a known point from after the change.

Steps two to four are the ones that matter, because they are the access that survives the account being deleted.

The activity log and what to look for#

Every server keeps a log of actions taken on it: power actions, file writes, backup operations, startup changes, subuser invitations. Most of the time it is boring, which is the point - it is there so that the one interesting week can be reconstructed.

Things worth noticing when you do look:

• Power actions at hours nobody plays, especially a stop that was never followed by a start.
• File writes in the plugin or mod directory that do not match an announced update.
• A backup downloaded. There are legitimate reasons, and there is also only one reason that matters.
• Startup variables changed, which is where the credentials are.
• Subuser invitations you did not send.

The panel log answers "who", and the console log answers "what the server thought about it". Read them together - logs worth keeping covers which console output is worth retaining, and reading the console covers making sense of it.

What subusers cannot fix#

Permissions solve the panel. They do not solve the game, and confusing the two is the most common mistake here.

Shared secrets are shared. RCON passwords, database passwords, in-game admin passwords and server passwords are known by whoever has been told them. Removing a subuser does nothing to any of those, which is the whole reason the offboarding list exists. RCON, safely makes the case for not having an RCON password in circulation at all.

In-game permissions are a separate system. A player given /op on Minecraft keeps it after their panel access is gone, because it lives in ops.json on the server rather than in the panel. The same is true of a SourceMod admin entry or a LuckPerms group. LuckPerms groups and permissions and whitelists and permissions are the game-side half of this post.

A bot is an unauditable subuser. A Discord bot with admin commands is an account that anybody with the right role in Discord can use, and its actions appear in your logs as the bot. Scope what it can do the way you would scope a person.

Weak passwords elsewhere. A subuser account taken over is your server taken over, limited only by what you granted. That limit is exactly what least privilege buys you, and it is the argument for granting narrowly even to people you trust completely.

FAQ#

Can a subuser see my other servers?

No. Access is granted per server, so a subuser on one server has no visibility of anything else on the account, including its existence. This is the main reason to use subusers rather than a shared password even for people you trust.

Can a subuser see billing, invoices or my payment method?

No. Billing lives on the account rather than on a server, so it is not something a server permission can reach in any combination. There is no subuser configuration that exposes it.

Can a subuser delete the server?

Only if you grant the settings and deletion permissions, and there is almost never a reason to. Keep deletion, subuser management and billing to yourself; everything else can be delegated safely with the caveats above.

Is panel console access the same as being an admin in the game?

Effectively yes, on most games, because the console runs the server's own admin commands. Somebody with console access on Minecraft can op themselves, and on a Source game can execute arbitrary configuration. Treat console as a trusted role and use in-game permission systems for anything narrower.

Does changing my plan affect subuser access?

No. Changing plan adjusts the limits on the server you already have rather than rebuilding it, so roles, teams, grants and the activity log carry over untouched. The same is true of backups and files.

Can I give somebody access for just a weekend?

Yes. Grants can be time-boxed, so the access ends on its own rather than depending on you remembering. Pair that with a backup taken before the weekend and a credential rotation after it, and one-off help costs you nothing permanent.