Brickadia Server Settings Explained: The Best Config for Your Group

The best Brickadia server configuration depends on whether you are hosting a private friends’ world or an open community. For a friends group, start with a recognizable server name, a nonempty password, bPubliclyListed=false, a conservative player limit, and a short welcome or rules message. Create a named world before relying on autosave, load that world after every restart, and forward UDP port 7777 for a dedicated server. Public servers should enable listing, publish a useful description, assign moderation roles carefully, and raise the player limit only after observing the host under your group’s real building load.

There is no published universal “best” player count or hardware tier. The settings below are a safe operating baseline, not a tested capacity guarantee.

What settings should a private Brickadia server use?

A private server should make access predictable and administration simple. Set a clear name so friends can identify it, require a password, hide it from the public list, and keep the player limit low enough for the host to handle your actual world and building activity.

Setting	Private friends group	Public community	Reason
ServerName	A recognizable group or project name	A descriptive community name	Players need to identify the correct server in the browser or direct connection list.
ServerPassword	Use a nonempty password and share it privately	Leave access open only if you have moderation and rules ready	Password protection is the simplest access-control boundary.
bPubliclyListed	false	true, if you want browser discovery	Listing determines whether the server is presented as a public destination.
MaxPlayers	Start conservatively and increase after observation	Choose a limit your host has demonstrated, not an arbitrary maximum	No authoritative source publishes a universal Brickadia capacity figure.
Welcome or rules text	Short instructions, build rules, and the group’s voice/chat expectations	Rules, moderation contact, reset policy, and building theme	Players see the policy before problems become moderation incidents.

These values are policy choices. Community configuration examples show that servers use both passworded and public setups, but they do not prove that a particular player limit will perform well on your machine. Increase MaxPlayers only after watching CPU load, memory use, connection stability, and the effect of large builds during a normal session.

Where is Brickadia’s GameUserSettings.ini file?

The dedicated-server settings are stored in an Unreal-style INI file. The exact path depends on the operating system and on whether you move the server’s saved-data directory.

Linux path

On a Linux dedicated server, the documented path is:

~/.config/Epic/Brickadia/Saved/Config/LinuxServer/GameUserSettings.ini

Windows path

On Windows, use:

C:Users<yourusername>AppDataLocalBrickadiaSavedConfigWindowsServerGameUserSettings.ini

Replace <yourusername> with the Windows account that launches the server. If you run several instances on one host, the -UserDir=<path> launch option can move the Saved directory so each instance has its own configuration, worlds, and logs.

Should you edit the INI directly?

Use the in-game server-settings interface first. Brickadia’s official Alpha 4 announcement described a permission-controlled settings menu and explicitly said, “There’s no JSON editing required – we’re not a pre-alpha any more!” Connect to the server, open the Edit Game or server-settings UI, change the values, and save. Then inspect the generated INI if you need to verify a value or fine-tune a setting that the interface exposes.

Managed hosting panels can rewrite INI values from startup variables. When a panel documents that behavior, make the change in the panel rather than editing the file and expecting it to persist. Stop the server before manual edits, keep a backup of the original file, and restart it so the change is loaded cleanly.

How do I launch a Brickadia dedicated server?

Steam or SteamCMD supplies the dedicated-server files. Community documentation identifies Steam app ID 3017590. The first launch must include a server-hosting token so the instance can register; subsequent launches can omit the token after registration.

First Linux launch

From the directory containing the Linux server executable, run:

./BrickadiaServer-Linux-Shipping -log -port=7777 -token=yourTokenHere

Replace yourTokenHere with the token issued for server hosting. Keep the token private; it is an authentication credential for registering the server.

Later launches

Once registration has completed, launch without the token:

./BrickadiaServer-Linux-Shipping -port=7777 -log

The documented default is UDP port 7777. To use another port, add -port=<port> and forward that same UDP port through the router and firewall. If you are running more than one instance, give each one a different port and a separate -UserDir path.

