Own server or rented? What the difference actually is

The short answer

For most people a rented server is the right choice. It runs around the clock without anyone leaving a machine on, it has a decent connection, and setting it up takes minutes rather than an evening.

Your own server pays off in three cases: when you want to test without disturbing players; when you need access to every log file; or when you hit the limits of what your provider allows.

The decisive difference is not performance but access. What you can configure is the same file either way – you simply reach it differently well.

Where the files live

A SCUM server is driven by text files, and on every server they sit in the same place: the subfolder SCUM/Saved/Config/WindowsServer/. That holds ServerSettings.ini with its 437 values, alongside the JSON files for economy and raid times and the plain text lists for admins, bans and whitelists.

On your own server that folder sits in the installation directory you chose yourself. You open the file in a text editor, change it and restart the server.

On a rented server you normally reach the same file two ways: through an input form in the provider's web panel that exposes the common values as fields, and through a file manager or FTP access that lets you edit the file directly.

The form is convenient and covers a fraction. With 437 values it is obvious no provider maintains them all as fields – the rarer settings are only reachable through the file. Anyone configuring seriously ends up working on the INI directly sooner or later.

The one rule that applies to both

Stop the server, edit, save, start.

SCUM writes its own settings back into the file when shutting down. Edit it while the server is running and you lose the change the moment the server next stops – and then wonder why nothing happened.

This is by far the most common mistake when setting up, and it hits both kinds of hosting equally. With the provider's input form the panel usually handles the order for you; editing the file directly, you have to remember it yourself.

What you cannot do on a rented server

Choose your ports. Game port, query port and RCON port are assigned by the provider. That is rarely a problem – until you want to use a tool that has to reach one of those ports from outside.

We tested exactly that for this project: on the GPortal server we checked, the query and RCON ports are filtered from outside. They do not answer although they are listed in the panel. Remote control over RCON and the usual status query therefore do not work there – that is not a misconfiguration but how it is set up. If you plan to use an administration tool, ask beforehand whether your provider opens those ports.

Read every log file. SCUM writes quite a number of them. Which ones you get to see is decided by the provider's file manager. If you want to settle disputes about raids or chests, that is where it can get awkward.

Install extensions. Anything that reaches into the game directory needs access to that directory.

Influence the hardware. How much computing power your server gets is part of the plan. When performance suffers you can adjust settings – and that is all.

What your own server costs

Not money but attention. The installation itself is unremarkable: download SteamCMD, log in anonymously and fetch application 3792580. That is around 18 gigabytes; the rest is waiting.

What comes afterwards is the actual work. The server needs reliable reachability, so either a fixed address or a service that keeps it current. It needs open ports in the router and the firewall. It needs regular restarts – and it cannot give itself those: among the 437 settings there is no restart schedule. That is your operating system's job, or your provider's.

And it needs backups. The configuration knows nothing about those either. An operator without backups loses everything to the first corrupted save file – and that does happen.

The biggest gain of your own server is nonetheless immediate: you can experiment safely. Change a setting, start, look, change again – with nobody watching. Many operators run both: rented for the community, a small one of their own for testing.

Why your config file collects ballast over time

One thing only becomes apparent after months: nobody tidies up your config file. Not your provider, not the game.

On startup SCUM adds every key it knows and finds missing. That is convenient – after an update the new settings appear in the file by themselves. The reverse does not happen, though: keys an update has abolished simply stay. They are not deleted, not commented out, not reported.

The result is a file that only ever grows. On a server running for a year it holds the current settings and the corpses of every earlier edition. We counted it on a real file from a rented server: 460 entries, of which 437 are current and 23 have not existed since the June update.

No harm is done – the old lines simply do nothing. What makes it unpleasant is something else: you end up configuring values nobody reads any more. Change a number after an update, see nothing happen, and you can spend hours looking for the fault in the wrong place.

On rented servers there is the added twist that your provider’s input form has a state of its own. It can show fields the game no longer knows and omit settings that have existed since the last update. When in doubt, the file counts, not the form.

So: look through it once after every larger update. Which lines are new, and which belong to settings that no longer exist? It takes five minutes and saves a lot of searching.

How to tell when to switch

You edit the INI more often than the form. Then you are not using the panel, you are working around it. A provider with good file access is usually enough at that point.

You cannot answer a question because a log is missing. That is the clearest sign. When “I do not know what happened” comes up repeatedly, you are short of access, not knowledge.

The server stutters and you have tried everything configurable. Then the hardware is the limit. A larger plan is the next step, not the next value.

The reverse holds just as well: if you run your own server and regularly forget to restart or back it up, a rented one is the more honest solution. Availability beats control as long as people want to play on it.