How to Run a Vintage Story RP Server: A Setup Guide

Vintage Story has no separate roleplay mode, so a Vintage Story RP server is a shared world shaped by your group’s rules, staff and optional mods. Start with the kind of story you want to tell, then choose a world that supports it, decide what game roles can do, and agree how players join and resolve disputes. That order matters: a preset can disable a protection system your community expected, while a mod can add maintenance work for every client. This guide helps you plan those choices before you open applications.

Decide what roleplay means for your group#

Write a short premise before changing server settings. Is this a light roleplay community where people mostly play survival and use character names, or a stricter setting with in-character speech, factions and scheduled events? Neither style is built into a special Vintage Story server type. The game supplies a world and multiplayer controls; your community decides what behavior counts as roleplay and how firmly it is enforced.

Keep the first version of the rules small enough that new players can follow it. Define:

What players should do in character, and where out-of-character conversation belongs.
Whether conflict, theft, PvP or settlement expansion need consent.
How a player asks for help, reports a dispute or appeals a moderation decision.
Which events need staff, and what happens if a moderator is unavailable.

Use a Discord server or another community space for applications and announcements if your group wants one. Those are community tools, not Vintage Story features, and a Discord role does not grant an in-game privilege. A one-page handbook is easier to maintain than a long list of rules nobody can find. Add detail when a real question or dispute shows where the first draft is unclear.

Choose a world preset that fits the story#

Vintage Story’s presets change the experience for everyone, so agree on the world before inviting the group. The right choice depends on whether your story needs the game’s existing lore, temporal mechanics, survival pressure and land-claim system.

Starting point	What to consider for RP	Check before players settle
Standard, with selected changes	A flexible base when your group wants survival, world lore or temporal events alongside its own story	Review the multiplayer world options and agree which shared mechanics remain enabled
Homo Sapiens	Its current source metadata disables lore content, temporal stability, rifts, storms and land claiming	It may suit a grounded story, but claims are off in this preset; verify the world setting if you rely on them
Another customized world	Useful when the story needs a specific pace or fewer survival systems	Record each change so staff can explain what players should expect

The official Homo Sapiens preset metadata lists those settings; calling it simply “the no-magic preset” misses other changes. If protected settlements matter, do not assume claims are enabled. Check the current multiplayer world-settings reference and verify the options for the actual game build before creating a long-term world.

Avoid settling important choices after players have invested in a map. If you later change a world or mod, make a separate copy first and confirm that you can retrieve and recover it. A backup entry is useful, but its presence alone does not prove that a particular save can be restored.

Separate in-game powers from community staff roles#

Vintage Story’s server roles control in-game privileges. Your community’s moderator, storyteller or application-review roles control people and process outside the game. Keep those systems separate: a person who can review an application does not automatically need admin access in the world. For the configuration file and exposed controls, see the Vintage Story server-config reference.

Start with the least access each job needs. Give full in-game administration to a small number of trusted owners. If moderators need to help with ordinary disputes, check the current role and privilege options on your server before granting broader powers. The default names and command examples on older wiki pages can lag behind the current release; use the server’s own /help output and the tested Vintage Story server-command reference for exact syntax.

For a private RP community, make the joining path clear before recruiting. Tell applicants which Vintage Story name to provide, who approves access and where they will receive connection details. Dedicated servers use a whitelist by default in current documented versions, but a whitelist is only a gate: it does not screen people for you or replace a conduct policy. Keep player authentication enabled. Each player needs their own Vintage Story account, and account sharing or disabling authentication is not a safe workaround for a login problem.

Set land claims around your settlement rules#

Claims can protect player-built areas, but the technical limit is only part of the policy. Decide how players can claim a home, how a settlement shares workshops and roads, whether a guild can reserve common space, and how staff handles abandoned or disputed claims. A rule such as “keep paths open and ask before building against another settlement” may prevent more conflict than simply raising claim allowances.

If you are still choosing where to run the world, compare resources and provider controls in this community-server hosting guide; this page stays focused on the RP setup itself.

Vintage Story exposes world-level land-claim behavior and role-related claim settings. Their exact controls and defaults can vary by game version and world preset; the older server-configuration wiki page marks its sample defaults as last verified for 1.20.0. Do not copy those numbers into a 1.22.7 server as if they were verified current values. Check the live game’s role and configuration help, and review the world-settings reference before the group commits to a map.

Test the policy with a few trusted players. Confirm that the group understands which areas are private, which are shared, and how a visitor can reach a public road or event space. If claims are disabled by the chosen preset, either enable the supported world option before launch or write a clear alternative protection policy. Do not promise that a mod or claim setting settles every disagreement; staff still needs a consistent way to review one.

Add class mods only after checking the release#

Mods can give characters different jobs or change how a community plays, but every addition becomes part of the server’s upkeep. Vintage Story’s catalog is the official ModDB, not Minecraft’s catalog or Steam Workshop. Before adding a class mod, check its latest release for the exact game-version tag, whether it runs on the server, client or both, required dependencies, and the author’s notes.

