A world built for the long game
Vintage Story rewards patience more than most survival games. Knapping your first tools, finding copper, surviving a winter and building something worth defending all happen over weeks rather than an evening, and that only works if the world is still there when everyone logs back in. A dedicated server keeps one persistent world running around the clock, so nobody has to be online first and progress belongs to the group rather than to whoever happened to host.
Running it yourself means a machine that never sleeps, .NET on the right version, and forwarding port 42420 over both TCP and UDP through a router you may not control. GHosting installs the official x64 Linux server in its own container with a fixed address to share and both protocols already open.
Native Linux server, native Apple silicon client
Vintage Story publishes a proper Linux dedicated server rather than a Windows build wrapped in a compatibility layer, which is why it is an unusually clean game to host. The server GHosting installs is the official stable x64 Linux archive from Anego Studios, checked against the checksum the release feed publishes before anything is unpacked.
On the player side the game ships builds for Windows, Linux and macOS, including Apple silicon, so a mixed group can share one world without anyone needing a second machine. Connecting is by address, so what you share is the line on your dashboard and the join password.
Bringing a world across, and why the extra files matter
A Vintage Story world is one .vcdbs file, and it is a SQLite database rather than a plain save. That single detail decides how you move one safely. Stop both the source and the destination first, then copy only the .vcdbs file. Its -wal and -shm companions are live database state, so copying one on its own, or copying while something has the world open, is how a world arrives corrupted.
Upload it to the Saves folder through Files, or over SFTP when it is larger than the browser upload allows, then either name it default.vcdbs or point the save path at it while the server is stopped. Advanced world generation belongs in the client: create the world you actually want there, play it far enough to be sure, then bring it over and start it once to check inventories, claims and spawn before you delete the original.
Mods without a modpack manager pretending to be one
Mods go in the Mods folder in your data directory as ZIP files, uploaded through Files or SFTP, and you do not unpack them. The panel keeps runtime files and your data separate, so a managed version update replaces the server binaries and leaves your world, mods, mod configuration, player data and backups exactly where they were.
The honest scope: Vintage Story documents that Server and Universal mods can be handed to joining clients automatically, while Client-only mods stay each player's own job. There is no one-click ModDB catalog in the dashboard at launch, because a mod installer that does not understand dependencies and version pinning creates more broken worlds than it fixes. GHosting runs the server and gives you full file access; it does not promise to debug an arbitrary third-party modpack or repair a world a mod has damaged.
- Server and Universal mods: upload the ZIP, restart, players are offered it
- Client-only mods: each player installs their own
- Always take an offline backup before changing versions or the mod set
Passwords, whitelists and who gets in
New servers start with a join password and the whitelist off, so your group can connect the moment the server is up without anyone learning console commands first. That default is deliberate: since game version 1.20 a dedicated server treats the Default whitelist setting as invite-only, which is why a self-hosted server so often looks broken on the first evening when nobody can join.
When you do want a whitelist, switch the setting to Default or On and add players by their exact Vintage Story account name from the Console tab. Player authentication is always enforced, so everyone joining owns the game and is logged in. Public listing on the master server is a separate switch, so a private world stays unlisted while a community server gets found.
Managed versions, and why old builds are not on the menu
Every new server installs the current stable release GHosting has selected, and the dashboard shows which version is running. Updates replace the installation files rather than extracting a new release over the old one, which is what upstream asks for, and your data directory is never part of that swap.
Pre-release, release-candidate, legacy and ARM builds are out of scope, and so are downgrades. A world, its mods and every player's client all have to agree, and an arbitrary version field is the fastest way to a world that no longer opens. Version changes are a controlled rollout instead, so the server, the world and the mod set move together.
Regions, and what prepaid actually means
Pick Europe or North America based on where most of your group plays. Vintage Story is more forgiving of distance than a shooter, but a long route shows up in combat and in how responsive block placing feels once several people are building at once.
Terms are prepaid and nothing renews on its own. When a term ends the server stops and your files are kept while you decide, rather than the card being charged again quietly. That fits a game people return to in bursts around each content update. Renew inside the seven-day grace window and the same world comes straight back; past that the server is deleted, so download the .vcdbs file before a long break. Your first server is covered by a 72-hour money-back guarantee.