Rust Solo Duo Trio Server Setup: Define Group Rules
Set up Rust solo, duo, or trio rules with a clear group definition, native team-limit check, moderator evidence steps, and an appeal path.
You will need
- Access to a Rust PC dedicated server and its console or RCON
- A second Rust PC account or player for an invitation test
- A written rule page and a way for players to contact moderators
A Rust solo duo trio server setup needs two separate decisions: the native team setting controls a team’s size, while your written rule defines which players may cooperate across the whole server. Set a clear boundary for bases, roaming, raids, replacements, and outside help; then verify the native limit in a real invitation test. This guide gives you a policy worksheet and a fair review process without treating a console readback as proof that every kind of cooperation is blocked.
Separate the team cap from your group rule#
Rust’s native team-size convar controls the maximum size of a team and its authorization size, according to Facepunch’s server gamemodes reference. It is not the same as a community rule that says “solo only,” “duos,” or “trios.” Facepunch’s documentation does not say the setting prevents two separate teams from helping each other, trading, sharing a base, or coordinating a raid. Treat those as policy questions you must answer in public rules.
| Control | What it defines | What it does not establish |
|---|---|---|
| Native team-size setting | Maximum members and authorization size for one team | Whether separate teams may cooperate under your server rules |
| Server rule | The conduct your moderators will permit across the server | Automatic blocking by the game or every plugin |
| Moderator review | How reports are evaluated and decisions are made | A reliable verdict from a single screenshot or a player’s proximity |
This distinction also helps you explain what the number means. A trio setting is a technical boundary for one team, not proof that exactly three people can take part in every activity or that a fourth person can never help. The Rust server settings guide covers persistent configuration practices; use it for general file handling, then verify the team behavior for your own server version.
If your goal is a private world for a fixed pair of friends, public group enforcement may be unnecessary. A private duo world is a different access and play-design problem. This guide is for an open community where players can meet, report possible teaming, and expect the same rule to apply to everyone.
Define which players count as one group#
Before changing a setting, describe the behavior that makes players one group under your policy. “No more than three in a team” is easy to count in the team UI, but it leaves unanswered whether a fourth player may live in the same base, guard a raid, hand over gear, or join after a teammate leaves. Add these cases to your rules before players encounter them.
| Activity | A useful policy question |
|---|---|
| Team membership | Is the limit based on current team membership, or on a wider regular group? |
| Base access | May players outside the counted group share doors, tool cupboards, beds, or storage? State what you will enforce and how. |
| Roaming and fights | Can two groups travel together, call targets, or fight the same opponents? Is temporary defense an exception? |
| Raids and defense | Can non-members scout, supply, guard, or participate in a raid? What about defending a shared event? |
| Trades and handoffs | Are ordinary trades allowed? Does repeated equipment or resource support change the answer? |
| Replacements | When a player leaves, can another take the open place? Can the former member continue helping the group? |
Do not copy a rule such as “no alliances” and leave “alliance” undefined. A player may reasonably read it as banning all trade, while a moderator may only mean coordinated combat. Write observable examples: “Players may trade at the safe zone, but two separate teams may not coordinate a raid against the same base.” Then list exceptions and whether players must disclose them.
Keep the rule no broader than your staff can apply. If moderators cannot distinguish an allowed handoff from prohibited repeated support using information available in a report, narrow the rule or explain what additional evidence is needed. A short enforceable policy is easier to moderate consistently than a long list of vague prohibitions.
Publish a boundary players can check#
Write your mode name and examples together. Players should be able to tell before joining what the cap means and what behavior crosses the line. A community can choose different definitions; the table below is a worksheet, not an official Rust definition or a tested server preset.
| Mode label | State explicitly | Example that needs a ruling |
|---|---|---|
| Solo | Whether a player may receive normal trades or temporary defense from another player | A friend drops building materials after a raid |
| Duo | Whether a regular third player may share base access or join fights | One teammate is offline and a replacement joins |
| Trio | Whether a fourth person may scout, call targets, or supply a raid | Two trios agree to attack the same group |
For every example, say what is allowed, what is prohibited, and whether the case needs moderator review. If you permit a temporary exception, define its scope: who may help, for what event, and when it ends. Avoid making “offline,” “new player,” or “emergency” a loophole with no time limit.
Publish the rule where new and returning players can find it, and add a date or version. When you change a wipe’s policy, keep the old wording long enough for staff to identify which version applied to a report. A policy page with a contact route is more useful than a server title that only says “trio,” because the title does not tell players how replacements or cross-team help work.
Verify the native cap in the running server#
Facepunch documents relationshipmanager.maxteamsize <value> as the setting for maximum team and authorization size. It does not document a universal default in that reference. A current isolated Rust Dedicated Server build (25797215) loaded a configured value of 3 from server.cfg, reached startup complete, and returned relationshipmanager.maxteamsize: “3” through local RCON. That verifies the file value loaded and could be read back; it does not verify that the client rejects a fourth invitation.
Use this as a verification sequence, not as a substitute for the operator-side test:
Set the intended value in the active identity
Add the setting to the
server.cfgfor the identity your process actually starts. For a trio, the line is:text relationshipmanager.maxteamsize 3Follow the current Facepunch dedicated-server configuration reference for the file location. If you edit a different identity’s folder, the running process may not load your change.
Restart and read the setting back
Restart the server if needed to load the file, then query the value from the server console or authenticated RCON. Confirm the response matches the policy you intend to test. A matching response proves the configured value is active enough to report; it does not prove a player invitation will be rejected.
Test membership with real clients
With an authorized test group, invite players until the configured boundary is reached, then test one more invitation. Confirm the client-visible result, check existing members after changing the setting, and repeat after a restart if persistence matters. Do not use a live community’s members for an unannounced test.
Record what the test covered
Note the game build, server build, identity, configured value, test date, and observed invitation result. Keep that record separate from your broader alliance rule: the membership test does not establish whether other teams can coordinate under your policy.
Review reports with repeatable evidence#
A report should identify the rule, approximate time, players involved, and activity in question. Give moderators enough context to check a sequence, not only an accusation. A screenshot can help establish what appeared on one player’s screen, but it may omit what happened before and after. Proximity, shared combat, or a trade alone should not be treated as proof unless your published rule explicitly makes that conduct a violation.
| Review item | Record | Avoid concluding from it alone |
|---|---|---|
| Timeline | Date, time zone, server event, and sequence of reported actions | A clip with no surrounding events |
| Identity | In-game names or identifiers your staff is authorized to review | Similar names or a player’s guess about an account |
| Context | Which mode rule may apply and what exception was considered | “They looked grouped” |
| Corroboration | Independent reports, relevant logs, or additional context available to staff | A repeated copy of the same unsupported claim |
| Decision | Rule version, evidence relied on, action, and reviewer | A public accusation or staff chat excerpt |
Use only records your staff can legitimately access, and set a retention period that fits your community. Do not ask players to publish private messages or personal details in public channels. Keep the original report available to the review team, limit access, and tell the reporter how to add information or appeal.
When evidence is incomplete, mark the report inconclusive or ask a focused follow-up question. This is better than turning a vague rule into a penalty after the fact. If an automated tool is part of your workflow, verify its current author documentation, supported server version, detection scope, and behavior yourself before relying on it; this guide does not recommend a particular plugin or claim automated detection works.
Apply decisions and appeals consistently#
Choose an escalation policy before the first report. For example, your staff might use a private clarification for a first unclear incident, a documented warning when evidence supports a minor first violation, and a defined temporary restriction for a repeated or serious violation. Those are policy options, not a universal penalty ladder. State who can issue each action, how long it lasts, and what evidence makes a case eligible.
For each decision, send the player a concise notice with the rule version, behavior found, action taken, duration, and appeal route. Do not reveal another player’s report or private identifiers. Have a second moderator review serious or disputed sanctions when staffing allows. If the same behavior receives different outcomes, record the reason for the distinction and adjust the policy if moderators are interpreting it differently.
An appeal should go to a moderator who was not the sole decision-maker when possible. Ask the player to identify a factual error, missing context, or inconsistent application; set a reasonable response window and tell them when a decision is final. Keep the appeal record linked to the original case so staff can see both the evidence and the reasoning. An appeal is a quality check on moderation, not a promise that every action will be reversed.
Recheck the policy after a wipe or staff change#
At each wipe, review the mode name, team setting, replacement rule, exceptions, and report route together. A configuration change can make a previously accurate server description misleading; a policy change can also make old moderator macros inaccurate. Ask one person to compare the live value and public rule, then ask another to test the invitation boundary if a client test is available.
Keep a simple change record: date, previous wording, new wording, reason, and who approved it. If the policy changes mid-wipe, announce the effective time and apply the new rule only after that notice. When a player asks whether something is allowed, answer with the relevant rule and example, then update the public wording if staff needed to improvise.
A reliable solo, duo, or trio community depends on a clear social boundary, a separate check of the native team limit, and a review process players can understand. Start with the activities you can actually moderate, test membership behavior with your own clients, and revise unclear examples before they turn into inconsistent penalties.
Quick answers
Does Rust's team-size setting stop separate teams from cooperating?
No. Facepunch documents the setting for the maximum team and authorization size; it does not document a rule against cooperation between separate teams.
Can a trio server allow trades with another team?
Yes, if the published policy permits trading and moderators apply the same boundary to everyone.
What evidence should moderators review for a teaming report?
Review a dated sequence with context and corroboration; proximity or one screenshot alone does not establish a rule violation.