Team Fortress 2 Server Requirements: RAM, CPU and Player Slots

What actually limits a TF2 server

TF2 uses the same four resources every other Source server does, but it stresses them in a specific order. If you want the broad picture first, it helps to understand game server hardware in general; for TF2, the main point is that not all resources fail in the same way.

The one that usually runs out first is single-core CPU time. The server runs a fixed 66.666 ticks per second, which means a new simulation step every 15 ms. Within that tiny window the main thread has to process player movement, weapon logic, damage, bots, projectiles, plugins and map entities, then prepare updates for clients. If that loop finishes late, the server FPS falls, input feels delayed and movement starts to look inconsistent.

RAM is different. It holds the game state, loaded map data, plugin state and other working memory. A TF2 server does not need huge memory just to exist, which is why small vanilla servers run in modest RAM. Extra memory helps when you load heavier maps, bigger plugin stacks or custom modes, but it does not make a late tick suddenly arrive on time.

Disk is mostly about capacity rather than live match performance: the base install, custom maps, logs, demos and replay data all live there. Bandwidth is the server’s upload budget. Every player needs snapshots from the server, and SourceTV spectators add another stream on top. For a rented server this is usually handled for you; for home hosting it is often the first hard limit.

• CPU: consumed by the main game loop each tick; player count, bots, projectiles, plugins and busy maps all add work.
• RAM: consumed by the process heap, maps and plugin state; useful for plugin-heavy or custom setups, but not a cure for tick drops.
• Disk: consumed by the base install, .bsp maps, .dem recordings, replays and logs.
• Bandwidth: consumed by snapshots to players and spectators; this grows with every connected client the server is feeding.

Player slots come first

Before you look at RAM or vCPU, decide what sort of server you are actually running. In TF2, slots drive the rest of the sizing. A quiet scrim server, a full public server and an MvM server do not put the same load on the process, even if their advertised plan looks similar.

MvM is the classic trap. It looks like a small co-op server because only up to six humans join, but from the server’s point of view it is a 32-slot configuration. The dedicated server will exit when you try to start an MvM map under that limit, because the robot population needs those extra slots. If a host sells TF2 by slots, an MvM server must be on a plan that allows 32 slots. If the host sells by RAM, check that you are free to set maxplayers yourself.

SourceTV and Replay are smaller versions of the same issue. SourceTV joins the server as a bot on the spectator team, so it takes one of your slots inside the same process that runs the match. That is why a 6v6 match server that records demos is really a 13-slot server. The -replay launch option adds one to maxplayers for its own replay bot, so a 24-slot server quietly becomes 25. Neither is a problem on its own; they only bite when your plan is capped at exactly the number of humans you expect.

Bots are not free filler. They count against maxplayers, and the server simulates them like players. A “fill the empty spaces with bots” setup can therefore hit both slot limits and CPU limits sooner than a human-only server with the same headline player count.

# 24-slot public server with Replay switched on
./srcds_run_64 -console -game tf -replay +map ctf_2fort +maxplayers 24 +sv_setsteamaccount TOKEN

# Mann vs. Machine: always 32, even for six players
./srcds_run_64 -console -game tf +map mvm_decoy +maxplayers 32 +sv_setsteamaccount TOKEN

Going past 32 with -unrestricted_maxplayers is possible, up to 100, but it is not the normal supported path. The risk is not just more people in the scoreboard. You increase player entities, update traffic and simulation work, then rely on an option Valve marks as unsupported. Treat that as an experiment, not a default purchase target.

CPU: the real performance limit

For TF2, fast single-core performance matters more than a big core count. The reason is mechanical: the main game loop still has to complete one tick at a time, in order, every 15 ms. Extra cores can help with background work and thread pools, but they do not make a late main thread stop being late.

That is why host marketing about “more cores” tells only part of the story. In plain terms, a vCPU on a plan is a share of a physical processor core rather than a whole core of its own. For TF2, the quality of that share matters more than collecting a lot of shares you barely use. A fast single core with decent scheduling is usually better than a slower plan with a bigger headline core count.

CPU load per tick rises with player count, bots, lots of active projectiles, busy custom maps, plugin logic and MvM robot waves. All of that work happens inside the same fixed tick schedule. This is also why no host can sell you a “higher tickrate” TF2 server as a premium upgrade: -tickrate is disabled in code for TF2, so the server already runs the fixed 66-tick path. In general Source terms, 100 tick is about 1.5x the CPU load of 66, but in TF2 that is not something you can buy your way into.