What does a successful launch look like?

• The process remains running instead of exiting immediately.
• The log shows the server beginning its normal startup and listening on the selected port.
• The server appears in the browser if bPubliclyListed=true and the network is reachable, or it can be joined by its address and port when using a private listing.
• The first registration launch completes with the token; later launches work without repeatedly supplying it.

What port does Brickadia use, and how do I make it reachable?

Brickadia’s documented default is UDP port 7777. A dedicated server needs a stable route from the internet to the host: reserve a stable LAN address, forward UDP 7777 on the router to that address, and allow the port through the host firewall.

Network checklist

1. Give the server computer or virtual machine a reserved LAN address so the forwarding rule does not point at a different device after a lease change.
2. Create a router rule forwarding UDP 7777 to that address.
3. Allow inbound UDP 7777 in the operating system or cloud firewall.
4. If you changed the launch flag, forward the replacement port instead of 7777.
5. Test from outside the LAN. A local connection can succeed even when internet players cannot reach the forwarded port.

The Linux hosting guide calls for a public IP and UDP forwarding. A router that uses carrier-grade NAT or otherwise gives you no inbound-control option can prevent a conventional dedicated server from being reachable. In that situation, the in-game GUI host is the documented alternative because it can avoid dedicated-server port forwarding; it is a different hosting mode, not a way to make an unreachable dedicated process public.

Why can players see the server but fail to join?

• The router forwards TCP instead of UDP.
• The forwarding target changed because the host’s LAN address was not reserved.
• The operating-system or cloud firewall still blocks the port.
• The server is listening on a custom port while players are trying the default.
• The process stopped after a crash or was launched with an invalid argument.

Check the launch log, the actual port flag, the router rule, and the firewall in that order. Do not assume that a browser listing proves that every path to the server is working.

How do I make a Brickadia server private?

Set a nonempty server password and disable public listing. In the settings UI, configure the server name, password, and listing option; in the generated INI, verify that the equivalent public-listing value is false.

1. Connect as an administrator and open the Edit Game or server-settings menu.
2. Choose a recognizable ServerName.
3. Enter a nonempty ServerPassword and distribute it only to the intended players.
4. Turn off public listing, represented by bPubliclyListed=false.
5. Save the settings and restart if the server requests it.
6. Ask a friend outside the host’s machine to join with the password, then confirm that the server no longer appears as an open public destination.

A password is access control, not a complete moderation system. Remove former players from the password-sharing channel, change the password after an unwanted disclosure, and use roles and backups to recover from griefing.

How many players should I allow?

There is no reliable, named publisher statistic that establishes an optimal Brickadia player limit, CPU tier, or RAM amount. The correct value is the highest limit your host can sustain with your group’s actual world size, construction complexity, and activity without making the experience unstable.

A practical capacity test

1. Start with a conservative MaxPlayers value that matches the number of friends you expect, not the largest number you can type.
2. Load the group’s real world, including its largest builds and the vehicles or effects your group normally uses.
3. Invite players in stages rather than filling the limit immediately.
4. Observe server logs, CPU utilization, memory pressure, network behavior, and player reports during building and map changes.
5. Raise the limit only when the host remains stable at the current setting across more than one normal session.
6. If lag or crashes appear, lower the limit and identify whether the trigger is population, a particular map, a build, or an administrative action.

A sample value in someone else’s configuration is not a benchmark. Two servers with the same nominal CPU and memory can behave differently because worlds and player activity differ. Public communities should publish a limit they have actually operated, while private groups should prefer predictable play over filling every available slot.

What hardware and software does a dedicated server need?

The Linux setup guide calls for an x86_64 Linux virtual machine, a recent 2–4-core CPU, at least 2 GB of RAM, SteamCMD, a public IP, and UDP port 7777 forwarding. The FAQ also states that the CPU must support AVX/AVX2 because Brickadia is built on Unreal Engine 5.

