Set a player password to restrict joining, keep the administrator password separate, and decide independently what the factory should do when everybody leaves. Then select the session that should return after a restart. Those are four different decisions; setting an admin password alone does not make a dedicated server private.
This guide covers an already reachable desktop dedicated server and its in-game Server Manager. Have administrator access, the correct server address and a second player available for verification. UI wording can vary with the installed build; use the named controls rather than copying unrelated INI keys from older guides.
Identify the instance and preserve a checkpoint#
Select the intended server in Server Manager and confirm the address and current factory. Record the active session, build, current settings and who should have administrative access. Two entries with similar display names are not necessarily the same instance.
Before changing session selection, create a named save, wait for it to complete and retain an independent copy. Keep existing saves while checking the new settings. If you later load an older checkpoint, progress made after it will not magically merge into that world.
For a newly installed, unclaimed server, use Server Manager → Add Server. Verify the certificate identity with the owner or trusted server console before accepting it, then claim the instance by setting its server name and administrator password. Complete this ownership step before distributing the address. An existing claimed server needs administrator authentication, not another claim or a settings reset.
Give players a joining password, not the admin credential#
Open Server Settings while authenticated as administrator. Under Player Password Protection, use Change Password and set a distinct joining password. Confirm the change and apply it where the interface asks you to. Share that credential privately with the intended players.
Admin Password protects management actions such as changing settings and loading saves. It is for the people you authorize to administer the server. Giving it to everyone as the invitation password grants more access than they need. The two credentials should be different; the bundled API documentation also treats them as separate credentials and rejects reuse between them.
Ask a player who has not authenticated as admin to test joining. Verify that they can enter with the intended player password and that an incorrect password is rejected. Use a fresh client authentication attempt when checking this: a remembered authenticated session does not test the new password prompt. Do not paste either password into screenshots or a public troubleshooting report.
If a joining credential becomes known outside the group, replace it and tell the authorized players through a private channel. Losing the admin password is a separate recovery problem. Deleting the server-settings save as a shortcut also changes other identity and configuration state; it is not part of this privacy setup.
Choose whether production continues while nobody is online#
Auto Pause controls simulation when no players are connected. Enable it if the group wants the factory to wait between shared sessions. Disable it if unattended production is intentional. Discuss that choice with players who depend on a particular production schedule.
This setting does not stop the operating-system service, choose a different world or create a backup. A server appearing unreachable after the last player leaves needs its own connection and process investigation. A historical player report describes that symptom continuing even with auto-pause disabled; it does not establish pause as the cause.
To verify the policy, record a recognizable production state, have everyone disconnect, wait a measured interval and rejoin. Compare the result with the selected policy. Avoid deciding from a running process alone: the service can remain available while simulation is paused.
Select the session for startup separately from the current save#
In Manage Saves, identify the session containing the factory you intend to keep playing. A session groups its saves; the name of one manual checkpoint is not necessarily the session name. Inspect the selected save and load it deliberately when changing the currently active game.
Set Auto-Load Session Name to the intended session in Server Settings. It selects which session's most recent save should load at server startup. Changing this value does not immediately replace the currently loaded game. The API reference explicitly separates future automatic loading from the active session.
If several factories are stored on the instance, write down both the active session and the auto-load selection. Do not delete another session to simplify the list. First establish which save contains the expected buildings and progress.
Check the settings after a planned restart#
Read back the settings after applying them. Review Auto-Save on Player Disconnect separately from Auto Pause, and keep periodic autosaves enabled. Save the active world explicitly and wait for completion before a planned stop; do not assume that every shutdown writes a fresh world save.
Restart through the existing administration procedure during an agreed window. Check that the expected session loaded, the password policy still works for a non-admin player, and Auto Pause retains the chosen value. The current server-wrapper maintainer notes report that some settings can revert after restart, so readback is more useful than assuming a saved click persisted.
If your own VPS hosts several games, Nexardo's administration workflow can help keep the instance identifiable alongside routine operations. Retain the player-access policy, authorized administrators and selected session in that record without writing their passwords into it.
