BeamMP Dedicated Server Setup Guide (2026)

Setting up a BeamMP dedicated server seems simple until the server is running, but nobody can find or join it. An invalid AuthKey, blocked port, incorrect map path, or CGNAT can make a healthy server appear broken.

A BeamMP dedicated server is a standalone Windows or Linux application that connects players, manages session settings, relays vehicle-state data, and distributes configured maps and vehicle mods. It does not require BeamNG.drive or a GPU on the server host.

BeamMP uses port 30814 over TCP and UDP by default, while public server listings require a valid AuthKey, Private = false, and successful communication with the BeamMP backend.

Small groups can self-host, but public communities usually need reliable IPv4 connectivity, sufficient upload capacity, and consistent uptime.

This guide covers hardware, installation, ServerConfig.toml, networking, mods, plugins, performance, updates, and troubleshooting.

You will learn how to launch a reachable server and resolve common connection failures before inviting players.

BeamMP Dedicated Server Quick Facts

BeamMP Server v3.9.1 added chat-length validation, improved socket handling, Lua stability changes, malformed vehicle-packet protection, and Debian 13 builds. Version 3.9.2 added IP limiting and more hosting-provider controls. Version 3.9.3 improved shutdown initialization and server stability.

How BeamMP Multiplayer Architecture Works

The Three Core Parts of the BeamMP Stack

A working BeamMP session depends on three components:

• BeamMP mod inside BeamNG.drive
• BeamMP launcher
• BeamMP dedicated server

A failure in the mod, launcher, server, or a required backend service can prevent connections or disrupt specific multiplayer functions.

BeamMP Mod Inside BeamNG.drive

The BeamMP mod runs inside BeamNG.drive and provides the in-game multiplayer layer. The in-game mod communicates locally with the BeamMP launcher. It also provides the multiplayer interface inside BeamNG.drive.

This includes:

• The multiplayer UI
• The server browser interface
• Connection prompts
• Multiplayer session controls

The mod is mostly built with Lua, with some JavaScript, HTML, and CSS for UI elements.

Once connected, the mod exchanges multiplayer state with the launcher and reflects other players, vehicles, and server data inside the game world.

BeamMP Launcher

The BeamMP launcher connects the in-game mod to the selected BeamMP server and also handles player authentication with BeamMP backend services. Its main role is not to render the server browser. The server list appears inside the mod UI in BeamNG.drive.

The launcher handles the parts that sit behind that interface:

• User login with BeamMP backend services
• Maintaining a constant connection with the mod
• Establishing a connection to the selected server
• Supporting multiplayer network communication
• Helping manage mod download and session entry

The launcher does not “load” the mod in the same way a code injector would. It launches BeamNG.drive with BeamMP already installed and available.

Players can also join as guests when the server’s AllowGuests setting permits guest access.

BeamMP Dedicated Server

The BeamMP dedicated server is the central session coordinator.

It connects one or more launchers to the same multiplayer session.

That distinction matters. The launcher is the player-side network endpoint, not the raw game client by itself.

The dedicated server handles:

• Active session coordination
• Player access
• Map and server settings
• Server visibility
• Mod delivery workflows
• Lua server-side plugins

The server can also run Lua plugins, which makes it useful for moderation tools, custom game modes, automation, and event logic.

How Authentication Works

Authentication starts on the launcher side.

BeamMP uses two different authentication systems:

AuthKey Generation:

Server administrators create an AuthKey using the BeamMP Keymaster portal, which requires a Discord login.

Player Login:

Players log in to BeamMP using BeamMP forum credentials inside the BeamMP launcher, or they may connect as guests if the server allows it.

These two authentication flows are separate and serve different purposes.

After that, the launcher connects to the chosen BeamMP server and keeps the multiplayer session active through its link with the in-game mod.

How the Heartbeat System Works

A public server sends periodic heartbeat data to the BeamMP backend so the service can maintain its listing.