Requirement or recommendation	What it means	Qualification
x86_64 Linux VM	Use a 64-bit Intel/AMD-compatible Linux environment for the documented Linux workflow.	It is a guide prerequisite, not a guarantee for every world.
Recent 2–4-core CPU	Provides the guide’s starting range for a small server.	Not a measured player-capacity result.
At least 2 GB RAM	Meets the guide’s minimum recommendation.	Large worlds and more players may require more; no universal amount is published.
AVX/AVX2 support	Required by the Unreal Engine 5 build described in the FAQ.	A machine without the required instruction set cannot be made compatible by changing INI values.
SteamCMD	Installs or updates the dedicated-server files.	Keep the installation and Saved data organized separately.
Public IP and UDP forwarding	Allows internet players to reach a conventional dedicated server.	Carrier-grade NAT or restricted hosting can block inbound access.

Treat these as documented prerequisites and starting recommendations. They do not promise that a 2 GB machine will support a particular player count, nor that adding cores alone will solve a map-specific problem.

How do I prevent my world from disappearing after a restart?

Create a named save before relying on autosave, enable Auto Save in advanced server settings, and explicitly load the named world after every restart. Autosave does not function until a save exists, and a saved world is not automatically the active world after a restart.

Create the first persistent save

BR.World.SaveAs GroupWorld

Use a name that is easy to type and recognize. The command creates the persistent world that later autosaves can update.

Configure autosave

1. Open the advanced server settings.
2. Enable Auto Save.
3. Set the interval appropriate for your session length and building risk.
4. Choose whether the server announces autosave events, so players know when a recent change has been written.
5. Save the settings and perform a manual save before a major edit or event.

Load the world after a restart

BR.World.Load GroupWorld

Run the load command after the server is ready. If the world name contains spaces, use the quoted form shown in the administration documentation:

BR.World.Load "map name"

Keep a backup copy of the Worlds directory before major configuration edits, game updates, or map changes. A backup gives you a recovery point if a save is damaged or an administrative command loads the wrong level.

Which Brickadia administration commands are most useful?

Use administrative commands deliberately and grant roles only to people who need them. The dedicated-server documentation lists these core commands:

Command	Purpose	Operational note
/GrantRole Admin <player>	Grants the Admin role to a named player when entered through the chat-command interface.	Grant sparingly; an administrator can affect worlds and other players.
BR.World.Load "map name"	Loads a named world or map.	Use the exact saved name and quote names containing spaces.
BR.World.Save	Writes the current world.	Run before maintenance, map changes, or other risky operations.
BR.World.SaveAs <name>	Creates a named persistent world.	Do this before expecting autosave to protect the session.
Server.Status	Displays server status information.	Useful when checking whether the process and current session are healthy.
servertravel <map>	Changes the level while attempting to keep clients connected.	The FAQ warns that it can sometimes crash connected clients.
travel <map>	Changes levels after disconnecting clients.	Use when a clean reconnect is safer than risking a client crash.

Test map changes with your group before using them during an event. Announce the save, explain whether players will disconnect, and keep the current world’s backup available.

How should a public Brickadia server differ from a private one?

A public server needs discovery, clear expectations, and an operating plan. Enable listing, write a description that tells players what the server is for, choose a demonstrated capacity, and assign moderation roles before advertising it.

Public-server checklist

• Set bPubliclyListed=true only when you are prepared for unknown players to find the server.
• Use a description that states the theme, building rules, reset policy, and how players can report problems.
• Set a password only if you intentionally want a gated community; do not advertise an “open” server whose password is required.
• Keep the player limit within the host’s observed capacity.
• Create a named world and test autosave before opening to strangers.
• Give Admin roles to a small, trusted moderation group.
• Back up the Worlds directory before major map or configuration changes.
• Record the current port, launch flags, server name, and administrator contacts so another moderator can restart the service.