For one current example, the ModDB lists Aldi’s Classes by Aldi, release 2.4.0, for Vintage Story 1.22.0–1.22.7, with its side marked “Both.” That is a catalog compatibility tag, not a test of your server’s whole mod list. Aldi’s separate Aldi’s Classes RP Patch was tagged only through 1.22.3 when checked on October 13, 2026, and the page warns it may be outdated on 1.22.7. Do not treat the patch as current just because the base class mod has a newer compatible release.

Since Vintage Story 1.16, the official mod guide says a server can offer required server-side and universal mods to players when they join. That does not install every client-only mod for everyone. Tell players what they need to check locally, and keep a short release list with each mod’s author and version. For the install workflow and file locations, use our Vintage Story ModDB server guide.

Start with one or two additions on a test copy, not the full planned pack on the only world. Before changing the live list, verify the backup is complete, that you can download it, and that you know how to restore it without overwriting the wrong save. Then check the server starts, the expected world loads and players can join with the required mod files. We have not tested this particular mod combination, so do not assume a version tag guarantees compatibility with every other mod.

Build applications and moderation outside the game#

An RP server needs a repeatable way to bring in players and handle problems. If you use applications, ask only for information that helps the group decide whether the setting and rules fit. Explain who reviews them, when a player should expect an answer and what information stays private. Avoid turning a small community into a form-filling exercise before anyone can understand the story.

Keep the operational decisions visible to staff. A short handoff note can record the current server version, mod list, who can administer the game, where the latest backup lives and who can contact the host. Publish rules where new players can find them, and give moderators a process for warnings, removals and appeals. The exact policy is yours; a game ban or whitelist removal is not a substitute for explaining why access changed.

If you use Discord for lore, applications or event notices, keep an in-game channel or notice board for people who do not use it. Tell players how out-of-character questions work during a scene. A consistent boundary between story and staff discussion makes it easier to resolve a rule issue without turning it into an in-character conflict.

Size the world and protect it without guessing#

Anego’s self-hosting guide gives a rough starting estimate of 1 GB plus 300 MB per player, and notes that players spread across more of the world can increase demand. That is not a per-settlement multiplier or a promise that a given plan will handle a particular map, mod list or population. Track the server’s actual memory use as the group explores, and use the separate Vintage Story RAM guide for the assumptions behind that estimate.

Protect the save before you change the world or update its mods. Vintage Story world files use SQLite; stop the game or server before copying its save, and preserve the complete copy rather than treating a lone .vcdbs file as proof that every recent change is included. The official data-folder reference describes the .vcdbs-wal and .vcdbs-shm sidecars. Keep your original copy until the changed server has started, the expected world is present and someone has confirmed that the group can join.

If the organizer would rather not keep a home machine and network running, a managed server is another route. Game Hosting’s Vintage Story page lists memory by plan and a panel with world settings, player controls and ModDB tools. A host can move process and panel upkeep off a member’s PC; it cannot guarantee that a particular mod combination or community rule will work as intended.

Run a small first session before opening the doors#

Invite a few trusted players before you publish a public recruitment post. Check that each person has a supported PC and their own account; the current official requirements list 64-bit Windows 10 or newer, macOS 13 or newer, and Linux. They do not list a console client. The official stable feed listed 1.22.7 when checked on October 13, 2026; use the live feed again before launch, and keep clients and server on compatible releases. Vintage Story 1.22 servers and macOS/Linux clients require .NET 10 according to the official requirements and dedicated-server guide.

Use that first session to check the experience, not to claim a performance result. Confirm that invited names can get through the access rules, staff can handle a basic moderation question, the map and claims match the handbook, and everyone sees the right required mod list. Ask players where the rules were unclear and make one controlled change at a time. If you change world or mod data, preserve and verify a recoverable copy first.

Once the group agrees that the world, rules and staff process match the promise in the recruitment post, open the next application round. For a broader view of connection methods and account prerequisites, start with the Vintage Story multiplayer guide. It covers how the group can play together; this page focuses on the decisions that make an RP community easier to run.

Sources checked October 13, 2026

Quick answers

How do you start a Vintage Story roleplay server?

Start by choosing the kind of story and survival rules your group wants, then configure a world, access roles and any compatible mods around that agreement. Vintage Story has no separate RP mode; the community supplies the lore and conduct rules.

Which Vintage Story world preset works for roleplay?

There is no universal best preset. Homo Sapiens disables lore, temporal mechanics and land claiming, so choose or customize a world that matches the group’s story and protection needs.

How should an RP server handle staff roles and land claims?

Keep the small group of in-game admins separate from community moderators, and decide how claims should protect homes, shared areas and travel routes before players build. Check current role and command syntax on your server version.

Which class mods work with Vintage Story 1.22.7?

Check the current ModDB release page for game-version tags, side and dependencies. When checked on October 13, 2026, Aldi’s Classes 2.4.0 was tagged for 1.22.0–1.22.7; that tag is not a test of your full mod combination.

How much RAM does a Vintage Story RP server need?

Anego’s rough starting estimate is 1 GB plus 300 MB per player, with more demand when players explore far apart. It is not a per-settlement formula or a performance guarantee; see the separate RAM guide for sizing caveats.