Schedule I Server Requirements and RAM Guide
How much RAM and CPU a Schedule I dedicated server really needs for your crew, why an empty server already uses most of a 4 GB plan, and how to tell whether to tune your settings or move up a plan.
The official baseline shows a 4 GB host running 0-1 players at roughly 72% CPU and about 3.0 GB RAM in use. That leaves only about 1 GB for player joins, saves, panel overhead, mods and OS overhead.
Schedule I dedicated hosting is sensitive to main-thread CPU speed. Once memory is sufficient, more RAM will not rescue a weak CPU, a slow virtual core or a crowded VPS node.
For 3-8 players, or any plan with a few mods and an always-on world, 6 GB gives the breathing room that 4 GB lacks during save/load spikes and busy periods.
More properties, employees, content mods, Wine or Proton, and inflated maxPlayers all raise the load. Pick a plan for peak evenings and future growth, not the empty-server graph.
Why a Schedule I server needs more than you would expect
Whether you write it Schedule I or Schedule 1, the starting point is the same: TVGS has not released an official dedicated server. Rented and self-hosted servers use DedicatedServerMod, which runs a headless copy of the full game with networking, save and load, quests, time, sleep and a built-in loopback host client on the server. That is why the baseline memory use is already high before your crew joins.
The project’s own host-sizing baseline is useful because it shows the true floor, not a comfortable target: a VPS with 2 vCPUs at around 2.0 GHz and 4 GB RAM can run a mostly idle server, but only with 0-1 connected players, at roughly 72% average CPU usage and about 3.0 GB RAM in use. On a 4 GB plan, that leaves about 1 GB of breathing room. That spare space disappears quickly once you add save spikes, panel overhead, Wine or Proton overhead, a few mods, or simple variation in a budget VPS node.
That is where most plan mistakes start. An empty world on a 4 GB plan looks fine, so it is easy to assume 4 GB is generous, when the server is already close to its minimum working set. If you want a broader primer on how CPU, RAM and storage affect game servers, the same rules apply here, just with an unusually heavy idle footprint for a small-player game.
So treat 4 GB as the floor for “it starts and works”, not “it stays smooth under normal use”. CPU clock comes first, but the first RAM step above the floor matters because it gives the server somewhere to absorb join events, saves and mod overhead without falling over.
Our RAM ladder by crew size
This ladder is not an official chart from the project. It is a practical reading of the official baseline plus how multiple hosts size their Schedule I plans for real customer use. Use it for pre-purchase planning, then watch the server at your peak hours and adjust.
| Crew / usage | RAM | Why this tier makes sense |
|---|---|---|
| 1-2 players, vanilla | 4 GB | The floor. It can work because the player count is low and you are close to the official bare-minimum baseline, but there is very little spare RAM once the server’s own roughly 3.0 GB idle use is accounted for. |
| 3-4 players, or a few mods | 4 GB minimum, 6 GB preferred | Several hosts sell 4 GB for four players, so it is clearly possible. The reason to jump to 6 GB is not raw player count alone; it is the extra headroom for save/load spikes, MelonLoader overhead and a world that is left running all day. |
| 5-8 players | 6 GB | This is the most sensible small-community tier. Three hosts size up to eight players at 6 GB, which fits the pattern that 4 GB runs out of breathing room before RAM looks “full” on paper. |
| 9-16 players | 8 GB | Two hosts size sixteen players at 8 GB. By this point the issue is not only memory allocation; larger worlds mean more simulation state, more joins and leaves, and more save pressure during your busiest sessions. |
| 17-20 players with content mods | 12-16 GB | This is where the server stops looking like a private co-op world and starts needing public-server headroom. One host sizes the full 20-player setup with content mods at 16 GB, while another places busy public servers with heavy mods in the 10-12 GB range. |
The chart below is the quick visual version. Read it as a conservative planning ladder, not a promise that RAM alone determines the result.
Why hosts disagree on plan size
Host plan tables are useful, but they are not identical because hosts sell different amounts of headroom and bundle CPU in different ways. Three hosts put four players on 4 GB, while another starts four vanilla players at 8 GB and sells nothing smaller. That does not mean one of them is wrong. It usually means they are making different assumptions about CPU share, mod use, support load, and how close they are willing to let a server run to the edge.
Some also present plans in RAM-first terms, while others quietly attach more CPU threads or a larger CPU share as you move up. That is why a simple RAM comparison can mislead. If you want help reading these bundles, the same issue comes up in slot-based vs RAM-based pricing: the label on the package is not always the whole story.
For Schedule I specifically, the host-by-player-count matrix below shows the spread across Shockbyte, Wabbanode, Physgun, Cybrancee, Gravel Host and XGamingServer. Use it to see the range, not to chase the smallest possible figure.
| Host | 4 players | Up to 8 | Up to 16 | 20 with content mods |
|---|---|---|---|---|
| Shockbyte | 4 GB | 6 GB | 8 GB | – |
| Wabbanode | 4 GB | 6 GB | 8 GB | – |
| Physgun | 4 GB | 6 GB | 8 GB (busy community) | – |
| Cybrancee | 4 GB (you and a friend) | 6 GB (small groups) | 8 GB (large groups) | – |
| Gravel Host | 6 GB (small crews) | 8 GB (most groups) | 10–12 GB (busy public) | – |
| XGamingServer | 8 GB (vanilla) | 12 GB (up to 10 modded) | – | 16 GB |
In detail: Shockbyte sells 4 GB for 4 players, 6 GB for 8 and 8 GB for 16, and Wabbanode recommends the same three steps. Physgun describes its 4 GB plan as right for a few friends in co-op, 6 GB for a typical group of up to 8 and 8 GB for a busy community server. Cybrancee pitches 4 GB at you and a friend, 6 GB at small groups and 8 GB at large groups. Gravel Host starts at 6 GB for small crews, calls 8 GB the sweet spot for most groups and modded servers, and puts busy public servers with heavy mods at 10 to 12 GB. XGamingServer starts at 8 GB for 4 vanilla players, then 12 GB for up to 10 modded players, 16 GB for the full 20-player MultiplayerPlus cap with content mods and 24 GB for heavy mod stacks.
CPU matters more than RAM once memory is enough
The project’s own advice is plain: prioritise modern high-clock CPUs. That matters because Schedule I is a Unity game, and most of its world logic runs on one main thread. NPC routines, employees, properties and time progression all queue up behind that thread, so they do not spread neatly across lots of slow cores. Once the server has enough memory to absorb spikes, one faster core helps more than another few gigabytes.
That is why the official 2 vCPU around 2.0 GHz baseline is so revealing. If a mostly idle server with 0-1 players is already at roughly 72% average CPU usage, the machine is nearly saturated before your evening session even starts. Add more players and the server has less room to finish each simulation step cleanly, so players feel it as rubber-banding, delayed world updates or stutter in time progression.
When comparing plans, look for high clock speed, modern Ryzen-based nodes where offered, and a clear statement of how much CPU share you actually receive. Some hosts show that as a percentage such as 150% or 200% CPU, while others show thread counts. Neither label is automatically better; the useful question is how much uncontended single-thread performance the plan really has during busy hours.
Cheap VPS plans are where people often get caught out. On paper the RAM looks fine, but the virtual core is slow or the node is crowded. Noisy neighbours hurt Schedule I more than many games because the server is already so sensitive to short stretches where the main thread cannot get CPU time. If you do go that route, read up on running a game server on a VPS before assuming a bargain virtual machine will feel like a proper game panel plan.
What changes the load beyond simple player count
Player count is only the first input. A quiet four-player private world and a four-player world with content mods, a developed empire and constant progression are not the same server load.
- Content mods and MelonLoader: the mod layer itself adds overhead, and content mods add more game state for the server to track. The cost is a mix of extra RAM use and more CPU work during simulation and save operations. The trade-off is obvious: more features, less headroom.
- Bigger empires: more properties, more employees and more persistent activity mean more logic for the server to process every tick. This is usually felt as main-thread CPU pressure first, then bigger save files and more noticeable save spikes later.
- Raised maxPlayers: DedicatedServerMod defaults to
maxPlayers = 16and caps at 64. The vanilla four-player Steam lobby cap does not apply to direct-IP joins, so do not assume “the game is only for four” when sizing. Raising capacity does not create load by itself if the server stays empty, but it signals that you expect busier peaks and should size for those peaks, not the average afternoon. - Mono vs IL2CPP: both runtimes are supported. Match the server and players to the same runtime and the same game build. A mismatch is a join problem, not a RAM problem.
- Linux via Wine or Proton: Windows is the primary target, and Linux hosting usually means Wine or Proton. That translation layer adds overhead and eats headroom, which matters most on small plans already close to the edge.
- Storage: the game itself needs 8 GB minimum or 10 GB recommended on Steam figures. Fast NVMe storage helps because save and load work is disk-sensitive as well as CPU-sensitive, so quicker storage can shorten the ugly part of each save spike.
Settings that trade CPU for smoothness
Three settings matter most because they let you decide how hard the server works all the time versus how often players feel a hitch. These are not magic performance boosts; they move load around.
[server] maxPlayers = 16 [performance] targetFrameRate = 60 vSyncCount = 0 [autosave] autoSaveEnabled = true autoSaveIntervalMinutes = 15.0 autoSaveOnPlayerJoin = true autoSaveOnPlayerLeave = true [gameplay] pauseGameWhenEmpty = false
targetFrameRate
The default is 60, and 30-60 is the normal dedicated-server range. Lowering it reduces CPU use because the headless server is told not to run its loop as aggressively. The trade-off is that you are choosing less simulation frequency in exchange for more spare CPU time, so the world can feel less crisp under load if you push it too low. You will know it helped if CPU use stays clear of the ceiling at peak times and players report fewer stutters.
autoSaveIntervalMinutes
The default is 15.0. Very short intervals amplify save spikes because the server has to serialise world state and hit storage more often. The resources involved are main-thread CPU, some extra memory churn during save work, and disk I/O. The trade-off is simple: shorter intervals reduce lost progress after a crash, but increase how often everyone feels a hitch. You will know it helped if the hitch every few minutes becomes rarer without leaving your group exposed to a big rollback after a crash.
pauseGameWhenEmpty
The default is false. Turning it on pauses the simulation when no real players are connected, which is useful for private worlds that should not progress unattended. This does not make busy evenings faster, but the server is no longer simulating a city for nobody all day. The trade-off is that some groups want an always-moving world; others want a frozen world between sessions.
If you are troubleshooting, change one thing at a time and judge it during the same kind of session that caused the issue. Random single-player checks on an empty server tell you very little.
Hosting on the same PC you play on, a separate machine, or a rented server
Self-hosting can work, but remember that the game client’s own requirements still apply. Steam lists the client at 8 GB RAM minimum and 16 GB recommended, with a 3 GHz 4-core CPU minimum, and the server’s roughly 3.0 GB idle use sits on top of that. On one PC, the game and the server compete for the same RAM, the same CPU time and the same storage activity.
A separate machine or rented host avoids that contention and keeps the world online while your gaming PC is off. If you host it yourself, forward 38465 UDP and 38465 TCP, plus 27016 UDP. Do not forward the web panel on 4051; it is loopback-only. For a fuller look at the trade-offs, see hosting a server on your own PC.
Symptom, likely cause, first fix
Most Schedule I problems fall into a short list. The table below focuses on the first move that gives you the clearest answer fastest.
| Symptom | Likely cause | First fix |
|---|---|---|
| Memory graph sits near the plan limit, or crashes happen when people join | RAM headroom is too thin | Remove recent content mods or move up a RAM tier. This works because join events and saves need temporary breathing room; if the server stabilises and stops crashing under the same session load, the diagnosis was right. |
| Rubber-banding or time stutter while CPU is pegged | Main-thread CPU bottleneck | Lower targetFrameRate into the normal 30-60 range, then upgrade to a faster CPU plan if needed. This helps by reducing constant loop pressure; if CPU remains pinned and player feel does not improve, the plan is simply too weak. |
| A hitch every few minutes | Autosave spike on a low-CPU host or slow storage | Increase spacing between autosaves. The server saves less often, so it interrupts play less often; if the pattern lines up with saves and then eases, you have found the cause. |
| Lag starts only after adding mods | Mod stack overhead or a bad mod interaction | Roll back the newest mods first. That isolates whether the extra CPU or RAM cost came from the new content; if performance returns, re-add them one by one. |
| Server is fine empty but struggles at peak | Peak player count or world complexity exceeds the plan | Size for your busiest session, not the idle state. Keep maxPlayers honest and move to the next tier if the same evening load repeatedly causes the same slowdown. |
| Lag comes and goes at random times on a cheap VPS | Noisy neighbours or node contention | Move to a better node or a game-focused host. This works because the problem is CPU access, not your config; if the same save and mod set suddenly behaves normally elsewhere, the node was the issue. |
| Players cannot join at all | Game build mismatch, runtime mismatch, or unsupported MelonLoader version | Match server and clients to the same Schedule I build, the same runtime, and supported MelonLoader versions. This is a compatibility problem, not a memory one. |
If you need a wider troubleshooting primer, what causes game server lag covers the difference between CPU delay, network delay and storage hitches.
Tune it first or upgrade straight away?
A good rule is to tune when the server is close to workable, and upgrade when it is obviously starved. This table keeps that decision practical.
| Situation | Tune first | Upgrade if this is still true afterwards |
|---|---|---|
| Small private world, performance only dips during saves | Lengthen autosave spacing and keep NVMe if possible | Save hitches remain severe even with sensible spacing |
| CPU spikes during normal peak sessions | Lower targetFrameRate and remove recent heavy mods | CPU still pegs and players still feel time stutter |
| Private world left online all day with nobody on it | Turn on pauseGameWhenEmpty | You need unattended progression, so config cannot solve the idle load |
| Plan is 4 GB and the server is stable only when nearly empty | Trim mods and keep the player count low | You want 3-4 players regularly, or any mod growth at all |
| Players and mods have grown beyond the original idea for the world | Set a realistic maxPlayers and test at actual peak | The same peak load repeats the same slowdown each week |
| Random bad evenings on a budget VPS | Check for node contention patterns | Performance varies wildly without any world or config changes |
The flowchart below is the quick version: first identify whether the pain is mostly save-related, CPU-related, memory-related or simply bad infrastructure. Upgrade when the bottleneck is structural, not just badly tuned.
If your crew is going always-on, or you know mods are coming, skip the “absolute minimum” mentality. Compare CPU allocation, storage and the next RAM tier together, not as separate checkboxes.
Compare the best Schedule I server hostsWhat a 6 GB plan costs
A 6 GB plan is the most useful price checkpoint because it is where small private worlds stop living on the edge. Regular monthly prices for 6 GB: Gravel Host Dealer 6GB is £6.76/month ($8.99); Cybrancee Bagman 6GB is £11.27/month ($14.99); Physgun Block Boss 6GB is £12.40/month ($16.49); Shockbyte 6GB is £12.77/month ($16.99); Wabbanode 6GB is £13.49/month ($17.94).
Conversion used: £1 = $1.33
Schedule I server FAQ
How much RAM does a Schedule I server need?
For a mostly idle or tiny vanilla setup, 4 GB is the bare floor. For a small always-on crew, 6 GB is the more practical starting point because the server already uses about 3.0 GB before normal activity, save spikes and mods are added. Larger groups or heavier mod plans should step to 8 GB or above.
Is 4 GB enough for a Schedule I server?
It is enough to start the server and cover 0-1 players, and it can work for 1-2 vanilla players. The problem is headroom: the official baseline leaves only about 1 GB free on a 4 GB plan, so small spikes and future growth hit the limit quickly. It is a floor, not a comfort target.
Does CPU or RAM matter more for Schedule I?
CPU matters more once you have enough RAM for your player count and mods. The server simulation is sensitive to main-thread performance, so a slow or contended CPU causes rubber-banding and time stutter that extra RAM will not fix. Buy enough memory first, then prioritise higher clock speed and cleaner CPU allocation.
How many players can a Schedule I dedicated server hold?
DedicatedServerMod defaults to 16 players and caps at 64. The vanilla four-player Steam lobby cap does not apply to direct-IP joins on this setup, so server capacity is controlled by maxPlayers and by the strength of your plan. In practice, hosting more players only works well if CPU, RAM and mod load are sized for the peak.
Can I run a Schedule I server on the same PC I play on?
Yes, but the server’s roughly 3.0 GB idle use sits on top of the game client’s own 8 GB minimum or 16 GB recommended memory target. Both the client and the server also compete for CPU time and storage access, so busy sessions are much more likely to hitch on one machine. It is fine for experimenting; a separate machine or rented server is better for an always-on world.
More Schedule I hosting help
Our Schedule I host comparison and the hosting explainers that go with this guide.
Schedule I is still changing, and host panels do not all expose the same options in the same way. If a game update or panel change differs from the guidance here, follow your host’s current panel and the current DedicatedServerMod notes first.