The official server browser is a live snapshot of listings, password indicators, dedicated status, descriptions, and player limits. Treat what it shows as changeable community information, not as a stable count or performance ranking.

What should I check when a setting does not stick?

First determine which layer is authoritative: the in-game settings UI, the generated INI, or a managed hosting panel. A panel may apply startup variables every time the process launches, overwriting a manual file edit.

Server name, password, or listing reverted

1. Stop the server cleanly.
2. Change the value in the panel if the host documents panel precedence.
3. If you manage the process directly, use the in-game settings menu and save.
4. Inspect the correct OS-specific GameUserSettings.ini under the active -UserDir.
5. Restart and confirm the effective value in the browser or connection flow.

The server starts with the wrong world

Verify that you created a named save with BR.World.SaveAs, that the Worlds directory belongs to the active Saved path, and that you ran BR.World.Load GroupWorld after restarting. Multiple instances using the same Saved directory can make this confusing; isolate them with separate -UserDir paths.

The process exits on launch

• Check that the executable matches the host architecture and that the CPU supports AVX/AVX2.
• Confirm that the token is present on the first registration launch and omitted only after registration succeeds.
• Check the port syntax and make sure another service is not already using the selected port.
• Run with -log and read the final startup messages before changing unrelated settings.

What is the safest configuration workflow for a small group?

Build the server in a controlled order so networking, access, persistence, and administration are tested separately.

1. Install the server files. Use Steam or SteamCMD and verify that the dedicated executable is present.
2. Check the host. Confirm x86_64 Linux for the documented Linux workflow, AVX/AVX2 support, sufficient memory, and a recent 2–4-core CPU as a starting recommendation.
3. Choose the data location. Keep the default Saved path or set a unique -UserDir when sharing a machine with other instances.
4. Register the server. Launch once with -token=yourTokenHere, -port=7777, and -log.
5. Open the network path. Reserve the LAN address, forward UDP 7777, and allow it through the firewall.
6. Set identity and access. Pick the name, password, public-listing state, welcome text, and initial player limit.
7. Create persistence. Run BR.World.SaveAs GroupWorld, enable Auto Save, and back up the Worlds directory.
8. Restart deliberately. Launch without the token, then run BR.World.Load GroupWorld.
9. Test with friends. Confirm that the intended players can join, the wrong password is rejected, and the world survives a restart.
10. Increase exposure gradually. Keep the server private until the workflow is reliable; only then enable public listing or raise the player limit.

Which configuration is best for your group?

For a recurring friends’ session, use a password, disable public listing, create one clearly named world, enable autosave, and keep the player limit close to your expected attendance. This minimizes moderation work and makes it obvious which world to load after maintenance.

For a public building community, enable listing only after the server has a tested save-and-restart routine. Publish rules and a useful description, appoint a small moderation team, and treat the player limit as an operational promise that must be validated against real activity. The “best” configuration is therefore the one your host can operate consistently, not the one with the most permissive values.

Frequently Asked Questions

Can I host Brickadia without forwarding a port?

A conventional dedicated server normally needs a reachable public address and UDP forwarding. If you cannot control the router, the in-game GUI host is the documented alternative because it can avoid dedicated-server port forwarding, although it is a different hosting mode with different administration characteristics.

Can one machine run multiple Brickadia servers?

Yes, isolate each instance with a distinct -UserDir=<path> so its Saved directory, configuration, worlds, and logs do not overlap. Each instance should also use its own listening port and matching firewall and router rule.

Why does my Brickadia server require AVX or AVX2?

The FAQ attributes the requirement to Brickadia’s Unreal Engine 5 build. If the processor lacks the required instruction set, changing the player limit, RAM allocation, or INI settings will not make that CPU compatible; use hardware that supports the instruction set instead.

What information does the Brickadia server browser show?

The browser is a live view of community listings, including password indicators, dedicated-server status, descriptions, and player limits. Listings and counts can change at any time, so use it to find a current server rather than as a permanent performance or population statistic.