Getting Started with Your Core Keeper Server

Your server says Running, you've copied the IP and port off the overview page, and you've pasted them into the group chat. Nobody can get in. Nothing is actually broken here: a Core Keeper server wants a password alongside the IP and port, and most of your Steam friends don't need the IP at all. Those two facts trip up more new server owners than everything else in this guide put together.

So here's how a Core Keeper server on our platform actually works: how people get in, where the world file ends up, what you can change yourself, and what you can't.

How players actually join

Core Keeper gives your players two ways in, and our servers accept both.

The Game ID is a long alphanumeric string that the dedicated server generates for itself when it boots. Players on the Steam version open the game, click Join Game on the main menu, paste that string in, and they're through. No IP. No port, no password, none of the usual faff.

The IP route is for everyone else. We launch every Core Keeper server with -port set, which switches on Pugstorm's direct connection mode, and that's what lets a friend on the Epic, GOG or Microsoft Store version join at all. They pick the join via IP option under Join Game and fill in three things: the IP, the port and the server's password. Leave the password out and the join fails, which is the usual story behind "nobody can get in".

You can read those details in three places:

• GameInfo.txt, in the root of your server folder. Open File Manager in the sidebar and it's sitting next to CoreKeeperServer.exe. It lists the Game ID, IP, port and password, and it ends with a line in the form IP;PORT;;PASSWORD that fills all three boxes at once when pasted into the IP field.
• GameID.txt, right beside it, which holds just the Game ID.
• The startup output in Web Console, which is the quicker route if the server is booting in front of you.

We delete GameID.txt immediately before every start. That looks alarming the first time somebody spots it, so for the record: it's deliberate, and it's precisely what Pugstorm's own Launch.PS1 script does on a self-hosted box. We didn't invent the habit, we inherited it. The server writes a fresh copy once it has finished booting. The point of it is that the ID you're reading always belongs to the run happening right now, rather than to some session from a fortnight ago.

Which brings me to the most common Core Keeper ticket we get. If GameID.txt isn't there, your server didn't start properly. It's not a broken install, and it isn't a file we forgot to ship. We've had customers reinstall twice and run a Steam update chasing a missing GameID.txt, when the real problem was the server process dying seconds into startup. Read Web Console first. Always.

One more thing, and I'd take this one seriously. The Game ID skips the password entirely. Pugstorm's own documentation is blunt about it: the ID alone gives a player everything a password would. Anyone holding that string can walk in and help themselves to your base, and so can anyone holding the IP, port and password. The order form does ask you for a server password, but Core Keeper doesn't take it from there. The server uses whatever is in its own config file and makes up a random one if that's empty, so check GameInfo.txt for the password your server is really using rather than assuming it's the one you typed at checkout. Keep all of it out of public Discords, and out of screenshots.

Where your world lives