This is how the BeamMP network knows the server is live and eligible for the public list.

If heartbeat messages fail, the server can disappear from the public browser even if the server process is still running.

How Vehicle Synchronization Works

BeamMP uses a client-authoritative physics model.

This means each player's machine calculates vehicle physics locally inside BeamNG.drive.The server does not run full soft-body physics for every vehicle.

Instead, the game client produces the live vehicle state, and that state gets sent through the multiplayer pipeline to other players.

That state is more complex than simple controls like steering or throttle alone. BeamMP relays vehicle-related state between clients, so sessions with more players and active vehicles can increase network traffic and client-side processing.

This design keeps server hardware demands lower than a fully server-side physics model would.

Why Latency and Update Rate Matter

BeamMP depends heavily on network quality.

Vehicle state updates move between the player, the server, and other players many times during a session.

Visible synchronization quality depends on latency, packet loss, client performance, active vehicle count, and network conditions.

When latency rises, you are more likely to see:

• Delayed vehicle movement
• Rubber-banding
• Late crash reactions
• Desynced traffic or player cars

Lower latency, minimal packet loss, and consistent routing can improve responsiveness and reduce visible synchronization problems.

Hardware and System Requirements for Running a BeamMP Server

A BeamMP server does not simulate vehicle physics. Each player’s computer calculates physics locally inside BeamNG.drive. The server coordinates players, distributes mods, and synchronizes vehicle state between clients.

Because BeamNG.drive clients calculate vehicle physics locally, the BeamMP server does not run the full soft-body simulation for every vehicle. Still, server hardware matters.

More connected players and active vehicles increase live synchronization work, while larger resource packs increase storage and download-bandwidth requirements.

CPU Requirements

CPU performance affects how quickly the server processes vehicle updates and distributes them to other players.

BeamMP’s official requirements recommend a CPU above approximately 1 GHz and preferably multiple cores. Practical performance depends on connected players, active vehicles, Lua plugins, and network traffic.

BeamMP does not publish an official CPU-to-player capacity table. Choose production hardware after testing the intended player count, active vehicles, plugins, and network load.

RAM Requirements

RAM usage can vary with:

• Connected player count
• Active vehicle count
• Lua plugins and resource handling
• Operating-system and control-panel overhead

BeamMP’s repository estimates 30–100 MiB for the server process, while the official FAQ lists more than 50 MiB of usable RAM, excluding operating-system overhead. Treat both figures as rough minimums.

A real deployment also needs memory for the OS, monitoring, control panels, plugins, file caching, and other services.

Resource handling, file caching, plugins, and other services may temporarily increase memory use while players join.

Storage Requirements

The BeamMP server binary is very small. BeamMP Server v3.9.3 binaries are approximately 8–12 MB, depending on the platform and architecture.

Most variable storage demand comes from mods, maps, logs, plugins, backups, and deployment files rather than the small server binary.

Typical Storage Usage:

• BeamMP server binary: approximately 8–12 MB for v3.9.3, depending on the build
• Config files: minimal storage; logs: variable and potentially much larger over time
• Mod packs and maps: several GB depending on server content

SSD or NVMe storage can improve file access, but player download time also depends on total mod size, server upload capacity, and network conditions.

Network Bandwidth Requirements

BeamMP servers constantly relay vehicle state updates between players. Network quality is a major constraint, but CPU capacity, plugin workload, connected players, active vehicles, and resource delivery can also become bottlenecks.

Bandwidth needs vary widely depending on:

• Player count
• Number of spawned vehicles
• Map activity
• Mod assets

BeamMP estimates approximately 5–10 Mbps of upload bandwidth as a basic server requirement. Actual traffic varies with connected players, active vehicles, resource downloads, and session activity, so public servers should monitor sustained and peak usage.

The 5–10 Mbps figure is a basic estimate rather than a guaranteed capacity target. Mod downloads, additional players, and active vehicles can increase bandwidth usage.

