For most friend groups, the best Core Keeper dedicated-server setup is Normal mode, an explicitly chosen player limit, a descriptive world name, and a seed recorded before the world is created. Keep a backup before changing anything. Put world settings in ServerConfig.json (or your host’s Server Options panel), while ports, IP binding, passwords, and other network controls belong in launch arguments. This split prevents settings from being silently ignored and makes it easier to recover when you test a new configuration.
The instructions below distinguish the official server package, a Windows self-hosted installation, and managed hosting panels. Their defaults are not identical, especially for player limits and Game ID validation.
What are the best Core Keeper server settings for four players?
Set the server to Normal mode, choose a maximum of four players (or five if a regular guest may join), give the world a recognizable name, and select and record the seed before first creation. Leave the season on automatic, let the server generate the Game ID, and keep relay mode unless you specifically need direct-IP connectivity or cross-play through an opened port.
| Setting | Recommended value for a four-player group | Reason and qualification |
|---|---|---|
| World name | A descriptive name such as Friday Core Keeper |
-worldname controls the name clients see. Names containing spaces must be quoted in a launch command. |
| World seed | Choose deliberately and save it with the backup | The seed affects generated content only when the world is first created. Editing it later does not regenerate an existing world. |
| World slot/index | Keep the established slot; use a new slot for experiments | A different slot loads a separate world instead of risking the established save. |
| World mode | Normal | It is the safest choice for a mixed-experience group. Hard is a deliberate challenge; Creative and Casual favor building or lower-pressure play. |
| Maximum players | 4, or 5 with a small guest cushion |
Set it explicitly because package and host defaults differ. |
| Game ID | Automatic generation | Hosted panels and the package reference apply different validation rules, so automatic generation avoids incompatible custom IDs. |
| Password | Only when using direct-IP access | The package reference says passwords apply to direct connections, not Game ID joins. |
| Port and IP | Leave relay mode on unless direct IP or cross-play is required | -port enables direct connections and cross-play. -ip has no effect without a port. |
| Season | Automatic | Omitting -season follows the system date. |
| Content bundles | Activate only after a backup | Activation is permanent for that world and cannot be undone. |
| Data path | Default | Use -datapath only when you have a deliberate storage or backup plan. |
| Auto-update | Enabled on managed hosting | One provider warns that outdated servers can cause connection problems; disable updates only with a version-pinning plan. |
Which Core Keeper settings belong in ServerConfig.json?
World identity and gameplay choices belong in ServerConfig.json or a host’s equivalent panel. Network-only values are launch arguments in the official package, even if a panel displays fields for them.
World and gameplay values
- World name: the client-visible name selected with
-worldname. - Seed: the generation input used at first world creation.
- World slot/index: the save selected by the server.
- World mode: Normal, Hard, Creative, or Casual.
- Maximum players: the concurrent-player ceiling.
- Season and seasonal override: automatic by default, with explicit override values available in hosted JSON guidance.
- Content bundles: world-level additions that cannot be rolled back after activation.
Launch-only network values
-portfor direct connections and cross-play.-ipfor binding an address when a port is also supplied.- A direct-connection password.
-datapathwhen relocating server data.
The dedicated-server reference verified against package version 1.2.1.5 on September 7, 2026 says port and IP values do not belong in ServerConfig.json. A managed panel may present a different interface, so follow the panel’s field labels while preserving this distinction for the official package.
How do I safely change Core Keeper server settings?
Stop the server, preserve the save, edit the correct setting surface, and restart before testing. A restart is required for Server Options changes to take effect.
- Stop the server cleanly. Do not edit a live configuration or copy a world while the process is writing to it.
- Back up the world and configuration. Keep the world files,
ServerConfig.json, the seed, the current slot number, and the active Game ID together. The Windows setup guidance includes a backup shortcut and specifically warns administrators to preserve backups before exposing a Game ID. - Choose the editing surface. For an official or Windows self-hosted installation, edit
ServerConfig.json. For managed hosting, open the provider’s Server Options panel; its fields may use different defaults. - Change only the intended values. Put world, seed, slot, mode, player, and season values in the JSON or panel. Put port, IP, password, and other launch-only values in the command line when the package reference marks them as launch arguments.
- Save and restart. WinterNode’s 2026 help documentation states that Server Options changes require a server restart.
- Verify the running configuration. Confirm the loaded world slot, generated Game ID, player limit, and mode before sending connection details to the group.
- Test with one player first. Check that the intended world loads and that the join method works before inviting everyone.
What does worldMode mean in Core Keeper?
worldMode is the numeric representation of the world’s gameplay mode in configuration files. The names and numbers below come from the package documentation and Akliz’s hosted JSON mapping; hosted values should be treated as deployment documentation, not a universal guarantee for every future version.
| Mode | JSON value shown in hosted guidance | Best use | Important limitation |
|---|---|---|---|
| Normal | 0 |
Mixed groups and a first shared world | Recommended default when players have different experience levels. |
| Hard | 1 |
Experienced groups seeking a tougher survival run | The gameplay guide says Hard raises enemy and boss base health and damage. |
| Creative | 2 |
Building, testing layouts, or experimenting | Switching between creative and non-creative after creation is unsupported. |
| Casual | 4 |
Lower-pressure sessions | Choose it intentionally rather than assuming it is another name for Normal. |
Difficulty is effectively a creation-time decision. If the group wants to test another mode, make a backup and use a new world slot instead of trying to convert the established world.
Can I change the Core Keeper seed after creating a world?
No. A seed controls generated world content when the world is first created; changing the value later does not rebuild an existing world. Decide on the seed before first launch and record it with the backup.
Use a new slot for experiments
Keep the current slot/index for the established campaign. Set a new index when testing another seed, mode, or configuration. Hosted documentation describes incrementing the world index as a way to load a different world without overwriting the existing one.
What to record
- The exact seed text.
- The world slot/index.
- The world name.
- The mode and maximum-player value.
- The backup date and server package version.
How many players can a Core Keeper dedicated server support?
Set the maximum explicitly rather than relying on a default. The official package reference says omitting -maxplayers defaults to eight, while WinterNode documents a hosted-panel range of 1–100 and a panel default of 100. Those figures describe different deployments, not a single universal limit.
For a four-person group, use 4 unless an occasional guest is expected; then use 5. A cushion prevents a late arrival from being rejected while still documenting the intended group size. After restarting, verify the value in the active panel or server output before sharing access.
Should I create a custom Game ID?
Usually not. Let the server generate the Game ID unless your group has a specific reason to use a stable custom identifier and can satisfy the deployment’s validation rules.
The package reference describes a 15–28-character alphanumeric ID and excludes Y, y, x, 0, and O. WinterNode’s panel documentation instead requires at least 28 characters. Because those requirements do not match, an automatically generated ID is the least error-prone choice.
Keep the active ID in the same administrative note as the backup, but share it only with the people who should join. If you change the world slot, restore a backup, or move between deployments, re-check the ID before players connect; do not assume an old invitation still identifies the running world.
Do I need a port for Core Keeper cross-play?
You need a correctly opened port when using direct connections or the package’s cross-play path. Relay mode does not require you to expose a port for ordinary Game ID joining.
Direct-connection checklist
- Add a valid
-portlaunch argument. - If binding a particular network address, add
-ipas well;-ipalone has no effect. - Open and forward that port through the host firewall and router as appropriate for your network.
- Set a password for direct-IP access if the group needs one.
- Restart and test from a second connection before distributing the address.
The package documentation says the direct-connection password is not used when players join by Game ID. Do not put port or IP values in ServerConfig.json for the official package, because those JSON entries are ignored there.
Where is Core Keeper ServerConfig.json on Windows?
For a Windows self-hosted dedicated server, the community setup guide places the file at:
%APPDATA%..LocalLowPugstormCore KeeperDedicatedServerServerConfig.json
That guide places dedicated-server worlds at:
%APPDATA%..LocalLowPugstormCore KeeperDedicatedServerworlds
These are Windows locations, not universal paths. Linux installations can differ according to the installation method and service account. Akliz’s hosted path is /core-keeper/DedicatedServer/ServerConfig.json; on a managed host, use its file manager or configuration panel rather than assuming a local Windows path.
How do official, Windows, and managed-host setups differ?
The underlying choices are similar, but the controls and defaults vary by deployment.
| Deployment | Where to edit | What to watch |
|---|---|---|
| Official dedicated-server package | Launch command plus ServerConfig.json |
Package version 1.2.1.5 was the reference point verified September 7, 2026. Omitted -maxplayers defaults to eight. |
| Windows self-hosted install | Windows LocalLow path and your launch shortcut or script | Back up the world directory and JSON before editing. Do not treat the Windows path as a Linux or hosted path. |
| Managed hosting panel | Server Options panel and provider file manager | Defaults can differ. WinterNode documents 1–100 players and a default of 100; Akliz documents mode values 0, 1, 2, and 4 in JSON guidance. |
Managed hosts may also provide automatic updates. WinterNode recommends keeping updates enabled unless you have a deliberate version-pinning plan, warning that an outdated server can cause connection issues. If a panel exposes a field that conflicts with the package reference, use the provider’s current documentation for that panel and verify the result after a restart.
What should I know about seasons and content bundles?
Leave the season automatic unless the group intentionally wants a specific event. With no -season argument, the package follows the system date; hosted JSON guidance also documents seasonOverride values for deployments that expose that option.
Content-bundle activation deserves more caution. The dedicated-server reference says activation is permanent for that world and cannot be undone. Back up first, confirm every player wants the bundle, and activate it only on the intended world slot. If you are testing content, use a separate slot so the permanent change does not affect the main campaign.
Why is my server loading the wrong world?
The most likely configuration issue is an unexpected world slot/index, not a seed change. Check the active slot against the value recorded with the backup, then stop the server before correcting it.
- Confirm the server is reading the intended
ServerConfig.jsonor panel profile. - Verify that the world directory contains the expected slot.
- Check that a test slot was not left selected after an experiment.
- Restart and confirm the loaded world before allowing players to build.
- Never delete or overwrite the established slot until a separate backup has been tested.
What should I do when a setting appears to have no effect?
First determine whether the value belongs in JSON, a panel, or launch arguments. Then stop the server, save the change, and restart; a running process will not apply Server Options edits.
- Mode or seed: verify that you are editing the world created with that value. Seeds do not regenerate existing worlds, and creative/non-creative changes after creation are unsupported.
- Player limit: compare the value with the deployment’s documented range and confirm the active server after restart.
- Port or IP: move the setting to launch arguments for the official package;
-iprequires-port. - Game ID: remove a custom ID that fails validation and let the server generate one.
- Season: check whether an explicit override is replacing automatic date-based behavior.
- Content bundle: remember that activation is permanent; restoring the pre-activation backup is the recovery path.
What information should I give players before the first session?
Send only the connection method that matches the running configuration. For Game ID joining, provide the current generated ID and the world name. For direct IP, provide the address, port, and password if one is configured.
Also tell players the intended mode, maximum group size, and whether the world is a test slot or the established campaign. Ask everyone to join after the final restart so no one enters while the server is still applying configuration changes.
Frequently Asked Questions
Can I run a second Core Keeper world without deleting the first one?
Yes. Keep the established world’s slot unchanged and assign a different world index/slot to the experiment. Record both slot numbers so a restart cannot accidentally point the group at the test world.
Is a Core Keeper server password required when joining by Game ID?
No. The dedicated-server package documentation says passwords apply to direct connections and are not used for Game ID joins. Configure one when you expose a direct-IP endpoint, not as a substitute for choosing the correct Game ID.
What happens if I activate a content bundle by mistake?
Activation is permanent for that world according to the dedicated-server reference. Your practical recovery is to stop the server and restore a backup from before activation, which is why a verified backup should precede the change.
Why does a hosted panel show a different player limit than the server package?
Providers choose their own panel defaults and validation ranges. The package reference lists an omitted maximum of eight, while WinterNode documents a 1–100 hosted range and a default of 100; set the value explicitly for your deployment.