Since the 18 April 2024 update, TF2 has 64-bit server support on Windows and Linux. The 64-bit launchers are srcds_run_64 on Linux and srcds_win64.exe on Windows, and Valve notes that this should include performance improvements for most users. The catch is compatibility: plugins or extensions built only for 32-bit will not load in a 64-bit server, so a CPU upgrade path can turn into a plugin maintenance job if your addon stack is old.

The -threads option only sets a thread pool and defaults to 3. It is worth knowing about, but it is not a substitute for single-core speed. If stats shows the server dropping below healthy FPS in live combat, more RAM and more nominal cores are the wrong first assumption. Start by asking how much work you are cramming into each tick.

RAM: enough for the job, not more than that

TF2 server memory use is usually modest. A plain srcds instance with an official map rotation does not need huge RAM, which is why small servers and standard public servers often run comfortably in far less memory than buyers expect. The place where RAM grows is not base TF2 so much as what you bolt onto it.

What adds to memory use? SourceMod plugin stacks, custom game modes, heavier custom maps, a broad map rotation kept ready on disk, replay data, and the extra state some addons keep in memory. Memory helps the process stay comfortable and avoids pressure during map loads or addon-heavy sessions. What it does not do is speed up a main thread that is already missing its tick window. If your live match FPS falls under load, that is still a CPU problem first.

These are sensible published starting points from one host’s TF2 guidance. Treat them as planning ranges rather than hard limits.

Our own TF2 host comparison lands in the same place: 1–2GB for a competitive 6v6 server with match plugins, 2GB for a 24-slot community server running a normal SourceMod set, and 3–4GB once you run a custom-mode server with heavy plugins and lots of maps. The first table is a little more generous because it leaves headroom; either way, RAM only climbs properly once you combine high slot counts with plugin-heavy or custom-mode workloads. Buy enough memory to cover the mode, the addon stack and the map set, but do not expect spare RAM to rescue a late tick.

Disk: small at first, then shaped by maps and recordings

The base requirement is straightforward: allow about 8 GB free for the install. TF2 dedicated server files come through SteamCMD as app ID 232250 and run on Windows or Linux; on Linux, a 64-bit system still needs the 32-bit compatibility libraries, and the official TF2 wiki lists glibc 2.3.6 or newer.

After that, disk use is mainly your content policy. Official-map vanilla servers stay tidy. Custom communities grow over time because every extra .bsp in tf/maps, every SourceTV demo, replay file and log adds to storage. If you turn on tv_autorecord 1, the server writes a .dem file every game, which is useful for league review and moderation but steadily increases disk use.

Replay adds the same kind of housekeeping overhead. It records and stores replay data on the server or a fileserver, so it is a disk feature first and a slot feature second. The trade-off is simple: more recoverable evidence and content, more storage to manage.

FastDL matters most when you use custom maps. It is not a RAM tweak and it is not a CPU tweak. It is a delivery path so players pull big files from a web server instead of dribbling them directly from the game server. That usually means faster joins, fewer download-related timeouts and less pressure on the game server’s own upload path.

// server.cfg: record every match, no live spectators
tv_enable 1
tv_maxclients 0
tv_autorecord 1

If you only want demos and not live spectators, tv_maxclients 0 keeps SourceTV as a recording tool without opening it up as a public bandwidth sink. If you do not want SourceTV at all, add -nohltv to the launch line instead: it removes SourceTV, frees its slot and closes port 27020.

Bandwidth and self-hosting

Bandwidth is mostly an outgoing traffic problem. The server sends snapshots to every connected player as often as the server and client settings allow, up to the useful ceiling of 66 updates a second because that matches the tick. The client advertises its download capacity with rate, while the server caps delivery with sv_minrate, sv_maxrate, sv_minupdaterate and sv_maxupdaterate. More players means more copies of those snapshots. More SourceTV spectators means another set again.

This is why you should measure with stats instead of trying to guess from a spec sheet. The In and Out columns show current server traffic. Watch them during the kind of match you actually plan to host: full public rounds, a bot-filled practice server, or an MvM wave. That number is your real requirement, because it includes your maps, your plugins and your player behaviour.

For home hosting, upload is usually the first limiting factor for a public 24-player server. The line has to feed every player continuously, and the server is only available while your PC is on. That makes a private scrim server or friends server much more forgiving than a public community server. If you are weighing that route up, read our guide to self-hosting a game server before you commit to a public setup.

• UDP 27015: game traffic
• TCP 27015: RCON
• UDP 27020: SourceTV