BeamMP Networking Requirements

A BeamMP server must use IPv4 networking. IPv6-only servers cannot host BeamMP sessions.

Administrators must open the default BeamMP port:

30814 (TCP and UDP)

This port must be:

• Allowed through the firewall
• Forwarded on the router if hosting from home

For a home-hosted server behind NAT, TCP and UDP port 30814 must normally be forwarded before players outside the local network can connect.

Supported Operating Systems and BeamMP Debian / Linux Compatibility

The BeamMP dedicated server runs on Windows and Linux systems. The best platform depends on the available tools, administration experience, and deployment requirements.

Windows Server Deployment

A Windows dedicated server offers a familiar executable-based setup, while Linux is well suited to command-line administration and automation.

The BeamMP server runs directly using the compiled executable. Most installations involve downloading the server package and launching the binary.

Windows deployments are common for:

• Personal servers
• Testing environments
• Administrators who prefer graphical tools

A Windows Server installation may use more baseline memory and storage than a minimal Linux installation, although the difference depends on configuration and background services.

Linux Server Deployment

BeamMP publishes official Linux server binaries for selected Debian and Ubuntu releases.

Linux offers:

• Potentially lower baseline overhead with a minimal installation
• Easier automation through scripts
• Service manager support for long-running processes

A Linux dedicated server is a common choice for public game-server hosting because it supports automation, service managers, and container tooling.

Running BeamMP on Debian and Ubuntu

Debian and Ubuntu are the Linux distributions for which BeamMP publishes selected precompiled server binaries.

These distributions provide established package-management and service-management tools. For production use, configure a systemd service so the BeamMP process can start automatically and be supervised by the operating system.

The BeamMP server binary runs directly once extracted and configured.

Linux Security Best Practices

The BeamMP server should not run as root.

Administrators should create a dedicated user account for the server process.

Running the server under a restricted user improves security and prevents accidental system damage.

A typical setup involves:

• Creating a dedicated server user
• Running the server under that account
• Managing the service through system tools

Linux Distribution Compatibility

Current official release assets include:

• Debian 12 x86_64 and ARM64
• Debian 13 x86_64 and ARM64
• Ubuntu 22.04 x86_64 and ARM64
• Ubuntu 24.04 x86_64 and ARM64

Other distributions may work but are not officially supported. Advanced administrators can also build the server from source for unsupported systems.

Docker and Container Deployment

BeamMP can be deployed in containers because many server settings can be supplied through supported environment variables.

Container deployment helps with:

• Repeatable server setups
• Controlled image replacement
• Easy migration between machines

Docker is especially useful for VPS environments or clustered infrastructure.

Why Linux Works Well for BeamMP Hosting

A minimal Linux installation supports service managers, automation, and container tooling while avoiding unnecessary desktop overhead.

BeamMP Server Setup: Step-by-Step Installation

A BeamMP dedicated server deploys in a clear sequence. Follow the steps in order to avoid connection problems.

You will:

1. Generate your BeamMP AuthKey
2. Download the BeamMP server binary
3. Run the server once to generate configuration files
4. Edit the ServerConfig.toml configuration
5. Configure networking and firewall rules
6. Start the server and verify player connections

Common setup failures include invalid or missing AuthKeys, incorrect TOML syntax, closed ports, incorrect firewall rules, CGNAT, and incorrect map or resource paths.

Generating the BeamMP AuthKey

Create your server key before launching the server. The key registers your server with the BeamMP backend.

AuthKeys are created through the BeamMP Keymaster portal.

Steps:

1. Open the BeamMP Keymaster page
2. Log in using your Discord account
3. Create a new server key
4. Copy the generated AuthKey

AuthKey Limits

BeamMP does not give unlimited keys.

Key rules:

• One key can run only one server at a time
• Users receive a limited number of keys
• Supporting the project unlocks additional keys

AuthKey Usage