Your world files sit in Saves\worlds\ inside the server folder. We launch with -datapath "Saves" (that's the argument doing the work), which drags the save location into the server directory where you can reach it, instead of leaving it buried in a Windows user profile the way a self-hosted install would.

A brand new server looks completely empty in there, and that's fine. The worlds folder isn't created until the world saves for the first time, which is roughly thirty seconds after the first player logs in, not at startup, which is the bit people expect. Start the server, join it once, then go and look.

Each Core Keeper service runs a single world. If you're bringing one across from a local game or another host:

1. Stop the server, and wait for it to properly stop rather than assuming.
2. Upload your world folder into Saves\worlds\ with File Manager.
3. Start the server and join, to confirm it loaded what you expected.

File Manager handles most of this happily. For anything over roughly 500 MB use SFTP on port 8822 instead (FTP is on 8821 if you'd rather) because the browser uploader gets slow and sulky with large folders. Your connection details are on the service page.

Worth saying plainly: there's no Cloud Backup or Cloud Restore in the sidebar on Core Keeper services, so nothing is quietly snapshotting your world on your behalf. Before you do anything risky (a reinstall, a build change, dropping in a world from somewhere else), download Saves\worlds\ to your own machine. It takes a minute. It's also the whole difference between an annoyance and losing the base your group spent a month on.

What the panel gives you, and what it doesn't

I'd rather you learned this from a guide than from a ticket. Core Keeper is a sparse game in our panel next to something like Palworld or Valheim (considerably sparser), and knowing that up front saves you hunting for buttons that were never there.

You get:

• Web Console, for live server output including the Game ID and join details at startup.
• File Manager, for the world folder, GameInfo.txt, ServerConfig.json and the log.
• Steam Update, to pull the current dedicated server build.
• Current Activity & Stats for CPU, memory and player history.
• Start, stop and restart from the service page, plus a reinstall when you want to begin again from clean.
• SFTP and FTP access.

What you don't get on a Core Keeper service is Configuration Files, Commandline Manager, Mod Manager, Cloud Backup or Cloud Restore. There are no config templates behind the first of those, so there's nothing for it to open even if you find your way to it.

The practical consequence is the bit that matters. Core Keeper reads its settings from two places: its launch arguments, and a ServerConfig.json file in your Saves folder. The command line is locked on this game, and anything passed on it wins, so your world name and slot count (-worldname and -maxplayers) aren't yours to change: the server writes them back over the file every time it starts. Open a ticket and we'll change them for you.

The rest of ServerConfig.json is yours to edit in File Manager. That's where your own Game ID (gameId), the IP join password (password) and the seasonal event override (seasonOverride) live, along with the world seed (worldSeed), which only counts when a world is first created. Stop the server first, save your change, then start it again.

I'm not going to dress the locked half up as a design decision. It's a gap, and it's a fair thing to be annoyed about.

Your server name, and getting settings changed

The name you picked when you ordered is handed to the server as -worldname, so it's the server's name and the name attached to the world all at once. It's set at provisioning, and there's no field in the panel to edit it afterwards. Don't go looking in Service Settings: it isn't hiding in there, it genuinely isn't there at all. Editing worldName in ServerConfig.json won't stick either, for the reason above.

If you want it changed, raise a ticket. The server picks its world by slot number (we launch with -world 0), not by name, so a rename shouldn't cost you anything. Take that copy of Saves\worlds\ I mentioned above anyway. I'd want a backup in hand before anything touches a live world's launch settings, and honestly, so should you.

Mods are a support conversation too. We don't install mods on Core Keeper servers and Mod Manager isn't enabled for the game, so if mods matter to your group, ask us what's possible before you build a whole season around them.

Restarting, updating, and one log line to ignore

When a Core Keeper patch lands, your server needs the matching build or players get bounced at the door. Run Steam Update from the sidebar, let it finish, then start the server again. Do that as soon as you notice a patch has dropped (not when somebody complains in chat) because the complaint always seems to arrive at about half eleven at night.

A restart is just stop, wait, start. Give it a moment, though. The process takes a little while to come up and write its Game ID, and hammering the start button twice tends to leave you worse off than simply waiting thirty seconds would have.

After any restart, re-read GameInfo.txt before assuming the old code still works. If gameId is blank in ServerConfig.json, the server mints a fresh Game ID for every session, so yesterday's code is dead the moment it restarts. If you'd rather hand out one code and be done with it, put your own in that field: 15 to 28 letters and numbers, with no Y, y, x, 0 or O.

Last thing. If you go poking around in Web Console, you'll see this:

Dedicated video D3D11 device creation failed (error: 0x887a0004). This device is used specifically for video decoding, we will use software video decoding instead.

That's normal, and it isn't your problem. It's a headless Windows machine mentioning that it has no GPU for video decoding, which a game server has absolutely no use for anyway. It turns up on Core Keeper servers that are running perfectly well. If yours is genuinely misbehaving the real error is somewhere else in the log, and CoreKeeperServerLog.txt in File Manager holds the full history once Web Console has scrolled past it.

If you're stuck on any of this, or you want a setting changed that the panel won't let you near, open a ticket. We're around at all hours, and with Core Keeper in particular, a good chunk of what you might want doing is a two-minute job at our end. The Core Keeper server hosting page has the plan details, and the panel itself lives at https://control.low.ms.