Forward those ports correctly if you self-host. If you use SourceTV for larger events, remember it runs inside the same process and consumes both CPU and bandwidth; Valve’s own notes point to relay proxies for many spectators because a single host can hit its limits quickly.

Sizing by server type

Use this as a purchase method rather than a rigid formula. Start with the server type, set the slots honestly, then prioritise the resource that actually constrains that type of server.

The decision rule is the same each time: set the real slot count, then buy CPU priority for busy ticks, then add RAM only for the content layer you are actually running. That avoids both common mistakes: overspending on memory a vanilla server never uses, and underbuying CPU for a full public server that falls apart as soon as players join.

What those plans cost to rent

TF2 is cheap to host because the server is light, and the market reflects that. The thing to watch is how a host sells it. Some price TF2 by RAM and let you set maxplayers yourself; others sell a fixed number of slots. A 10-slot plan is a bargain for a scrim server and useless for Mann vs. Machine, which cannot start below 32.

Conversion used: £1 = $1.33

The cheapest TF2 plan in our comparison starts at £2.25/month ($2.99), so there is rarely a reason to overbuy. Spend the difference on a host with fast single-core CPUs and a UK location rather than on memory a vanilla server will never touch.

How to tell your plan is too small, or too big

Check the server under the load it was bought for, not when it is empty. Run stats during a real match, with players, bots or MvM waves active. Healthy server FPS stays near 66.67; if it falls below 60 in live combat, the server cannot finish ticks on time. CPU near 100 with players on points to overload. For plugin-heavy servers, use SourceMod’s profiler to see what is eating main-thread time, and compare that with your control panel’s memory graph.

If you need broader fault-finding after the first pass, use our TF2 server troubleshooting guide. For fast triage, start here:

stats
sm prof start
sm prof stop

A plan can also be too big. If full matches keep FPS healthy, CPU is not pegged and the memory graph stays comfortable, throwing more RAM at the server buys very little. At that point, tune the content, not the package.

Renting vs self-hosting, and when to upgrade

Renting solves two of the awkward parts of TF2 hosting straight away: stable upstream bandwidth and hardware that stays on all the time. Self-hosting gives you full control and can work very well for private use, scrims and testing, but public server ambitions run into home upload limits quickly. If you are building your own instance from scratch, our guide to setting up a TF2 dedicated server covers the install side on Windows and Linux.

Upgrade when the evidence says the server is genuinely CPU-bound at the load you want to support: full match, real map, real plugins, real spectators. That is the case where a better plan helps. Do not upgrade first when the issue follows one custom map, one addon pack, one 64-bit compatibility problem or one weak home upload line. Those are configuration problems, not package problems.

If your next step is comparing plan types, remember the practical split: some hosts sell by slots, some by RAM. Slot plans are simple until a hidden-slot mode like MvM forces you to buy higher. RAM plans are flexible until a host restricts how you set maxplayers. Use fixing TF2 server lag to rule out tuning issues first, then use our Team Fortress 2 server hosting comparison to choose the kind of plan that fits your server type.

Team Fortress 2 server requirements FAQ

How much RAM does a TF2 server need?

Less than many buyers assume. A small vanilla server can start in the 1-2 GB range, a standard 24-player vanilla server is often fine around 3 GB, and heavier SourceMod or custom-mode setups need more. The important part is that RAM covers your maps and addons; it does not fix a server that is CPU-limited.

How many players can a TF2 server hold?

The standard maxplayers limit is 32. Casual-style public play is built around 24 players, Competitive is 6v6 for 12 players, and Highlander is 18 players. Going above 32 with -unrestricted_maxplayers is possible but unsupported and comes with stability risk.

Why does my Mann vs. Machine server need 32 slots?

Because MvM uses the rest of the slot pool for robots. Valve changed the dedicated server so it exits if you try to start an MvM map with less than 32 maxplayers. In practice, that means an MvM server is a 32-slot purchase even though only up to six humans are playing.

Does a TF2 server need a fast CPU or more cores?

A fast CPU core matters more. TF2 runs at a fixed 66 ticks a second and the main thread has to complete each tick on time, so late-tick problems are mainly about single-core performance. More cores can help with supporting work, but they do not solve a main game loop that is already too slow.

Can I host a TF2 server on my own PC?

Yes. srcds is free through SteamCMD and runs on Windows or Linux, but your home upload and uptime are the usual limits, especially for a public 24-player server. You also need the right ports forwarded and should check live In and Out with stats instead of assuming the line can cope.

More Team Fortress 2 server help

The host comparison and the TF2 guides that sit alongside this one.