A valid AuthKey is required for public server-list visibility and is also recommended for private servers.

Treat the key like a password. Never share it publicly.

Downloading the BeamMP Server Files

Before running the BeamMP server on Windows, install the Microsoft Visual C++ Redistributable (x64). The BeamMP server binary depends on these runtime libraries, and the server may fail to start if they are missing.

After installing the Visual C++ Redistributable, download the server binary from the official BeamMP GitHub releases page.

BeamMP publishes multiple platform-specific builds.

Linux:

chmod +x BeamMP-Server-xxx

./BeamMP-Server-xxx

Windows:

BeamMP-Server.exe

During the first run the server creates:

• ServerConfig.toml
• Server.log
• Resources folder

Server.log contains startup messages, plugin errors, and network activity. This file is the first place to check when troubleshooting server problems.

Editing the Server Configuration

The ServerConfig.toml file controls server behavior.

Open the file in any text editor.

Example configuration:

[General] Name = "My BeamMP Server" MaxPlayers = 12 Port = 30814 Private = true AuthKey = "YOUR_AUTH_KEY_HERE"

Important settings include:

• Server Name
• Maximum Players
• Network Port
• Private/Public Status
• AuthKey

Paste your generated key into the configuration.

Example:

AuthKey = "YOUR_AUTH_KEY_HERE"

After inserting the key, the server can appear in the public server list if the server is not set to private.

Configuring Networking and Firewall Rules

BeamMP servers use the default port:

30814 (TCP and UDP)

This port must allow incoming connections.

Firewall Configuration

Allow the BeamMP server through your firewall.

Required rules:

• Inbound TCP 30814
• Inbound UDP 30814
• Outbound TCP 30814
• Outbound UDP 30814

Both Windows and Linux firewalls can block these connections by default.

Port Forwarding (Home Servers Only)

If you host from home, forward the configured server port, which is 30814 by default, over both TCP and UDP to the server’s local IPv4 address.

Example router rule:

On Ubuntu hosts, follow the official UFW firewall guidance to allow only the required BeamMP TCP and UDP port.

When Port Forwarding Is NOT Required

You can skip port forwarding if you host on:

• VPS servers
• Dedicated servers
• Local LAN servers

VPS and dedicated-server deployments do not require home-router forwarding when they have directly routed public connectivity, but the configured server port, which is 30814 by default, must still be allowed over TCP and UDP through host and provider firewalls.

Public communities may also benefit from DDoS-protected dedicated servers to reduce the risk of disruption from malicious network traffic.

CGNAT Warning for Home Hosts

Many home internet providers place users behind Carrier-Grade NAT (CGNAT). In this situation, your router does not receive a public IPv4 address.

BeamMP requires IPv4 connectivity. CGNAT usually prevents inbound hosting. Request a public IPv4 address, use a VPS or hosting provider, or use a tunnel that explicitly provides reachable TCP and UDP port forwarding. BeamMP does not support Hamachi or RadminVPN.

CGNAT is a common cause of failed inbound connections because the router does not receive a directly usable public IPv4 address.

Starting the Server

Once configuration and networking are ready, start the server again.

Linux:

./BeamMP-Server-xxx

Windows:

BeamMP-Server.exe

Confirm that the server is listening on the configured port, which is 30814 by default, and that no startup errors remain.

Connecting Players to the Server

Players connect using the BeamMP launcher and multiplayer menu.

Connection flow:

1. Launch BeamNG.drive through the BeamMP launcher
2. Open the multiplayer menu
3. Find the server in the server browser
4. Connect to the session

A running server can appear in the public list after it uses a valid AuthKey, sets Private = false, and successfully communicates with the BeamMP backend.

Direct IP connection also works if the server remains private.

Joining Your Own Server (Same Machine)

If the BeamMP server runs on the same computer as BeamNG.drive, connect through Direct Connect using 127.0.0.1 and the configured server port.

Steps:

1. Open the multiplayer menu in BeamNG.drive
2. Choose Direct Connect
3. Enter the following address:

127.0.0.1:30814

This address represents the local machine's loopback network interface.

Understanding the ServerConfig.toml Configuration

The ServerConfig.toml file controls how your BeamMP server operates.

The server generates this file during the first launch. You must edit it before making the server public.

This file defines:

• Server identity
• Player capacity
• Network settings
• Gameplay limits

A minimal configuration example looks like this:

[General]

Name = "My BeamMP Server"

Description = "Private testing server"

Port = 30814

MaxPlayers = 12

Private = true

AuthKey = "YOUR_AUTH_KEY_HERE"

During setup, keep Private = true until you obtain an AuthKey.Private = true only hides the server from the public list. It does not add password protection or prevent users who know the IP address and port from attempting a direct connection.

Important Configuration Parameters

The most important parameters include:

• Server NameAppears in the BeamMP multiplayer server browser.
• Server DescriptionExplains the purpose of the server such as drifting, racing, or roleplay.
• PortDefines the listening port for player connections.Default value: 30814.
• MaxPlayersLimits the number of players who can join the server.
• MapThe Map field must use the full internal map path, not the display name.

Example:

Map = "/levels/west_coast_usa/info.json"

For modded maps, open the .zip mod file, locate the levels folder, and copy the exact folder name. Using only the display name will prevent the server from loading the map.

• Vehicle LimitsControls the maximum number of vehicles each player can have.
• Visibility SettingsDetermines whether the server appears in the public server list.

How Configuration Affects Gameplay

Server settings directly influence multiplayer performance.

Examples:

• Higher player counts, enabled by a larger MaxPlayers limit, increase networking and processing demand.
• Large map archives increase initial download requirements, while complex maps may increase client-side loading and simulation demands.
• A high MaxCars setting can increase the number of active vehicle updates and raise client and network load.
• Private servers do not appear in the public server browser.

Community servers usually balance these values to maintain stable sessions.

Example Community Server Configuration

The following values are an editorial starting point rather than official BeamMP recommendations:

Increase player and vehicle limits only after measuring client performance, latency, packet loss, bandwidth, and server resource usage.

Installing Mods and Custom Maps on a BeamMP Server

By default, BeamMP distributes configured ZIP resources from Resources/Client to connecting players so they can load the maps, vehicles, and assets required by the session. Resources protected with protectmod are not redistributed.

Correct Mod Folder Structure

Mods must be placed in the Client resource directory.

Correct structure:

Resources/

└── Client/

└── example_mod.zip

Important rules:

• Mods must be zipped packages
• Only .zip files should exist inside the Client folder
• Loose folders will cause server startup errors

By default, the server sends ZIP resources from the Client folder to connecting players. A resource marked with protectmod <filename.zip> true is not redistributed and must be obtained separately.

Vehicle Mods

Vehicle mods add custom cars to the server.

Examples include:

• Drift vehicles
• Racing cars
• Police vehicles
• Roleplay fleets

Each vehicle must exist as a BeamNG-compatible zip mod.

Custom Maps

Custom maps allow communities to host racing tracks, drifting areas, or roleplay cities.

Map mods follow the same rule:

• Stored as zip files
• Placed inside Resources/Client

How Mod Distribution Works

When a player joins:

• The server sends unprotected ZIP resources from Resources/Client.
• The client downloads missing assets.
• BeamNG loads the content before joining the session.

The server distributes its configured client resources, but players may still have other local mods installed separately.

Mod Compatibility Best Practices

Stable servers follow these practices:

• Limit Total Mod Size
• Avoid Conflicting Vehicle Packs
• Test Mods Before Deployment
• Remove Broken Mods Quickly

Large mod packs increase:

• Connection time
• Bandwidth usage
• Loading delays

Using the BeamMP Lua Plugin System

BeamMP includes a server-side Lua plugin system.

