Permissions
IgniteSky keeps its permission surface deliberately small. The everyday /is commands need no permission at all, so a fresh install is playable by everyone the moment it loads. What a player is allowed to do on an island is decided by their island role (see Members & Roles), not by server permissions. The nodes below are only for operators and for letting trusted staff step outside the normal rules.
Nodes
| Node | What it grants |
|---|---|
ignitesky.admin | Every /is admin command, and a bypass of island protection so staff can build and break anywhere |
ignitesky.bypass.spawn | Build inside the protected spawn radius |
ignitesky.bypass.restrictions | Ignore the configured island restrictions (see features/qol.yml) |
ignitesky.bypass.commandrules | Run commands that the command rules feature otherwise blocks |
Most skyblocks scatter dozens of per command permission nodes. IgniteSky moves those decisions into island roles instead, which is where they actually belong: the owner controls who can do what on their island, and the server only steps in for staff overrides.
Giving an operator full access
Grant ignitesky.admin to your staff group. That single node opens the entire /is admin toolkit and lets them work on any island for moderation. Pair it with the bypass nodes only if those staff also need to ignore spawn protection, restrictions or command rules.
Roles, not permissions, for island actions
When you want to control whether members can build, withdraw from the bank, set warps and so on, edit the roles in islands/roles.yml or use /is permissions <role> in game. Server permission nodes do not gate those; the per island role system does, so two islands can have completely different rules. The Members & Roles page covers this in full.