Plugins allow server owners to extend multiplayer gameplay without modifying the game itself.

This system powers moderation tools, custom events, and automated server features.

Correct Plugin Folder Structure

Server plugins must follow this structure:

Resources/

└── Server/

└── ExamplePlugin/

└── ExamplePlugin.lua

Important rules:

• Each plugin lives inside its own folder
• Each plugin folder must contain at least one top-level .lua file
• There is no plugins directory

Plugin Loading Behavior

The server loads Lua plugins during startup.

When multiple plugins exist:

• Top-level Lua files within each plugin directory load in alphabetical order
• Load order matters when top-level Lua files within the same plugin depend on one another.

Server logs display loading errors if a plugin fails to initialize.

Event-Driven Plugin System

Plugins react to server events.

Examples include:

• Player joins
• Player disconnects
• Vehicle spawns
• Chat messages
• Custom registered events and event timers

Plugins register event handlers that run throughout the session.

Plugin Communication

Plugins can interact with each other using BeamMP event calls:

• MP.TriggerLocalEvent
• MP.TriggerGlobalEvent

MP.TriggerLocalEvent synchronously calls handlers in the current plugin or Lua state, while MP.TriggerGlobalEvent asynchronously calls handlers registered across server plugins.

Plugins are isolated by default and can communicate through global events; optional state sharing must be configured explicitly in PluginConfig.toml.

Common Plugin Use Cases

Community servers commonly deploy plugins for:

• Moderation SystemsAdmin commands, bans, and player management.
• Race TimersLap timing and racing events.
• Custom Game ModesDrift competitions, challenges, and roleplay scenarios.
• Server AutomationScheduled restarts, announcements, and logging systems.

Plugins allow servers to create structured multiplayer communities.

Combining Mods and Plugins

BeamMP servers often combine two systems:

Client Mods

• Vehicles
• Maps
• Assets

Server Plugins

• Gameplay rules
• Event logic
• Server management

Together, these systems allow communities to build advanced multiplayer environments.

Choosing Between Self-Hosting, VPS, Managed Hosting, and Dedicated Servers

The right choice depends on your player count, network stability, and how much control you want over the infrastructure.

Performance Optimization for Stable Multiplayer Sessions

Let’s explore the key factors that shape BeamMP multiplayer stability and why some sessions run smoothly while others struggle.

BeamMP uses a client-authoritative synchronization model while each BeamNG.drive client calculates local vehicle physics.

The server does not simulate physics itself. Instead, the server relays vehicle-state data so clients can approximate a shared session.

Latency, packet loss, frame rate, and simulation differences can still cause visible divergence.

Permissive player and vehicle limits can allow workloads that generate more synchronization traffic when those slots and vehicles are used. This can lead to lag, desynchronization, or unstable multiplayer sessions.

Some performance problems originate on the client rather than the server. A computer that struggles to simulate multiple vehicles may experience reduced frame rates and less consistent multiplayer behavior for the vehicles it controls.

Key Configuration Parameters That Affect Performance

These fields appear inside ServerConfig.toml.

Example configuration structure:

[General]

Name = "My BeamMP Server"

Description = "Private drifting server"

Port = 30814

MaxPlayers = 12

MaxCars = 3

Private = true

AllowGuests = true

Tags = "Drift, Freeroam"

Map = "/levels/west_coast_usa/info.json"

Debug = false

Important fields include:

MaxPlayers

Limits how many players may connect simultaneously.

MaxCars

Defines the maximum number of vehicles per player.Vehicles spawned above the player’s MaxCars limit are deleted immediately.

Map

Specifies the map path, not the map name.Example:

/levels/gridmap_v2/info.json

AllowGuests

Controls whether guest players may join.

Private

Determines whether the server appears in the public browser.

Tags

Adds searchable labels such as:

• Drift
• Racing
• Police
• Freeroam

How Configuration Choices Affect Stability

Performance depends on:

Player Limits

More players increase:

• Vehicle state traffic
• Synchronization load
• Bandwidth usage

Vehicle Limits

Increasing the number of active vehicles generally increases the amount of synchronization data that clients and the server must handle.

Each active vehicle contributes synchronization data that other clients must receive and process.

Map Selection

Map impact depends on archive size, map complexity, active objects, client hardware, and the vehicles used in the session.

Measure loading time, frame rate, and memory use on representative client systems instead of relying on a universal map-load rating.

Use a stock map such as Gridmap v2 for a clean connection and configuration baseline before adding custom resources.

Common BeamMP Server Problems and How to Fix Them

BeamMP server issues can come from configuration errors, firewall rules, port forwarding, CGNAT, incompatible resources, plugin errors, outdated binaries, or client-side problems.

The table below covers frequent problems and practical solutions.

Using Debug Logging for Troubleshooting

Enable detailed logs by setting:

Debug = true

Debug mode increases log verbosity and helps identify:

• plugin failures
• connection errors
• mod loading issues

Logs grow significantly in size when Debug is enabled.

Maintaining and Updating a BeamMP Server

Stable servers require regular monitoring.

Maintenance includes:

• updating binaries
• checking logs
• maintaining plugins
• backing up configuration files

Updating the Server Binary

New BeamMP releases appear on GitHub.

Updating usually requires:

1. Download the latest binary
2. Replace the server executable
3. Restart the server

BeamMP does not currently support automatic server-binary updates. Self-managed installations must download the correct release asset, stop the server, replace the existing executable, restore executable permissions on Linux if required, and restart the process.

BeamMP’s current documentation contains conflicting descriptions of ImScaredOfUpdates and UpdateReminderTime. Self-managed server updates should therefore follow the documented manual executable-replacement process.

Check the official BeamMP-Server releases page regularly for new versions.

Monitoring Logs

Server logs reveal operational issues.

Logs report:

• Plugin loading errors
• Network failures
• Player join events
• Mod loading problems

Server.log is usually the first diagnostic source because it records startup, network, resource, and plugin messages.

Managing Plugins

Plugin maintenance includes:

• Updating scripts after BeamMP updates
• Removing incompatible plugins
• Testing plugins before public deployment

Top-level Lua files within each plugin directory load alphabetically, which can affect dependencies between those files.

Backing Up Configuration Files

Always back up:

• ServerConfig.toml
• Plugin directories
• Mod archives

Backups allow fast recovery after configuration mistakes.

Warning About Old Config Files

Older BeamMP installations used a configuration file named:

Server.cfg

This format is no longer supported.

If the file still exists in the server directory, the server will display warnings.

Remove the old file and use ServerConfig.toml instead.

BeamMP Hosting Requirements and RedSwitches Server Options

A reliable BeamMP server depends on more than powerful hardware. Correct ServerConfig.toml values, reachable IPv4 connectivity, open TCP and UDP ports, low latency, sufficient upload bandwidth, and tested resources determine whether players can connect and remain synchronized.

Self-hosting works well for testing and small private groups. As a community grows, home upload limits, CGNAT, shared resources, and inconsistent uptime can become serious constraints.

Dedicated infrastructure provides isolated resources and greater control, although client hardware and network quality will still affect the multiplayer experience.

RedSwitches dedicated servers provide single-tenant hardware, dedicated IPv4 connectivity, full root access, KVM and IPMI controls, plan-dependent DDoS protection, configurable NVMe or SSD storage, 20+ global locations, and 24/7 human support.

This allows administrators to select infrastructure near their players and scale it according to tested workloads rather than unreliable player-count estimates.

Start with conservative MaxPlayers and MaxCars values. Monitor Server.log, latency, packet loss, bandwidth, and resource usage before increasing capacity.

With careful configuration and reliable infrastructure, your BeamMP server can become a dependable home for racing, roleplay, and community events instead of a recurring troubleshooting project.